Ok so mod_status helped me make an interesting observation :

There is only one child picking up the request for sleep.cgi when i
launch it new in new tabs/ new windows, rest are children all waiting,
and picking the next requests when this one gets done .

Srv     PID     Acc     M       CPU     SS      Req     Conn    Child   Slot    
Client  VHost   Request
0-0     20815   0/0/0   W       0.00    0       684599440       0.0     0.00    
0.00
        127.0.0.1       127.0.1.1       GET /server-status HTTP/1.1
1-0     20816   0/0/0   W       0.00    36      684635474       0.0     0.00    
0.00
        127.0.0.1       127.0.1.1       GET /cgi-bin/sleep.cgi HTTP/1.1

However clicking that one link on the page again and again launches up
new processes with no restraint. here below ( same link clicked again
and again )
and the same child pid is responsible for launching up new instances
of sleep.cgi ( 20815, 20816 )

0-0     20815   0/0/0   W       0.00    7       684077228       0.0     0.00    
0.00
        127.0.0.1       127.0.1.1       GET /cgi-bin/sleep.cgi HTTP/1.1
0-0     20815   0/0/0   W       0.00    6       684076661       0.0     0.00    
0.00
        127.0.0.1       127.0.1.1       GET /cgi-bin/sleep.cgi HTTP/1.1
0-0     20815   0/0/0   W       0.00    5       684076206       0.0     0.00    
0.00
        127.0.0.1       127.0.1.1       GET /cgi-bin/sleep.cgi HTTP/1.1
1-0     20816   1/1/1   W       0.00    7       0       0.1     0.00    0.00    
127.0.0.1       127.0.1.1       GET
/cgi-bin/sleep.cgi HTTP/1.1
1-0     20816   0/0/0   W       0.00    6       684076898       0.0     0.00    
0.00
        127.0.0.1       127.0.1.1       GET /cgi-bin/sleep.cgi HTTP/1.1
1-0     20816   0/0/0   W       0.00    6       684076442       0.0     0.00    
0.00
        127.0.0.1       127.0.1.1       GET /cgi-bin/sleep.cgi HTTP/1.1
1-0     20816   0/0/0   W       0.00    0       684070224       0.0     0.00    
0.00
        127.0.0.1       127.0.1.1       GET /server-status HTTP/1.1

The apache conf , I have attached here.


Let me know , what else could help

Thanks
Digz

On Wed, Jul 29, 2009 at 8:52 AM, Chandranshu .<[email protected]> wrote:
> Hi Digz
>
> Meanwhile, when you say that "apache will not service any other CGI
> requests", what exactly do you mean? Did you mean that your further HTTP
> requests returned with 503 or some other error code? Or do they just wait
> around for a long time before returning any data?
>
> You should enable mod_status with "ExtendedStatus On" and check whether your
> requests are taken up for processing by the httpd server. Please send the
> output generated by mod_status along with the apache config if your problem
> remains unsolved.
>
> Best of Luck
> Chandranshu
>
> On Wed, Jul 29, 2009 at 5:41 PM, Digvijoy Chatterjee <[email protected]>
> wrote:
>>
>> Hi,
>>
>> We are running apache 2.0.35 on RHEL4 running in prefork mode.
>> Its a standard apache configuration for running cgi scripts. I can
>> send it if required
>>
>> The behaviour we are observing with apache is after servicing 2 cgi
>> requests which (do a long database lookup ~5 minutes)
>> apache will not service any other cgi requests until one of the above come
>> back.
>>
>> I have tried using RLimitNPROC, RlimitCPU , and RLimitMEM and even set
>> them to max,
>> but it does not affect the behavior.
>>
>> apache runs as www.
>>
>> Any clues ?
>>
>> --Digz
>>
>> ---------------------------------------------------------------------
>> The official User-To-User support forum of the Apache HTTP Server Project.
>> See <URL:http://httpd.apache.org/userslist.html> for more info.
>> To unsubscribe, e-mail: [email protected]
>>   "   from the digest: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
>

Attachment: apache2.conf
Description: Binary data

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: [email protected]
   "   from the digest: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to