square
custom config for client's SETTINGS_INITIAL_WINDOW_SIZE
Although I use okhttp in Android client, and maybe for performance or other reasons, the SETTINGS_INITIAL_WINDOW_SIZE value for client now is OKHTTP_CLIENT_WINDOW_SIZE = 16MiB, and can't set to other value. But sometimes we want to change this value, we can config it a different value by consider the quantity of request, request payload, timeout and other factors. So are there probability to support this feature?
Can you run an experiment and share the impacts? Ie. benchmark the benefits of using 512 KiB, 16 MiB, and 512 MiB?
My hypothesis is that the 16 MiB value is a good enough memory/throughput balance for every application. If you get better performance with a different value, I'd love to learn more.
Thanks for reply. I'm sorry about to no benchmark data to present, and maybe my think is fault. From my opinion every different case have different performance target. Large window size means high transfer speed for one stream but low fairness for multiple streams. Please think this case, I have a list of four audio names and each have a play button, and user can click any button to play any audio, there is no definite order to play, user can play arbitrary audio in arbitrary order. But audio datas need fetched by url. My player can start play even if the entire audio data not download complete. So I'm request four audio files concurrently. We assume that each audio data size smaller than 16MiB, then we can see we receive those audio datas one by one in the whole. If user click one button, but correspond audio data in the end of the transfer queue, he maybe wait long time. But if we receive those audios crossly, i.e. multiplex, so whichever button the user click, he can wait shorter than above, because we play audio at the same time we download it, we don't care how fast it transferred, I'm only want to use least connection to satisfy my requirement. In fact, this case is very close to my real case in my app.
Ahhh, got it. The window size is unlikely to be the problem or solution here.
Sending data of each stream evenly is a tricky problem. Assuming no packet loss your biggest problem is the server is going to send data in an arbitrary order, and that might not be the order you'd prefer.
Try asking on StackOverflow. I'm out of ideas here.
I've been still thinking about this and I've come around that the window size could work. Sorry for the snap judgement.
Hi, what's the result of you think about. Explain more, before user click any button, we do the preload, so all the data have the same priority, then it's nothing about the order the server send data.
@swankjesse If we tackle this, we should look at our current logging as well, make sure we have the right level of information in place to diagnose and tune.
09:35:52.922 url https://www.google.com/
09:35:52.922 Request Request{method=GET, url=https://www.google.com/, headers=[User-Agent:okurl/dev OkHttp/4.10.0-RC1], tags={class com.baulsupp.okurl.credentials.Token=TokenSet(name=default)}}
09:35:52.954 Dns (www.google.com): www.google.com/172.217.169.36, www.google.com/2a00:1450:4009:800:0:0:0:2004
09:35:53.097 Q10002 scheduled after 5 s : OkHttp www.google.com ping
09:35:53.098 >> CONNECTION 505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
09:35:53.098 >> 0x00000000 6 SETTINGS
09:35:53.098 >> 0x00000000 4 WINDOW_UPDATE
09:35:53.098 Q10005 scheduled after 0 Ás: OkHttp www.google.com
09:35:53.099 Q10001 scheduled after 0 Ás: OkHttp ConnectionPool
09:35:53.099 Q10005 starting : OkHttp www.google.com
09:35:53.099 --> GET https://www.google.com/ h2
09:35:53.099 Q10001 starting : OkHttp ConnectionPool
09:35:53.099 User-Agent: okurl/dev OkHttp/4.10.0-RC1
09:35:53.099 Q10001 run again after 300 s : OkHttp ConnectionPool
09:35:53.099 Accept-Encoding: br,gzip
09:35:53.099 Host: www.google.com
09:35:53.099 Connection: Keep-Alive
09:35:53.099 --> END GET
09:35:53.099 Q10001 finished run in 362 Ás: OkHttp ConnectionPool
09:35:53.100 Matching interceptor: null
09:35:53.100 >> 0x00000003 47 HEADERS END_STREAM|END_HEADERS
09:35:53.132 << 0x00000000 18 SETTINGS
09:35:53.132 Q10002 scheduled after 0 Ás: OkHttp www.google.com applyAndAckSettings
09:35:53.132 Q10002 starting : OkHttp www.google.com applyAndAckSettings
09:35:53.132 << 0x00000000 4 WINDOW_UPDATE
09:35:53.132 Q10004 scheduled after 0 Ás: OkHttp www.google.com onSettings
09:35:53.132 >> 0x00000000 0 SETTINGS ACK
Small note if this is still open, we tested increasing it to whatever chrome uses, and we noticed a slight loss in performamce. We were running ~2k requests/second, we had a lot of data to compare it to and yeah saw it going down a bit.
I can run the test again if needed but increasing it caused 15ms ish decline. we tested this with real world site, where we have a latency of 250ms so the 15ms was easily noticeable
hope this helps, i think it should stay the way as it is as imo its easy to change and adding an option for that might cause people to tinker with it without knowing how it works then complain later abt performence
Looked into this in https://github.com/square/okhttp/pull/7804/files#diff-c6fc1bf3c089bee5d491717bd27b42f193c3b5590dd9d344530361eac25ac042
But we decided not to go ahead with it.
Note: there is also observability in 5.x here https://github.com/square/okhttp/pull/7810