On Sat, 2020-05-30 at 21:58 +0200, Michael Osipov wrote: > ...
> > #isDataAvailable is not cheap even with 1 ms timeout. Socket > > timeout > > granularity is far from being 1 ms. In fact it is pretty close to > > 50 > > ms. If we are not careful we can easily end up with 50 ms overhead > > for > > every write operation. > > Where did you get the 50 ms? Is that a Java thing? OS thing? If OS > which > OS did you try, reference for this value? > Past experience with the stale connection check. It may not always be 50 ms depending on JRE / OS / Java version / other factors but it is always substantially more than 1 ms. I presume this is a general shortcoming of the classic i/o in Java. > > I am _hoping_ that SSL input stream would not actually read > > anything > > from the underlying socket as long as there is unencrypted data > > stuck > > in its buffers. > > ... > > Makes sense. Please see the updates in my branch. > > Will pick this up on Monday as soon as I get access to our > infrastructure. > > > Now we need to decide if this is as good as it gets or we want to > > put > > more research into it. > > I read liked you idea of the chunks. 2048 seems too low for me > because > most well write with a buffer of at least 4 KiB. > > So I think we can try to things to miminize overhead: > > * Make this feature optional, just like we do with Expectation. > * Try to increase the step chunk size, e.g., 64 KiB or greater. With > that we don't peek on each and every invocation. > Yes, we may consider making it optional / disabled by default We can give step chunking another go but it is less important now as I have inserted the check into the low level socket stream whose write operations should be already quite optimized by the protocol layer. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
