Re: [libmicrohttpd] Where are http requests queued?

[Christian Grothoff]

On 05/05/2015 01:32 AM, Bob Furber wrote:
> Would someone be able to tell me if there is a limit to the number of
> connection threads when *http_init*() is initialized with
> /MHD_USE_THREAD_PER_CONNECTION/?
> 
> When I torture test my MHD server by bombarding it with xhr requests, I
> can only find evidence of at most 6 simultaneous MHD threads.

If your handler routine is reasonably fast, it can be difficult to
stress-test an MHD server with just a single client. You might need to
get a good HTTP benchmark tool and a client farm with high bandwidth to
stress-test MHD.  I had a case where MHD running on a low-power ARM took
two fast i7 client systems to drive to its limit. YMMV.

> The MHD threads transfer their requests to a message queue (for
> processing by main()) and uSnooze-wait for their replies from the main()
> thread before proceeding to post their replies to the client. Normally,
> the main() thread responds as promptly as possible. But, when I put
> main() to sleep for a number of seconds, one would expect the MHD
> threads to back up and the message queue to fill up. But, the message
> queue never gets longer than 6 queue items waiting, whereas many 1000
> requests queue up while main() sleeps and are ALL are eventually
> responded when main() awakes.
> 
> What is really interesting in this exercise, is that NO requests are
> lost while main sleeps. They are queued up elsewhere. But, where? In
> MHD? In the processors Ethernet chip/module? And, more importantly,
> where should requests best be queued? Why?

I'm not sure where you put the sleep(), but you may have them in the TCP
listen() queue of the operating system.  That's a good place for them if
MHD can temporarily not catch up, you just want to keep that queue short
enough that client's do not regularly time out while in the queue.


Happy hacking!

Christian

0xE29FC3CC.asc
Description: application/pgp-keys