libmicrohttpd
[Top][All Lists]
Advanced

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

Re: [libmicrohttpd] Doubts regarding how MHD_OPTION_THREAD_POOL_SIZE and


From: Evgeny Grin
Subject: Re: [libmicrohttpd] Doubts regarding how MHD_OPTION_THREAD_POOL_SIZE and MHD_OPTION_CONNECTION_LIMIT interact together
Date: Sun, 18 Dec 2016 23:10:10 +0300
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1

On 17.12.2016 1:58, Fermín Galán Márquez wrote:
> Just to check if I have understand correctly how
> MHD_OPTION_THREAD_POOL_SIZE works, let's consider the following example.
> MDH_OPTION_THREAD_POOL_SIZE is set to 4. In a given moment, the MHD
> server is attending at the same time 4 connections at the same time
> (i.e. all the threads in the pool are busy) and a new connection is
> received at the MHD service port. As far as I understand, that
> connection is rejected (i.e. the socket is closed without sending back
> any response to the client).
> 
> Is my understanding correct, please?

No, it's not correct.
Even single thread may process many connections. When several
connections have some data to send or receive at the same time, they
will be processed one-by-one in thread. Idle connections are just resting.
In case of thread pool, each thread process subset of connections.

If MHD is used in thread-per-connection mode, single thread is running
for listen socket and new thread is generated for each new connection.
In majority of cases, this mode is less effective than thread pool.

-- 
Evgeny

> 
> 
> El 11/12/2016 a las 20:57, Evgeny Grin escribió:
>> Hi Fermin,
>>
>> First of all, I'd like to clarify: MHD_OPTION_THREAD_POOL_SIZE is
>> supposed to be set to value equal or close to number of available CPU
>> cores. If you set MHD_OPTION_THREAD_POOL_SIZE to value higher than
>> number of CPU cores then you'll most probably experience performance
>> decrease: number of actively executed threads at the same time will be
>> limited by number of CPU cores and system will waste resources for
>> switching threads.
>>
>> For other answers see below.
>>
>> On 07.12.2016 14:15, Fermín Galán Márquez wrote:
>>> Assuming that MHD_OPTION_THREAD_POOL_SIZE is greater than zero (i.e.
>>> thread pool is actually used) the following posibilites are possible:
>>>
>>>    * MHD_OPTION_THREAD_POOL_SIZE => MHD_OPTION_CONNECTION_LIMIT. In this
>>>      case, I understand that MHD_OPTION_CONNECTION_LIMIT limits the
>>>      number of concurrent connections, no matter the size of the pool.
>> Correct.
>>
>>>    * MHD_OPTION_THREAD_POOL_SIZE < MHD_OPTION_CONNECTION_LIMIT. Not sure
>>>      what happen in this case if all the threads in the pool are busy
>>> and
>>>      a new the process receives a new incoming connection, among the
>>>      following:
>>>       1. The connection is rejected (as if it has hit the
>>>          MHD_OPTION_CONNECTION_LIMIT)
>>>       2. The connection is somehow enqueued internally until a free
>>>          thread in the pool can deal with it. In that case I understand
>>>          that MHD_OPTION_CONNECTION_LIMIT is the size of such
>>> internal queue.
>>>       3. A new "extra to pool" thread is created to deal with the
>>>          incoming connection (to be destroyed once the requests has been
>>>          processed).
>>>
>>> Which option corresponds to the actual behaviour, please?
>> The same as in first case. Number of connections and size of thread pool
>> are independent.
>>
>> When MHD instance reach specified connection limits, next connection
>> could be ether rejected explicitly or not accepter before some
>> connections are closed (actually both is possible and cannot be
>> configured). In any case - MHD will not process more connection at the
>> same time then configured by MHD_OPTION_CONNECTION_LIMIT.
>>
> 
> 



reply via email to

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