On 05/06/2015 12:12 AM, Bob Furber wrote: > On 15-05-05 03:09 AM, Christian Grothoff wrote: >> If your handler routine is reasonably fast, it can be difficult to >> stress-test an MHD server with just a single client... > > I can get MHD on our ARM server to back up at about 150 (27 byte) > requests/s sent by a LinuxPC on the same LAN. That is, if the client > bombards the server at this rate for about a minute, and then posting > requests is stopped. However, 1000 to 2000 replies are returned by the > server AFTER sending requests has ceased. > >> 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. > > Ah! So, the OS (Linux, in this case) has a TCP listen queue! Doh! I was > unaware. This is a good clue for further investigation. > > But, I am still puzzled by the limit of 6 concurrent MHD threads? Why 6, > not 5, 7...? Is this modifiable? Would there be any benefit to > increasing or decreasing this number?
There is no hard limit like that by MHD. However, usually having significantly more threads than cores is unlikely to improve performance if you are CPU-bound. For the best performance, you should typically use the thread pool, there you can specify exactly the number of threads MHD should start. Why you currently get exactly 6 is not something I can say; MHD should start more (in thread-per-connection mode) if there are more concurrent connections to be handled. -Christian
