Are you referring to Rob Mayoff's threadpool code from 2004? Does it
still work in 4.5.1?
I'm trying to avoid modifying the code as much as possible; I may get
to that point, but I'm trying to exhaust my tuning options first. I
have a feeling that once I crack open the cover I'm going to be stuck
in buggy quicksand and I'd rather not go there if I don't have to,
despite how financially rewarding it would be. :)
janine
On May 12, 2009, at 3:34 PM, Tom Jackson wrote:
On Tue, 2009-05-12 at 22:23 +0200, Gustaf Neumann wrote:
Janine Sisk schrieb:
When I first started working on this problem, the settings were
ns_param maxconnections 5
ns_param maxthreads 5
ns_param minthreads 5
maxconnections of 5 is for most applications to small. The term
"maxconnections" is misleading since it does not mean "maximum
number of incoming connections", but is a counter per thread, when
it will shut down. With the value above, every thread will exit
and be recreated after 5 requests. If the application is well
written,
no garbage should be left after the request, therefore the value can
be set to e.g. 1000.
This sounds like great general advice. If I had to boil down a few
rules, I would say at bare minimum:
maxconnections > 5 * maxthreads.
But 10 to 20 times would be much better. Also, unless you have a
memory
leaking application, start with a minimum of 100 for maxconnections.
You should also be using threadpools. If you don't, then every request
gets dumped into a default threadpool that is shared by all virtual
servers. What this means is that it is possible for multiple interps
to
exist in each thread, up to one for each virtual server. At a bare
minimum, each virtual server should have its own default threadpool
which matches every request to that vs.
So the problem with one nsd-process-wide threadpool is the memory
footprint of each thread will be at least the sum of each vs interp.
Maybe I should point out that one advantage of threads is to reduce
the
memory footprint by specializing the interp code.
If you setup a number of threadpools, you can partition your requests
into static and dynamic (at the very least). A few threads can handle
many static requests. You should also partition your requests by need
run tcl code/filters.
Do you want to require filter processing for css and basic image
files?
Personally I would use a different port for pure static content. I
have
used publicfile: http://cr.yp.to/publicfile.html but I have heard that
AOLserver is pretty fast at static file handling (I'm trying to catch
up).
tom jackson
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[email protected]
> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.
---
Janine Sisk
President/CEO of furfly, LLC
503-693-6407
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<[email protected]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
