Question about setting stream window size

[asagrat]

Hi All,

Is there any option to explicitly set window size? Or it's hardcoded? What is the value in this case?

Maybe window size is dynamically calculated based on some system/environment factors (so that implicitly we can influence window size)?

[karimra]

This is handled by the underlying gRPC package. Is there is a specific reason you want to manually set the window size ?

[asagrat]

Recommendation is coming from the vendor - increasing window size upto 5MB. This is based on the number of subscribed paths and volume of streamed data. Not mandatory but will help with efficiency. "This is handled by the underlying gRPC package" - anything I can modify there to increase window size?

…

On Thu, Aug 15, 2024 at 3:26 PM Karim Radhouani ***@***.***> wrote: This is handled by the underlying gRPC package. Is there is a specific reason you want to manually set the window size ? — Reply to this email directly, view it on GitHub <#508 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXLESORGDCKIWHUYMB7XRVDZRUTKHAVCNFSM6AAAAABMQUMJ56VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJSGM4TMMRUGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[LimeHat]

Not mandatory but will help with efficiency.

Just out of curiosity, how is the efficiency defined in this case?

We can expose the InitialConnWindowSize and InitialWindowSize settings, which disable the dynamic BDP estimator and allow you to manually configure the initial window size for the connection and streams. That should be a trivial change

Maybe window size is dynamically calculated based on some system/environment factors (so that implicitly we can influence window size)?

It is, based on BDP.
https://github.com/grpc/grpc-go/blob/master/internal/transport/bdp_estimator.go

[asagrat]

It was seen that in some cases the negotiated window size was not the optimal for whatever reasons (too low). This could lead to some negative side effects (without going into much details of it). Correspondingly, switching to a static higher window size has shown an overall 'improvement'. This is especially emphasized in case of a large streaming data volume.

…

On Wed, Aug 21, 2024 at 11:10 AM Sergey Fomin ***@***.***> wrote: Not mandatory but will help with efficiency. Just out of curiosity, how is the efficiency defined in this case? We can expose the InitialConnWindowSize and InitialWindowSize settings, which disable the dynamic BDP estimator and allow you to manually configure the initial window size for the connection and streams. That should be a trivial change Maybe window size is dynamically calculated based on some system/environment factors (so that implicitly we can influence window size)? It is, based on BDP. https://github.com/grpc/grpc-go/blob/master/internal/transport/bdp_estimator.go — Reply to this email directly, view it on GitHub <#508 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXLESOQMKDLJJ3HG255BFVDZSTJX5AVCNFSM6AAAAABMQUMJ56VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBSGY3TQNJQHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[karimra]

You can increase the target buffer size to move more messages at once from gRPC to the output(s).

targets:
  router1:
    # other fields
    buffer-size: 1000 # defaults to 100

If you consider that the window size is not enough, it's probably that gNMIc is not able to write fast enough to the output and the gRPC congestion control is kicking in. There are ways to improve that depending on which output you are using.