[ 
https://issues.apache.org/jira/browse/TS-3185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sudheer Vinukonda updated TS-3185:
----------------------------------
    Description: 
 Currently, proxy.config.spdy.initial_window_size_in is set to the default 
value 64K (suggested in
http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3-1). This 
suggested value is perhaps due to historic reasons when the window_size was 
only allowed 2 octets in the older spdy versions.

Note that, ideally, the client (sender) should still be able to defer the 
upload when the send window is exhausted until the server (receiver) sends an 
WINDOW_UPDATE frame indicating to resume the sending. 

Even so, 64K may still be too small and may result in increasing upload
latencies, especially, in case of large concurrent upload scenarios. Hence, I 
would like to bump up the default value for the spdy initial window
size to a higher value (preferably, 1 mb that more popular spdy enabled web 
servers are using).

Here's some basic benchmarking data (thanks to [~yzlai]):

5 parallel uploads from APAC to the US with a total of 2,299,250 bytes.

spdy=off, 2.34 secs
spdy=on, spdy.initial_window_size_in=64k: 11.28 secs
spdy=on, spdy.initial_window_size_in=1M:   1.99 secs
spdy=on, spdy.initial_window_size_in=10M:  2.01 secs


  was:
 Currently, proxy.config.spdy.initial_window_size_in is set to the default 
value 64K (suggested in
http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3-1). This 
suggested value is perhaps due to historic reasons when the window_size was 
only allowed 2 octets in the older spdy versions.

Note that, ideally, the client (sender) should still be able to defer the 
upload when the send window is exhausted until the server (receiver) sends an 
WINDOW_UPDATE frame indicating to resume the sending. 

Even so, 64K may still be too small and may result in increasing upload
latencies, especially, in case of large concurrent upload scenarios. Hence, I 
would like to bump up the default value for the spdy initial window
size to a higher value (preferably, 1 mb that more popular spdy enabled web 
servers are using).

Here's some basic benchmarking data (thanks to [~yzlai]):

5 parallel uploads from APAC to the US with totally 2,299,250 bytes.

spdy=off, 2.34 secs
spdy=on, spdy.initial_window_size_in=64k: 11.28 secs
spdy=on, spdy.initial_window_size_in=1M:   1.99 secs
spdy=on, spdy.initial_window_size_in=10M:  2.01 secs



> Increase the default spdy initial_window_size_in setting to 1 mb
> ----------------------------------------------------------------
>
>                 Key: TS-3185
>                 URL: https://issues.apache.org/jira/browse/TS-3185
>             Project: Traffic Server
>          Issue Type: Improvement
>          Components: SPDY
>            Reporter: Sudheer Vinukonda
>
>  Currently, proxy.config.spdy.initial_window_size_in is set to the default 
> value 64K (suggested in
> http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3-1). This 
> suggested value is perhaps due to historic reasons when the window_size was 
> only allowed 2 octets in the older spdy versions.
> Note that, ideally, the client (sender) should still be able to defer the 
> upload when the send window is exhausted until the server (receiver) sends an 
> WINDOW_UPDATE frame indicating to resume the sending. 
> Even so, 64K may still be too small and may result in increasing upload
> latencies, especially, in case of large concurrent upload scenarios. Hence, I 
> would like to bump up the default value for the spdy initial window
> size to a higher value (preferably, 1 mb that more popular spdy enabled web 
> servers are using).
> Here's some basic benchmarking data (thanks to [~yzlai]):
> 5 parallel uploads from APAC to the US with a total of 2,299,250 bytes.
> spdy=off, 2.34 secs
> spdy=on, spdy.initial_window_size_in=64k: 11.28 secs
> spdy=on, spdy.initial_window_size_in=1M:   1.99 secs
> spdy=on, spdy.initial_window_size_in=10M:  2.01 secs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to