RE: pending connections

Hi Ron,

I'm doing much the same thing, and have some similar experiences in this
area.  Here are some thoughts and questions:

1) Use PHP for all the non-time critical processing (user signup, user
admin, etc).

2) Store session info in either shared memory or the database - this allows
PHP, to get to the same session info as the chat itself.  This means that
you can, for example, cancel user sessions via PHP.  (If you use shared
memory - which is great for performance - plan on using a mutex coordinate
access to the shared memory).

3) In the fastcgi examples directory there is a sample 'threaded'
application.  I'm convinced this is the perfect model on which to base the
chat. (Also, this suggests that I believe multi-threaded is, in fact,
critical).  The problem with non multi-threaded is that eventually you'll
want to do something a little processing-intensive with some chat
messages, and you don't it to inject a delay for all users).

Don't be afraid of going multi-threaded - just be sure to have a grasp
of using mutexes to serialize execution of critical sections (such as
adding messages to chat rooms).  The threaded example shows how to use
mutexes as well.

Hope these thoughts help you to avoid making some tactical mistakes I've
made in the past!

-Rich

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