httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <mad...@hp.com>
Subject RE: Regarding Apache 2.0.48 and specweb99
Date Tue, 02 Dec 2003 17:06:47 GMT

>-----Original Message-----
>From: gregames@apache.org [mailto:gregames@apache.org]
[SNIP]

>I'm glad you're making progress.  But I'm wondering why 
>raising the mod_cgid 
>Listen backlog was so important.  If 100 mod_cgid connections 
>wasn't enough at 
>some point, either the workload is spikey or the steady state 
>arrival rate of 
>CGI requests is too fast for one daemon + your SPECweb99 CGI 
>program to keep up.


I was probably driving the server pretty hard for CGI's. The avg. number of
forks per second were around 15..20 - but often, the forks went up to
35..40. It was a few times that the no. of forks went as high as 90 - and
soon, I started getting the 503 messages.

I think the CGI daemon listen backlog can also be a configurable number - I
can post a patch if people think itz useful.

>
>If the latter is true, you should see more and more CGI 
>requests building up 
>over time in server-status with ExtendedStatus on, and a big 
>improvement in 
>throughput if you set DYNAMIC_CGI_GET=0 in the SPEC rc file.

Your evaluation is correct - the throughput definitely improved when I set
DYN_CGI to 0.. AND some cgi requests took as high as 900 ms (the static file
took 0.0 ms!!). 

 
>Then it would be 
>worthwhile using tusc/strace/truss with some timing options 
>set to look for 
>unnecessary delays in mod_cgid. 

I can capture the tusc output from cgi daemon on the next run and post it
here.

>If that doesn't show a problem, perhaps we 
>should have multiple cgid daemons running in parallel for best 
>throughput. 
>Someone brought up that idea a while back on dev@httpd; 
>cross-posting there.

That's a pretty neat idea - I'll have to think about it.

-Madhu

Mime
View raw message