RE: FastCGI errors after timeout

There is no FCGI queue per-say, AFAIK. The queue is implemented through
your operating system. If the FCGI does not accept a connection, the operating
system will then backlog (queue) the connection and the connection becomes
pending. This queue implementation differs from platform to platform and between
Unix / TCP/IP sockets. Given this, there is no easy way for a FCGI to know
when a connection is made and pending; the FCGI is not aware of pending
connections. Also, because of this, it is not always possible to time FCGI requests
from client side.

Keep in mind, a queue does not increase throughput, it only delays the request
instead of dropping it. The queue is basically a way to handle request spikes
when there are not enough FCGI processes. A few FCGI processes and a large
queue would mean slower response time and potential timeout errors. It is best
to always have enough FCGI processes and a large enough queue to handle
spikes. You can figure this out based on the number of requests you need to
process and the amount of time it takes to process each request.

-Simon

--Original Message Text---
From: Karl Skidmore
Date: Wed, 29 Dec 2004 08:21:27 -0000

v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} 

>>  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-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org] 
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/