Re: Performance comparison for worker, leader/follower, and threadpool MPMs
Sorry for the late response. On Sat, 2002-04-20 at 18:05, Brian Pane wrote: Austin Gonyou wrote: ... Given that info, is there a way to do: ... Since the switch from mutexes to atomic ops on leader/follower, I'm seeing slightly lower mean response times (on par with worker and prefork). The CPU utilization hasn't dropped, but it's still competitive with prefork. The main reason I'm asking is that if worker is to be replaced, then how much longer will it be till Apache 2.0, on *nix is really ready to rock with a threaded model? Performance-wise, I think leader/follower might be there already (based on its performance compared to prefork). But it needs more testing. On this point, what is the possibility of leader/follower having another issue like worker. 25 is ok, 26 is not? (max threads) I'm only curious because I never ran into it, wasn't trying to, but I also run about 50 forks with 20-25 threads max. So I probably never would've hit the problem to begin with. Anyway..TIA. --Brian -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: [EMAIL PROTECTED] It is the part of a good shepherd to shear his flock, not to skin it. Latin Proverb signature.asc Description: This is a digitally signed message part
Re: Performance comparison for worker, leader/follower, and threadpool MPMs
On Thu, 2002-04-18 at 21:28, Brian Pane wrote: Justin Erenkrantz wrote: Also, while I'm not terribly sure how valuable this might be to you, ... Here are the prefork numbers... ...I'm going to refocus my efforts on turning leader/follower into production-quality code. --Brian httpd listening on one port: Requests/ Mean request CPU CPU MPM second time (ms)loadutilization --- Threadpool854 55.5 4.8 52% Leader/follower 957 39.5 6.8 72% Worker892 31.4 7.0 70% Prefork 899 32.9 7.3 76% Given these numbers, it seems that Threadpool is not too shabby, though the Request Time(ms) is much higher than the others, the CPU utilization is not and load is not. In terms of increasing capacity without replacing hardware, over time, that's pretty important. Given that info, is there a way to do: 1. tweak threadpool so that it uses slightly more CPU, but takes less time, not to exceed 60% cpu. 2. Tweak leader/follower to use less CPU, sub 60%, generate less load ,sub 5, and maintain or lower it's response time? The main reason I'm asking is that if worker is to be replaced, then how much longer will it be till Apache 2.0, on *nix is really ready to rock with a threaded model? TIA. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: [EMAIL PROTECTED] It is the part of a good shepherd to shear his flock, not to skin it. Latin Proverb signature.asc Description: This is a digitally signed message part
Re: Performance comparison for worker, leader/follower, and threadpool MPMs
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)loadutilization --- Threadpool854 55.5 4.8 52% Leader/follower 957 39.5 6.8 72% Worker892 31.4 7.0 70% httpd listening on two ports: Requests/ Mean request CPU CPU MPM second time (ms)loadutilization --- Threadpool 848 54.5 4.8 53% Leader/follower814 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 minmax worker 39.5ms 5.5ms9s 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
Re: Performance comparison for worker, leader/follower, and threadpool MPMs
Justin Erenkrantz wrote: 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 Here are the prefork numbers... Based on all this data, I think leader/follower is the best candidate for the next-generation Unix MPM. I'm going to refocus my efforts on turning leader/follower into production-quality code. --Brian httpd listening on one port: Requests/ Mean request CPU CPU MPM second time (ms)loadutilization --- Threadpool854 55.5 4.8 52% Leader/follower 957 39.5 6.8 72% Worker892 31.4 7.0 70% Prefork 899 32.9 7.3 76% httpd listening on two ports: Requests/ Mean request CPU CPU MPM second time (ms)loadutilization --- Threadpool 848 54.5 4.8 53% Leader/follower814 58.4 4.5 51% Worker 881 47.7 5.1 59% Prefork760 62.9 3.7 43%
