Re: [naviserver-devel] tcmalloc and jemalloc results with naviserver

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

The "best" number of threads depends on many things, including the 
hardware (e.g. number of cores). For most cases, i recommend not more 
than than 4 threads/core. With high number of threads a low numbers of 
cores, context switching might degrade performance.

concerning 100 threads vs. tcmalloc: you might try to increase 
|TCMALLOC_MAX_TOTAL_THREAD_CACHE_BYTES| (defaults to 16MB). For more 
details, see:
http://gperftools.googlecode.com/svn/trunk/doc/tcmalloc.html

concerning waiting time in threads: a good number of threads can be 
determined via observing the queuing time and the number of queue 
requests recorded by naviserver (See in nsstats (from bitbucket) the 
"process" page). The best number of theads is the lowest number where 
the number of queued requests is low (e.g. less than 0.1%) or the 
queuing time is acceptable (e.g. less than 0.1 ms). The numbers 
certainly depend on the application, but when one has essentially no 
queued requests with 30 connection threads, then there is no benefit in 
increasing the number of connection threads.

-gustaf


Am 06.01.14 14:36, schrieb John Buckman:
>
> On Jan 5, 2014, at 2:27 PM, Wolfgang Winkler 
> <wol...@di... 
> <mailto:wol...@di...>> wrote:
>
>> I was wondering, why you'll want to have 100 threads, because the 
>> number seems a little high to me. So I've just conducted some test on 
>> two of our development system.
>
> You're right, 100 is high, but I do use SQL quite a lot, and so long 
> running threads, where the cpu is blocking, waiting for a SQL server 
> response, can generate a lot of pending threads.
>
> I wanted enough threads to be around to handle short running page 
> requests too.
>
> But besides that, it's very odd that tcmalloc had this huge decrease 
> in performance at 100 threads.  It's perhaps not enough of a reason to 
> avoid tcmalloc, but it's a cause to worry, nonetheless.
>
> Gustaf's tests didn't show that same slowdown result, and the big 
> slowdown I have at 100 threads only happens with tcmalloc, not with 
> jemalloc or zippy, with a simple [clock seconds] ADP page.
>
> -john
>
>