apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: [proposal] apr_thread_setconcurrency()
Date Mon, 17 Sep 2001 18:20:25 GMT
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



Mime
View raw message