HttpServer performance issue / improvement

robert engels rengels at ix.netcom.com
Sat Apr 6 23:37:56 UTC 2024


Hi Daniel,

Here is a PR which fixes it. All tests pass.

https://github.com/openjdk/jdk/pull/18667
fix for small messages with tcp_nodelay off by robaho · Pull Request #18667 · openjdk/jdk
github.com


> On Apr 5, 2024, at 5:37 PM, robert engels <rengels at ix.netcom.com> wrote:
> 
> Hi Daniel,
> 
> I think I have a solution that would work. I will try to get a PR together. Do you know if there is an existing test case the demonstrates the issue? - if not, I will start with that.
> 
> Robert
> 
>> On Apr 4, 2024, at 9:44 AM, Daniel Jeliński <djelinski1 at gmail.com> wrote:
>> 
>> Hi Robert,
>> Thanks for bringing this up! We are aware of the issue, it's tracked under https://bugs.openjdk.org/browse/JDK-6968351.
>> 
>> If you have an idea for a proper fix that doesn't add too much complexity, please open a PR, and we'll be happy to help.
>> Cheers,
>> Daniel
>> 
>> czw., 4 kwi 2024, 14:55 użytkownik Robert Engels <rengels at ix.netcom.com <mailto:rengels at ix.netcom.com>> napisał:
>>> 
>>> When doing some testing on github.com/robaho/httpserver <http://github.com/robaho/httpserver> - which is a fork of the jdk http server, I discovered a significant performance issue.
>>> 
>>> When an http connection is in ‘keep-alive’ - the default for http 1.1 - the headers are “flushed” here https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java#L281
>>> 
>>> This means that after the handler runs and it sends data - e.g. /hello sends “hello” on the connection, the connection will stall due to the Nagel algorithm - usually incurring a 50 ms delay. The stall occurs since the client will not see the expected data until after the delay, so it is unable to send the next (when reusing the same connection/HttpClient).
>>> 
>>> You can set the TCP_NODELAY on the server to work-around this, but a better solution would be to override the flush() on the BufferedOutputStream to not flush() the underlying connection - i.e. only write the buffered bytes, or rework it a bit to only flush when there is no content to send.
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20240406/02c0a149/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 18667.png
Type: image/png
Size: 133518 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20240406/02c0a149/18667-0001.png>


More information about the net-dev mailing list