Performance Questions and Poller Implementation in Project Loom

[Robert Engels]

In the robaho version there is no setting of the socket send buffer - it uses the os default size. The 1mb buffer in user space is the same in both. Same with the baseline. 

The floating buffer is what causes the ENOBUFS in OSX - Linux does not exhibit this issue. 

That helidon is setting the kernel send buffer behind the scenes was not obvious to me. 

I will try and configure both to be be the same and rerun. 

> On Nov 10, 2023, at 5:25 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
>  On 10/11/2023 00:12, robert engels wrote:
>> Btw, I had a chance to check out Helidon 4.0 and the results are mixed. I really like the programming model.
>> 
>> In a very simple (and probably not very meaningful nor scientific) test github.com/robaho/httpserver outperforms it by 2x. I couldn’t get it to work on Linux (see https://github.com/helidon-io/helidon/issues/7983), which is strange given that they have very similar non-async designs.
>> 
>> The robaho httpserver achieves more than 6GB/sec on Linux under the same conditions as reported in the issue. Hopefully the Helidon team checks it out and makes some recommendations or at least provides reasoning around the performance issues.
>> 
> 
> If I read this correctly, this is comparing two HTTP servers that serve up responses with a 1MB payload through the loopback interface. 
> 
> For the Helidon case, it's Socket.write with the socket's send buffer (SO_SNDBUF) set to 32k.  The robaho server is using SocketChannel.write channel's socket send buffer set to 1.3MB. You probably need to configure them to be the same.
> 
> -Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20231110/cb31a486/attachment.htm>