libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] Why MHD latency is so high on Windows?


From: Martin Bonner
Subject: Re: [libmicrohttpd] Why MHD latency is so high on Windows?
Date: Wed, 18 Nov 2015 15:28:58 +0000

In general, TCP_NODELAY is not a catastrophe if you use TCP_CORK to allow the accumulation of partial packets in the kernel.  The good news is that MHD can use TCP_CORK; the bad news is that Windows doesn’t support it :-).

 

However, this link:

http://stackoverflow.com/questions/22117205/is-there-an-equivalent-to-tcp-cork-in-winsock

appears to have a some sample code that achieves a similar effect.

 

Now all we need is for somebody to create some patches to use that code on Windows, and for Christian to accept them.  (Won’t be me – I only care about linux on ARM.)

 

Von: libmicrohttpd-bounces+address@hidden [mailto:libmicrohttpd-bounces+address@hidden Im Auftrag von Evgeny Grin
Gesendet: Mittwoch, 18. November 2015 14:21
An: libmicrohttpd development and user mailinglist <address@hidden>
Betreff: Re: [libmicrohttpd] Why MHD latency is so high on Windows?

 

Hi!

 

libmicrohttpd was ported to use Windows API directly, so PlibC wrapper is not used anymore.

 

According to MSDN docs there is no TCP_FASTOPEN flag on Windows: https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms738596(v=vs.85).aspx

It also not present in any header file from VS 2010, 2012, 2013, 2015 and in MinGW-w64 headers.

How did you compile MHD?

MHD currently has no cmake files. Only autotools files for build on Linux/Unix/Darwin/MinGW/Cygwin and Visual Studio 2013 project for Windows builds.

 

If you just add "#define TCP_FASTOPEN 1" to some header, this misled MHD. On Win32 option TCP_NODELAY has value of 1. So instead of enabling TCP_FASTOPEN, you forced MHD to disable Nagle's algorithm (disabling is not recommend according to MSDN).

 

-- 

Best Wishes,

Evgeny Grin

 

 

 

18.11.2015, 05:44, "silvioprog" <address@hidden>:

Hello Nils,

I can't found any `select.c` file and PlibC entry. :-/ Is this file available in the latest MHD release?

But, after your tip, I tried to debug the MHD sources, so I found a build flag called `TCP_FASTOPEN`, and after enable it in my cmake file, rebuilt the DLL and used the `MHD_USE_TCP_FASTOPEN` option in my app, the latency problem as solved, went down to about 3 and 5 ms. However, see this part of the MHD doc:

MHD_USE_TCP_FASTOPEN

Enable TCP_FASTOPEN on the listen socket. TCP_FASTOPEN is currently supported on Linux >= 3.6. On other systems using this option with cause MHD_start_daemon to fail.

But when I enable this flag it works fine on Windows (7, 8 and 10). Is this doc topic outdate or is really wrong to enable this flag on Windows? I just did a cast at the line 4030 of the `daemon.c` file to avoid compiler hints:

if (0 != setsockopt (socket_fd,
                     IPPROTO_TCP, TCP_FASTOPEN,
                     (const char *) &daemon->fastopen_queue_size,
                     sizeof (daemon->fastopen_queue_size)))

Does anyone have problem using this flag on Windows? If not, it should be interesting to update the *FASTOPEN doc topic.

On Mon, Nov 16, 2015 at 5:23 PM, Nils Durner <address@hidden> wrote:

Hi Silvio,

 

it's been a while since I have looked at the code last, but we used to have an event loop in the Windows implementation of select() (in PlibC) that switches between waiting on sockets and waiting on other handles (specifically, a shutdown signalling pipe handle) every 200ms.

 

Just to see if this the source of the 250ms delay, you could remove the waiting-on-handles part from PlibC select.c.

 

Hope this helps,

 

Nils


reply via email to

[Prev in Thread] Current Thread [Next in Thread]