RE: FastCGI errors after timeout

>> So, make sure your queue is large enough and that there is enough
FCGI serving processes, <<

 

Is there anyway for an fcgi script to ascertain (from request structures
or the environment) the time at which a request was added to the fastcgi
queue and the length of that queue at the time (or the length at the
time the request was taken off the queue)?  A company called
fast-engines used to provide this info with their proprietary fcgi
implementation and this helped determine the correct numbers of cgis to
run for normal and flash-flood operation.

 

Cheers... Karl

 

________________________________

From: fastcgi-developers-bounces+karl=multimap.com-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org
[mailto:fastcgi-developers-bounces+karl=multimap.com-xGejAJT2w6xVgU18Zptdi4jBFkejb+Ym@public.gmane.orgm
] On Behalf Of Simon
Sent: 29 December 2004 05:13
To: Allen; fastcgi-developers-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org
Subject: Re: [FASTCGI] FastCGI errors after timeout

 


When all FCGI processes are busy and queue is full, you will receive:
FastCGI: failed to connect to server

So, make sure your queue is large enough and that there is enough FCGI
serving processes, otherwise what you describe will occur. The best
approach
is to make sure your FCGI requests do not take longer than few seconds
to complete or you will need many FCGI processes to make things
scalable.
Also, if your FCGI processes get stuck, no matter how many FCGI
processes
you have, it will be very easily to DoS your FCGI pool.

-Simon


On Tue, 28 Dec 2004 21:18:05 -0500, Allen wrote:

>We been using FastCGI (mod_fastcgi) for a year and it has been working 
>great. Recently and without configuration changes, we've experienced a 
>problem.
>
>After a "timeout" condition (a transaction exceeded the 30-sec limit), 
>successive transactions caused FastCGI "failed to connect to server" 
>errors in the apache error_log, and eventually the CGI processes 
>starting to die after the first execution. After an apache graceful 
>restart, the problem goes away until the timeout occurs again.
>
>Anyone have this problem, solutions or suggestions?
>
>Details:
>
>We use FastCGI to invoke a Perl process to handle straightforward API 
>calls to our system. This api-server process stays resident and 
>persistent and holds onto database connections to remove the overhead
of 
>a large number of database connects and Perl runtime initialization.
>
>The api-server itself is configured to self-end after 10 minutes of 
>runtime, to keep things "fresh". FastCGI automatically starts another 
>process when this occurs, and it all works wonderfully.
>
>Due to other long-running database-related processes on the system, 
>there comes a time where the PostgreSQL database becomes unresponsive 
>for a period of about 4 minutes at a time. This is certainly not 
>desirable, and we are also working to resove this issue.
>
>However, when this occurs, the currently executing FastCGI transaction 
>is blocked for the 4 minutes before it returns. The timeout of FastCGI 
>is set to the default 30 seconds, and it detects the timeout condition.

>The following error messages result:
>
> [Thu Dec 16 22:06:56 2004] [error] [client xxx.xxx.xxx.xx]
> FastCGI: comm with (dynamic) server
> "/path/bl-api-server.fpl"
> aborted: (first read) idle timeout (30 sec)
> [Thu Dec 16 22:06:56 2004] [error] [client xxx.xxx.xxx.xx]
> FastCGI:incomplete headers (0 bytes) received from server
> "/path/bl-api-server.fpl"
>
>After that each transaction encounters the same problem and
occasionally 
>this error:
>
> [Sun Dec 19 05:59:42 2004] [error] [client 207.218.164.32]
> (61)Connection refused: FastCGI: failed to connect to server
> "/path/bl-api-server.fpl": connect() failed
> [Sun Dec 19 05:59:42 2004] [error] [client 207.218.164.32]
> FastCGI: incomplete headers (0 bytes) received from server
> "/path/bl-api-server.fpl"
>
>During this period, FastCGI keeps starting api-server processes which 
>run the transacation successfully, but then disappear. It does not 
>appear that the process is ending naturally, but I suspect there maybe 
>in issue with the Perl interface to FastCGI in holding the connection
to 
>the parent process.
>
>After an apache graceful restart, the problem goes away.
>
>On inspection of the api-server logs, each transaction was properly 
>started and successfully executed, most within a second each. The error

>message after the response problem cleared continued to appear although

>the process did finish normally and long before the timeout period. I
am 
>not certain if the result HTTP page response was properly sent, though
I 
>assume not from these messages.
>
>We are currently running FreeBSD 4.6.2-RELEASE-p2, FastCGI verion 
>mod_fastcgi-2.4.2, Apache 1.3.26, Perl version 5.005_03, and Perl 
>interface to FastCGI veriosn $CGI::Fast::VERSION='1.01';
>
>Thanks,
>Allen
>___________________________________
>fastcgi-developers mailing list
>http://fastcgi.com/fastcgi-developers/
>

___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/