Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 83598 invoked from network); 10 Feb 2004 15:24:48 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 10 Feb 2004 15:24:48 -0000 Received: (qmail 55926 invoked by uid 500); 10 Feb 2004 15:24:26 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 55881 invoked by uid 500); 10 Feb 2004 15:24:26 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 55858 invoked from network); 10 Feb 2004 15:24:26 -0000 Received: from unknown (HELO prv-mail20.provo.novell.com) (137.65.81.122) by daedalus.apache.org with SMTP; 10 Feb 2004 15:24:26 -0000 Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 10 Feb 2004 08:24:28 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 10 Feb 2004 08:24:15 -0700 From: "Jean-Jacques Clar" To: Subject: Re: 2.0.48 worker mpm on RH3 NPTL results Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part78591D8F.0__=" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part78591D8F.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Joe, You will probably need more info, but if you have time give it a try and if you run into problems we could contact greg ames from the ASF. Thanks, JJ >>> gregames@apache.org 1/12/2004 9:45:50 AM >>> Jean-Jacques Clar wrote: > Attached are 2.0.48 numbers on RH AS 2.1 and 3.0. > Apache is build with worker MPM and default options on both versions. Thanks for posting these measurements. I was happy to see that performance stays pretty flat as the system got overloaded. The AS 3.0 8 CPU curve sags a little but it's not too bad. What did you use for ThreadsPerChild? The default? It's 25. The reason I ask is I did some scalability measurements maybe a year ago and saw a lot of CPU usage in linuxthreads with a high number (maybe 1000) for ThreadsPerChild. It was in some pthread mutex unlock function, doing a serial search for the highest priority thread to wake up. This is pointless in our case because all the worker threads are the same priority. I'm hoping that this problem is fixed in the new pthread library, but haven't verified it. > C: > Apache is servicing more requests per sec on 2.1 on 1 and 2 CPUs, 3.0 is > picking up the slack between 2 and 4 CPUs. > Prefork still serving static requests faster than worker (6300 req/sec > on RH 2.1 on 8 CPUs). I'm very curious to know why prefork is beating worker. Could you get a profile of the CPU usage for both cases? I've had good luck with oprofile. I had a little trouble compiling its kernel module on RH AS 2.1 due to 2.5 kernel features that RedHat backported, but you can edit oprofile's module/compat.h to get around that. Greg --=__Part78591D8F.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Joe,
 
You will probably need more info, but if you have time give it a try = and
if you run into problems we could contact greg ames from the = ASF.
Thanks,
JJ


>>> gregames@apache.org 1/12/2004 9:45:50 AM = >>>
Jean-Jacques Clar wrote:

> = Attached are 2.0.48 numbers on RH AS 2.1 and 3.0.
> Apache is build = with worker MPM and default options on both versions.

Thanks for = posting these measurements.  I was happy to see that performance =
stays pretty flat as the system got overloaded.  The AS 3.0 8 CPU = curve sags a
little but it's not too bad.

What did you use for = ThreadsPerChild?  The default?  It's 25.  The reason I ask =
is I did some scalability measurements maybe a year ago and saw a lot = of CPU
usage in linuxthreads with a high number (maybe 1000) for = ThreadsPerChild.  It
was in some pthread mutex unlock function, = doing a serial search for the highest
priority thread to wake = up.  This is pointless in our case because all the
worker threads = are the same priority.  I'm hoping that this problem is fixed in =
the new pthread library, but haven't verified it.

> = C:
> Apache is servicing more requests per sec on 2.1 on 1 and 2 = CPUs, 3.0 is
> picking up the slack between 2 and 4 CPUs.
> = Prefork still serving static requests faster than worker (6300 req/sec =
> on RH 2.1 on 8 CPUs).

I'm very curious to know why prefork = is beating worker.  Could you get a profile
of the CPU usage for = both cases?  I've had good luck with oprofile.  I had a =
little trouble compiling its kernel module on RH AS 2.1 due to 2.5 = kernel
features that RedHat backported, but you can edit oprofile's = module/compat.h to
get around that.

Greg

--=__Part78591D8F.0__=--