Downgrade response time HTTP-2 after 1.3.0 to 2.0.1 #321
Comments
|
Hello, I'm not sure what you mean by "downgrade" here or what you're measuring exactly. I don't think there's any changes that require configuration although if you're connecting over HTTP/2 some settings are best tweaked. |
|
Response time from services has increased, I have changed only 1.3.0 to 2.0.1 without any settings, and I have got worst percentiles. No any changes except gun version. I can show graphics. |
|
I need a way to reproduce but having data would help understand what this is about yes. |
|
There are 2 services on AWS + http2 with gun, response from 2nd service grew after update 1st service to 2.0.1 gun |
|
So in % BEFORE |
|
4194682 was meant to improve HTTP/2 performance when receiving larger bodies. But perhaps this had a negative impact in your case. What is the size of the body you send, and what is the size of the body you receive (roughly)? Another change that was done is There may be a few other things. If you can try different Gun commits it could help identify when things started getting worse. I could provide a few interesting commits to upgrade to and see what happens. |
|
received_bytes sent_bytes |
|
Yeah small. So it's possible the higher default is causing trouble for the server. Try setting the |
|
And another |
But I don't see -type opts() :: #{
connect_timeout => timeout(),
http_opts => http_opts(),
http2_opts => http2_opts(),
protocols => [http | http2],
retry => non_neg_integer(),
retry_timeout => pos_integer(),
trace => boolean(),
transport => tcp | tls | ssl,
transport_opts => [gen_tcp:connect_option()] | [ssl:connect_option()],
ws_opts => ws_opts()
}.and -type http2_opts() :: #{
keepalive => timeout()
}. |
|
Right it's not available in 1.3, sorry. I guess the only way to properly test is upgrading to 2.0 and set the option there to 65535. |
Thank's! I'll try it later! #{
http2_opts => #{
keepalive => 60 * 1000,
initial_connection_window_size => 65535, initial_stream_window_size => 65535
},
connect_timeout => 5000,
retry => 100,
retry_timeout => 1000 % 1s
},except of yours? |
|
Go with that for now and let's see. |
It really works! Much better with options! 1st, 1.3.0 After, 2.0.1 |
|
Glad to hear. I didn't expect that the default value's increase would have such a negative impact, I will need to do further experiments and perhaps change either the value or the related algorithm to better handle both cases (small bodies and large bodies). Might be worth looking at what browsers are doing too. |
Another example 1.3.0 2.0.1 default 2.0.1 + extra options So you see 2.0.1 with not extra options gives really downgrade response time |
|
Maybe you can advise how to correct choose these values? What's the rule? |
|
I have a service which works correct with default gun, I'll give you sizes of bodies on Monday. It's really interesting, no any downgrade. |
It's just a control for how much memory you are willing to accept using. With the downside that the lower the value (and the lower the memory usage) the lower the performance. Default Gun has those values to 8MB to favor performance when having large bodies. But in Gun setting this value to 8MB has no effect on its own, no buffer gets allocated immediately, it just means there can be roughly 8MB in transit at once between your application and the server. Clearly the server you are connected to doesn't seem to like that though. Maybe on your service that runs well you are connected to a different server. Or perhaps it's an issue related to shared resources or bandwidth. Figuring out the real cause is likely to be difficult. |
So initial_stream_window_size - is it a max size for 1 stream? |
|
Best I redirect you to the spec, see https://datatracker.ietf.org/doc/html/rfc7540#section-6.9.1 for full details about flow control. The two options are what Gun will set for the initial values for the flow control window. Then Gun has an algorithm that ensures there's always some space in the window, see cow_http2_machine:ensure_window for the implementation. |
|
Morning) Now I get new error {badmap,{'EXIT',{{badmatch,{error,{stream_error,{closed,{error,closed}}}}} And stacktrace shows a line with Maybe another additional options are needed? |
|
That just indicates the server closed a connection. Please open a separate ticket with the stacktrace. |
It’s already open actually that’s why I switched back to gun 1.3.0 |
|
Have you tried to using The way the HTTP/2 handler is implemented in gun means that gun will use two seperate gen_tcp:send for every HTPP/2 requests, one send for the header frame and one for the data frame. This leads to two TCP fragments being send and that pattern then triggers a bad interaction between the TCP Nagle algorithm and TCP delayed ACK. The observable effect is typically a 40ms delay in the request. |
No, I haven't. I used initial_connection_window_size/initial_stream_window_size and it helped with reduce of response time. |
Hello! We have a huge downgrade response time after updating to 2.0.1 after 1.3.0.
My config for client...
Opts = #{
connect_timeout => 5000,
retry => 100,
retry_timeout => 1000 % 1s
},
Args = [
{size, PoolSize},
{start_mfa, {gun, start_link, [self(), Url, 443, Opts]}},
{supervisor_period, 1},
{supervisor_intensity, 1000},
{supervisor_restart, permanent}
],
Result = erlpool:start_pool(PoolName, Args),
And request
StreamRef = gun:post(ConnPid, Path, [
{<<"content-type">>, "application/json"},
{<<"content-length">>, integer_to_binary(size(ReqBody))}
], ReqBody),
GunResp = gun:await(ConnPid, StreamRef, ?TIMEOUT),
Maybe we have to add some extra options which are not required in 1.3?
The text was updated successfully, but these errors were encountered: