RE: Regarding worker MPM and queue_push/pop

2003-12-07 Thread MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)
Hi, Just wanted to update y'all - I traced down the bottleneck to mod_specweb99.c. The bottleneck is caused by the POST & CAD_GET transactions. If I eliminate the POST & CAD_GET from the SPECweb99 requests, I don't see any spiky activity - the CPU usage is steady at 100%. More comm

Re: Regarding worker MPM and queue_push/pop

2003-12-05 Thread Aaron Bannert
On Wed, Dec 03, 2003 at 11:38:25PM -0800, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: > A first guess is that I'm using SysV semaphores, and a semlock can bring > down the entire httpd to crawl. I'm re-compiling using pthread mutexes > whenever possible. Depending on the implementation in you

RE: Regarding worker MPM and queue_push/pop

2003-12-04 Thread MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)
>-Original Message- >From: Jeff Trawick [mailto:[EMAIL PROTECTED] [SNIP] > >While researching the AIX issue affecting mod_cgid, in which >kill() would not >report that a process was gone until up to 1 second after it >exited*, I >constructed a test program to expose the delay without u

Re: Regarding worker MPM and queue_push/pop

2003-12-04 Thread Jeff Trawick
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: Here is the fix for AIX: http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/generators/ mod_cgid.c.diff?r1=1.158&r2=1.159 Thanks - I'll try it out right away. While researching the AIX issue affecting mod_cgid, in which kill() would not report th

RE: Regarding worker MPM and queue_push/pop

2003-12-04 Thread MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)
>-Original Message- >From: Bill Stoddard [mailto:[EMAIL PROTECTED] [SNIP] >Are you using CGI scripts? (an aside... if so better be >using mod_cgid rather than mod_cgi with worker). Jeff may >have already pointed out to you a "feature" in the >AIX that would keep threads hanging around

Re: Regarding worker MPM and queue_push/pop

2003-12-04 Thread Bill Stoddard
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: I sure would do that sometime today. The leader probably uses some apr_atomic stuff - and I'm trying to see if I can use IA64 native code to do the atomics. For people at ease with visual stuff, here's the CPU performance that I'm getting with worker

RE: Regarding worker MPM and queue_push/pop

2003-12-04 Thread MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)
December 04, 2003 10:52 AM >To: [EMAIL PROTECTED] >Subject: Re: Regarding worker MPM and queue_push/pop > > > >On Dec 4, 2003, at 9:18 AM, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) >wrote: > >> >>> -Original Message- >>> From: Cliff Woolle

Re: Regarding worker MPM and queue_push/pop

2003-12-04 Thread Brian Pane
On Dec 4, 2003, at 9:18 AM, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: -Original Message- From: Cliff Woolley [mailto:[EMAIL PROTECTED] [SNIP] On Wed, 3 Dec 2003, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: instead of having the worker threads compete for the incoming connectio

RE: Regarding worker MPM and queue_push/pop

2003-12-04 Thread MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)
>-Original Message- >From: Cliff Woolley [mailto:[EMAIL PROTECTED] [SNIP] >On Wed, 3 Dec 2003, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: > >> instead of having the worker threads compete for the >incoming connections >> (using ap_queue_pop .. and hence mutex_lock), assign the >conn

Re: Regarding worker MPM and queue_push/pop

2003-12-04 Thread Cliff Woolley
On Wed, 3 Dec 2003, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: > instead of having the worker threads compete for the incoming connections > (using ap_queue_pop .. and hence mutex_lock), assign the connection to the > next free thread on a round-robin basis - if I'm not wrong, zeus does > som