Aaron Bannert wrote:
On Mon, Sep 17, 2001 at 10:17:16AM -0700, Brian Pane wrote:
So that's 25 ThreadsPerChild + 3 builtin threads (door server, door client, reaper) = 28, so yeah, it stabalized to the number of simultaneous requests I expect to handle (aka the number of worker threads).
How were you handling 25 simultaneous requests with just 10 concurrent connnections in ab?
Bad wording on my part... It stabilized at the number of worker threads being used in the system.
The quick re-use of the workers in an ab test probably explains why Solaris ended up creating one LWP per worker thread in this test.
But I wouldn't extend that observation to say that it's a good idea in general to set the concurrency hint to the number of worker threads. In the real world, each thread tends to spend a lot more time waiting for I/O than it does during a stress test. If you're running a server with 500 worker threads, you probably don't want want 500 LWPs.
Since the worker queue is FIFO, all the worker threads are used fairly soon after they enter the queue. I'll be changing this to LIFO in the near future (per Dean's suggestion) for possible cache hits, etc...
My hypothesis is that the number of LWPs will drop to ~13 when you do this: 10 for the concurrent connections, plus the 3 built-in ones.
--Brian
