RE: pending connections

Rich,

Thanks for your response - very encouraging.  I still seem to have some gaps
in my understanding, as I'm sure will be evident from the following
statements/questions:

How many fastcgi process do I need here?   I would be running PHP as a
fastcgi, so there's one.  Generally, to share session information in an
application it looks like I can roll my own using a database or shared
memory, but what about the infamous session-affinity patch?  It's no clear
if I would be using session_start() etc. or if I would create my own
protocol for sessions.

In my chat application there's chat-server concept, and I can't figure out
if this is fastcgi or not.  This seems doable as a standalone PHP process
that accepts socket connections and manages some data about each connection.
In this case, my web page would need a frame that invoked a fastcgi to get
the chat-client concept.  The webserver would get the chat-client running,
then the chat-client would connect to the chat-server.  OR...should I be
thinking in terms of the chat-server being a fastcgi and the web page
invoking that?  

The crux of what I'm trying to do is to have the chat-server send messages
to a selected set of chat-clients as necessary (e.g., whoever is in a
specific chat room), while the chat-clients are permanently connected to the
chat-server.  I don't want a chat-client to have to poll periodically to see
if there
are any messages for it - I want the chat-client sitting at an accept().
Upon receipt of a message, the chat-client would have to echo a Javascript
function call to affect the visible part of the page, then reload and wait
for another message.  This seems to imply that the chat-client has to be in
a separate frame from the frame that initiated the connection, and has to
get the connection resource to listen on from a session variable.  Of
course, each chat-client has to be able to send messages to the chat-server
too, but I think that part can be done with Ajax or something similar.  In
other words, my use of the word "connection" is - I think - a different
connection from how the webserver connects to the fastcgi process.

Finally, I'm trying to do this with only PHP, which seems to have all the
socket functions and support I need.  Or am going to have to do some of this
in C?


-----Original Message-----
From: rbryant-lIMM5TLcLRBvBvnq28/[email protected] [mailto:rbryant-lIMM5TLcLRBvBvnq28/[email protected]] 
Sent: Wednesday, November 30, 2005 10:16 PM
To: Ron Rudman
Cc: 'David Birnbaum'; 'Richard Bryant';
fastcgi-developers-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org
Subject: [SPAM] RE: [FASTCGI] 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/