Re: [naviserver-devel] naviserver with connection thread queue

[Gustaf N. <ne...@wu...>]

On 14.11.12 09:51, Gustaf Neumann wrote:
> On 13.11.12 15:02, Stephen Deasey wrote:
>> On Tue, Nov 13, 2012 at 11:18 AM, Gustaf Neumann <ne...@wu...> wrote:
>>> minthreads = 2
>>>
>>> creating threads, when idle == 0
>>>      10468 requests, connthreads 267
>>>      total cputime 00:10:32
>>>
>>> creating threads, when queue >= 5
>>>      requests 10104 connthreads 27
>>>      total cputime 00:06:14
>> What if you set minthreads == maxthreads?
> The number of thread create operations will go further down.
Here are some actual figures with a comparable number of 
requests:

with minthreads==maxthreads==2
    requests 10182 queued 2695 connthreads 11 cpu 00:05:27 
rss 415

below are the previous values, competed by the number of 
queuing operations and the rss size in MV

with minthreads=2, create when queue >= 2
    requests 10104 queued 1584 connthreads 27 cpu 00:06:14 
rss 466

as anticipated, thread creations and cpu consumption went 
down, but the number of queued requests (requests that could 
not be executed immediately) increased significantly.

Maybe the most significant benefit of a low maxthreads value 
is the reduced memory consumption. On this machine we are 
using plain Tcl with its "zippy malloc", which does not 
release memory (once allocated to its pool) back to the OS. 
So, the measured memsize depends on the max number of 
threads with tcl interps, especially with large blueprints 
(as in the case of OpenACS). This situation can be improved 
with e.g. jemalloc (what we are using in production, which 
requires a modified tcl), but after about 2 or 3 days 
running a server the rss sizes are very similar (most likely 
due to fragmentation).

-gustaf neumann
> When running already at minthreads, the connection thread
> timeout is ignored (otherwise there would be a high number
> of thread create operations just after the timeout expires
> to ensure minthreads running connection threads). With
> connsperthread == 1000, there will be about 10 thread create
> operations for 10000 requests (not counting the 2 initial
> create operation during startup for minthreads == 2). So,
> the cpu consumption will be lower, but the server would not
> scale, when the requests frequency would require more
> connection threads. Furthermore, there will be most likely
> more requests put into the queue instead of being served
> immediately.
>
> When we assume, that with minthreads == maxthreads == 2
> there won't be more than say 20 requests queued, a similar
> effect could be achieved by allowing additional thread
> creations for more than 20 requests in the queue. Or even
> more conservative, allowing thread creations only when the
> request queue is completely full (setting the low water mark
> to 100%) would as well be better than minthreads ==
> maxthreads, since the server will at least start to create
> additional threads in this rather hopeless situation, where
> with minthreads == maxthreads, it won't.
>
>
>
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel