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.
A test. similar to your simple adp page with maxthreads of 5 yields
between 1500 and 2500 requests per seconds, including session handling
in the preauth filter. With 24 maxthreads I get between 6800 and 7500
reqs/sec.
For a real world not cached CMS page on a 6 core hyperthreaded CPU we
still get more than 500 pages/sec with 5 maxthreads and 770-780 with 12
threads, 820 - 830 up to 950 with 24 maxthreads. From there it doesn't
change much, until performance degrades slightly again at around 100
maxthreads (780 reqs/sec).
I used ab with -n 20000 -c 50|200|500|1000
My conclusion: Having a higher number of maxthreads than the number of
cores is helping performance, more than twice the amount isn't helping
anymore.
It might be different, when you've got some long running threads, where
you have to pull information from other servers and the threads are idling.
This was all done with tcmalloc, If I'll find the time, I'll rerun the tests
with
jemalloc as well.
wolfgang
Am Samstag, 4. Januar 2014, 20:35:05 schrieb John Buckman:
> >> After rebuilding tcl and naviserver (current) from source, with
> >> -ltcmalloc, my naviserver is stable.>
> > great. the tip version of naviserver have already some modifications
> > to help against concurrency bugs in tcl (e.g. reducing the frequency
of
> > interp create operations, serializing these etc.).
>
> With Gustaf's patch in place, I was able to test tcmalloc vs jemalloc vs
> zippy in naviserver.
>
> Both tclmalloc and jemalloc gave me a 20% speed up on a simple [clock
> seconds] adp page. Both gave me about a 40% speedup on a much
more
> complicated, unoptimized Tcl index.adp page.
>
> Once I received an openssl() assertion failure on startup with jemalloc
and
> "minthreads 100" but was not able to recreate it.
>
> tcmalloc under 20 threads worked well, but performance was *terrible*
at
> "minthreads 100", (about a 90% slowdown, even with apachebench -c
10).
> Neither zippy nor jemalloc had this problem. There's something about
> having many naivserver threads launched that makes tcmalloc not work
well.
>
> Conclusion:
>
> For now, I'm using jemalloc, though the openssl assertion failure I had
> makes me nervous.
>
> tcmalloc's terrible performance with 100 threads makes me not want to
use
> it.
>
> At the same time, I don't want to stick with zippy, as I've experienced the
> "bloat" problem that Gustaf talks about, solving it at BookMooch.com
with
> 64GB of RAM (!) but that's not a very good solution, so it's worth my
while
> to try other mallocs.
>
> -john
>
>
>
> ----------------------------------------------------------------------------
> -- Rapidly troubleshoot problems before they affect your business. Most
IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics
> Pro!
>
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.
clktrk
> _______________________________________________
> naviserver-devel mailing list
> naviserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
--
digital concepts OG
Software & Design
Landstrasse 68 / 5. Stock
A - 4020 Linz
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
