>-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] [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 [EMAIL PROTECTED]; >cross-posting there. That's a pretty neat idea - I'll have to think about it. -Madhu
