RE: FastCGI errors after timeout

>> 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. <<

If this is the case then how does the fcgi process manager know when to
not accept requests beyond the figure set with the "-listen-queue-depth
XXX" directive?

 

 

________________________________

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: 30 December 2004 01:43
To: fastcgi-developers-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org; Karl Skidmore
Subject: RE: [FASTCGI] 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-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/