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

[John B. <jo...@ma...>]

Hi Gustaf, thanks for the suggestion.

I tried adding a zero, and then another zero, to 
export TCMALLOC_MAX_TOTAL_THREAD_CACHE_BYTES= 167772160

and still had terrible naviserver performance at 100 minthreads.  

When I dropped a digit, ie:
export TCMALLOC_MAX_TOTAL_THREAD_CACHE_BYTES= 1677721

naviserver failed to work at all, which serves as a good proof that the setting was taking effect.

That being said, I went with your 4xCPU cores suggestion, and set minthreads at 32 to test again. 

At that setting, performance was the same as at minthreads=10, so I can live with that!

-john


On Jan 6, 2014, at 3:05 PM, Gustaf Neumann <ne...@WU...> wrote:

> 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.