Justin Erenkrantz wrote:
>On Thu, Apr 18, 2002 at 12:08:24AM -0700, Brian Pane wrote:
>
>>httpd listening on one port:
>> Requests/ Mean request CPU CPU
>> MPM second time (ms) load utilization
>>-----------------------------------------------------------
>>Threadpool 854 55.5 4.8 52%
>>Leader/follower 957 39.5 6.8 72%
>>Worker 892 31.4 7.0 70%
>>
>>
>>httpd listening on two ports:
>> Requests/ Mean request CPU CPU
>> MPM second time (ms) load utilization
>>-----------------------------------------------------------
>>Threadpool 848 54.5 4.8 53%
>>Leader/follower 814 58.4 4.5 51%
>>Worker 881 47.7 5.1 59%
>>
>
>(Assuming you ran with AcceptMutex pthread...)
>
Right
>Do you still have no idea why Leader/follower is getting nailed
>when there are two listeners (while worker has a dropoff, it isn't
>quite that severe)?
>
I put some ideas about this in the commit log for the initial check-in
of the threadpool code:
In my initial testing, the
leader/follower MPM performs very well on multiprocessor Solaris 8 when
listening on a single port, but poorly when listening on multiple ports.
(I don't know why this is happening. What I've found so far is that
when you add a poll on the listen socket(s) before the accept in the
leader/follower MPM, all the socket-related syscalls in the httpd get
slower. My hypothesis is that the thread scheduler is making an optimal
decision about where (on what CPU) to run the newly awakened thread if
its first syscall is an accept, and a nonoptimal decision if its first
syscall is a poll.) The threadpool MPM performs better with multiple
listener ports, and in my testing so far it looks competitive with
leader/follower when running with a single listener.
I'm inclined to call this a peculiarity of the Solaris thread scheduler,
but I'd really like to see results from at least one other multiprocessor
Unix platform first.
> So, threadpool is slower on single listeners
>but has almost no noticable difference when having two listeners
>versus one. Is this because threadpool doesn't use S_L_U_A?
>
That's what I thought, but I did a followup test with threadpool
using S_L_U_A and its performance was about the same as the non-S_L_U_A
version.
>With one listener, how does worker have a better mean but a noticably
>worse rps count? Were there some requests that skewed the mean?
>
I think this is what skewed the mean on request time:
MPM mean min max
worker 39.5ms 5.5ms 9s
l/f 55.5ms 5.5ms 21s
>Also, while I'm not terribly sure how valuable this might be to you,
>I think it might be good to see how prefork compares on this same
>test. After all, it is our default MPM and will be until we can
>prove to people (esp. committers) how much better threading can
>be. -- justin
>
I agree. If I have time, I'll run a prefork test tonight.
--Brian
