RE: pending connections

I have a similar solution in mind as Andrej.  

I want to have 100 clients talking simultaneously to a chat-like server and
I want to avoid using a true client connection (e.g., a java applet).  I
plan to do everything using sockets and php.  The 100 clients would then be
connected to the chat server by virtue of a web page with an invisible frame
that creates the connection.  I would also do "tricks" to maintain the
connection, but for a variable amount of time (initially 30 seconds) that I
hoped to optimize from experience.  More tricks would allow me to then
reload the frame and establish a new socket connection without losing any
client data known to the chat server.  

I didn't think this type of architecture fit with mod_php, so I hoped to use
fast-cgi for the process that runs in the frame.  This is based on my hope
that there was a reason I could find so many references containing the words
"fast-cgi" and "long-lived process".

The other part of my hope is that I read that there is no reason to use
threads on a modern Linux system when process would achieve the same thing,
100 simultaneous processes being quite manageable.  So I'd planned on having
100 of my fast-cgi process executing simultaneously, 1 process for each
user.

Is there any chance for success with this kind of setup?


-----Original Message-----
From: fastcgi-developers-bounces+ron=rudman.org-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org
[mailto:fastcgi-developers-bounces+ron=rudman.org-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org] On
Behalf Of David Birnbaum
Sent: Tuesday, November 29, 2005 10:45 AM
To: Richard Bryant
Cc: fastcgi-developers-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org
Subject: Re: [FASTCGI] pending connections

FastCGI is generally set up to reduce startup time overhead and efficientcy.

Obviously, you could make it multi-threaded, but if each application is
going to run for 20 minutes on one request (or set of requests), then the
startup time of a second or two becomes immaterial.  If 1,000 people hit the
appliation in 20 minutes, that's a thousand threads.  Depending on your
memory overhead and such, it might work fine, but ultimately, I would
probably ask, why not just plain CGI
- or, more importantly, how can I rewrite this application (session
management,
perhaps?)  You're going to tie up httpd processes also, which makes it sound
very unscalable at any sort of normal load.

David.

-----

On Tue, 29 Nov 2005, Richard Bryant wrote:

> Hi David,
>
> I'm wondering if Andrej's application might work wtih FastCGI, provided it
is 
> written to be multi-threaded.
>
> Having read the FastCGI documentation it seems to me that the rule of
thumb 
> for a multi-threaded app is necessary
> if an individual request an require an inordinate amount of time to
process.
>
> -Rich
>
> At 08:31 AM 11/29/2005, David Birnbaum wrote:
>> Andrej,
>> 
>> If you have only one fast-cgi instance, and send 100 requests, the other
99 
>> will block in httpd waiting for the accept() to the FastCGI socket to 
>> succeed. Whether or not they timeout is a function of the client browser,

>> your httpd/fastcgi settings, etc.  The number of requests that can wait 
>> before getting connection refused is defined by the request queue
(defaults 
>> to your TCP wait queue, I think, but changable with a FastCGI parameter).
>> 
>> However, keep in mind that the keepalive to the client is usually handled

>> by the httpd process, not by the FastCGI process.  In an ideal world, the

>> httpd handles the response to the request, and the FastCGI process is
then 
>> free to process the next response.
>> 
>> The application you describe would not be a good match for FastCGI.
>> 
>> David.
>> 
>> -----
>> 
>> On Tue, 29 Nov 2005, Andrej van der Zee wrote:
>> 
>>> Hi,
>>> 
>>> I have a question about pending connections. Suppose I have only one 
>>> fast-cgi instance running and I send simultaneously 100 requests. Now
the 
>>> first request that is accepted takes 20 minutes. We will do some tricks
to 
>>> keep the connection to the client alive. What happens to the pending 99 
>>> requests? Are they being timeout by the kernel before they will be 
>>> accepted by fast-cgi? Does anybody has experience with this? I am
working 
>>> on a 2.6.12+ kernels.
>>> 
>>> Greets,
>>> 
>>> Andrej
>>> 
>>> 
>>> ___________________________________
>>> fastcgi-developers mailing list
>>> http://fastcgi.com/fastcgi-developers/
>> 
>> 
>> ___________________________________
>> fastcgi-developers mailing list
>> http://fastcgi.com/fastcgi-developers/
>
>

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