You are viewing a plain text version of this content. The canonical link for it is here.
Posted to test-dev@httpd.apache.org by "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <ma...@hp.com> on 2003/12/02 02:20:27 UTC
RE: Regarding Apache 2.0.48 and specweb99
I think I found the problem (.. and it's not the cgid exiting problem).
The problem was because the default Listen Backlog in mod_cgid was a little
small (100 outstanding connections). I got the following tusc log for the
httpd processes :
{62717} connect(13, 0x9fffffffbebbfe60, 94) .............. ERR#239
ECONNREFUSED
{62849} connect(29, 0x9fffffffbdcbfea0, 94) .............. ERR#239
ECONNREFUSED
I increased listen backlog and the processes are a little more happy now :)
BTW, I had to increase the "ListenBacklog" for httpd also - the default 512
caused too many "Can't connect" errors. I increased it to 1024.
-Madhu
>-----Original Message-----
>From: gregames@apache.org [mailto:gregames@apache.org]
>Sent: Monday, November 24, 2003 1:48 PM
>To: test-dev@httpd.apache.org
>Subject: Re: Regarding Apache 2.0.48 and specweb99
>
>
>MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
>> Hmmn. Interesting.
>>
>> 1. Did you include the cgid restart fix ?
>
>I don't think so. It's the httpd-2.0.48 tarball + mod_specweb99.
>
>> 2. Are you driving the server with the SPECweb99 recommended
>CGI load ?
>
> DYNAMIC_CGI_GET=.005
>
>I believe that's the standard.
>
>Looking at server-status, I see the CGI URIs dominating the
>active server
>threads even with this tiny percentage of the total workload.
>I'm using the
>perl script shipped with SPECweb99. An obvious improvement
>would be to use a
>compiled C implementation. But I'm not very interested in
>setting records or
>making CGIs run fast. I'm more interested in speeding up
>mod_specweb99 and base
>Apache.
>
>> 3. do you mind posting the httpd.conf
>
>attached.
>
> > Oh.. BTW I hope you're also using worker MPM .
>
>[gregames@monkey built]$ bin/httpd -l
>Compiled in modules:
> core.c
> worker.c
> http_core.c
> mod_suexec.c
> mod_so.c
>
>Greg
>
Re: Regarding Apache 2.0.48 and specweb99
Posted by gr...@apache.org.
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
> I think I found the problem (.. and it's not the cgid exiting problem).
>
> The problem was because the default Listen Backlog in mod_cgid was a little
> small (100 outstanding connections). I got the following tusc log for the
> httpd processes :
>
> {62717} connect(13, 0x9fffffffbebbfe60, 94) .............. ERR#239
> ECONNREFUSED
> {62849} connect(29, 0x9fffffffbdcbfea0, 94) .............. ERR#239
> ECONNREFUSED
>
> I increased listen backlog and the processes are a little more happy now :)
>
> BTW, I had to increase the "ListenBacklog" for httpd also - the default 512
> caused too many "Can't connect" errors. I increased it to 1024.
>
> -Madhu
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.
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. Then it would be
worthwhile using tusc/strace/truss with some timing options set to look for
unnecessary delays in mod_cgid. 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.
Greg
Re: Regarding Apache 2.0.48 and specweb99
Posted by gr...@apache.org.
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
> I think I found the problem (.. and it's not the cgid exiting problem).
>
> The problem was because the default Listen Backlog in mod_cgid was a little
> small (100 outstanding connections). I got the following tusc log for the
> httpd processes :
>
> {62717} connect(13, 0x9fffffffbebbfe60, 94) .............. ERR#239
> ECONNREFUSED
> {62849} connect(29, 0x9fffffffbdcbfea0, 94) .............. ERR#239
> ECONNREFUSED
>
> I increased listen backlog and the processes are a little more happy now :)
>
> BTW, I had to increase the "ListenBacklog" for httpd also - the default 512
> caused too many "Can't connect" errors. I increased it to 1024.
>
> -Madhu
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.
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. Then it would be
worthwhile using tusc/strace/truss with some timing options set to look for
unnecessary delays in mod_cgid. 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.
Greg