<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=windows-1252"
 http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="-1"><font face="Helvetica, Arial, sans-serif">Thanks Igor.
That makes lots of sense. I appreciate your time.<br>
<br>
I'll grab a copy of the fastcgi server code, read the spec, and start
playing around!<br>
</font></font><br>
Igor Clark wrote:
<blockquote
 cite="mid:FFC70AF2-B447-4850-A735-A273CF3B475E@pokelondon.com"
 type="cite">Hi Philip,
  <br>
  <br>
I'm not sure about the way PHP-fcgi manages its processes internally,
but there's some detail about the way the FastCGI communication happens
in the FastCGI protocol spec at
<a class="moz-txt-link-freetext" href="http://www.fastcgi.com/devkit/doc/fcgi-spec.html">http://www.fastcgi.com/devkit/doc/fcgi-spec.html</a>
  <br>
  <br>
In short, the protocol works by exchanging FCGI "records" between the
client and server which are basically chunks of information wrapped up
in FCGI "messages". Each message header identifies itself including a
request ID and a record type, allowing the client and server to
establish input, output and error streams. The web server (FastCGI
client) passes the normal CGI/1.1 environment variables (configured by
nginx as fastcgi_params) to the FastCGI server's input stream, and the
FastCGI server returns the request's output to the web server via its
output stream. Any errors should be passed back via the error stream.
  <br>
  <br>
There is scope in the protocol for multiplexing these connections, i.e.
communicating multiple requests and responses across the same
connection and identifying each by its request ID, but there seems to
be no flow control built into the protocol, making this a somewhat
dangerous proposition. As I understand it the protocol also allows for
long-lived FastCGI connections which are re-used for multiple
request/response cycles, but this isn't possible with nginx currently
as it uses HTTP/1.0 to talk to upstream servers; additionally, the
upstream server might be overwhelmed if nginx made hundreds of
long-standing connections to it.
  <br>
  <br>
There's further discussion of this and FastCGI in general at
<a class="moz-txt-link-freetext" href="http://thread.gmane.org/gmane.comp.web.nginx.english/2974/focus=2974">http://thread.gmane.org/gmane.comp.web.nginx.english/2974/focus=2974</a>
  <br>
  <br>
cheers,
  <br>
Igor
  <br>
  <br>
On 2 Apr 2008, at 08:08, Phillip B Oldham wrote:
  <br>
  <br>
  <blockquote type="cite">After the recent thread on php-fastcgi and
memory leaks, I've realised that I'm a little unsure as to exactly how
nginx and php-fastcgi communicate with one another. I'm wondering
whether anyone could spare the time for clarification?
    <br>
    <br>
I understand that when started (in my case using spawn-fastcgi from the
lighttpd project) php-fastcgi creates a master process and a number of
child processes. Nginx then passes requests through to php-fastcgi,
which processes the request and returns a response.
    <br>
    <br>
What I'm unsure on is whether nginx is passing the request directly to
one of the child processes or the master process which then delegates.
    <br>
    <br>
I'm also unsure as to how nginx passes through the fastcgi params we
configure.
    <br>
    <br>
The reason I ask is that I have some useful components written in
Eiffel which I'd like to make available via a webserver. I've found a
small fastcgi server written in Eiffel, which I'd like to expand on to
replicate the kind of through-put the php-fastcgi instance I'm running
allows.
    <br>
    <br>
Thanks.
    <br>
-- <br>
    <br>
*Phillip B Oldham*
    <br>
The Activity People
    <br>
<a class="moz-txt-link-abbreviated" href="mailto:phill@theactivitypeople.co.uk">phill@theactivitypeople.co.uk</a>
<a class="moz-txt-link-rfc2396E" href="mailto:phill@theactivitypeople.co.uk">&lt;mailto:phill@theactivitypeople.co.uk&gt;</a>
    <br>
    <br>
------------------------------------------------------------------------
    <br>
    <br>
*Policies*
    <br>
    <br>
This e-mail and its attachments are intended for the above named
recipient(s) only and may be confidential. If they have come to you in
error, please reply to this e-mail and highlight the error. No action
should be taken regarding content, nor must you copy or show them to
anyone.
    <br>
    <br>
This e-mail has been created in the knowledge that Internet e-mail is
not a 100% secure communications medium, and we have taken steps to
ensure that this e-mail and attachments are free from any virus. We
must advise that in keeping with good computing practice the recipient
should ensure they are completely virus free, and that you understand
and observe the lack of security when e-mailing us.
    <br>
    <br>
------------------------------------------------------------------------
    <br>
&lt;phill.vcf&gt;
    <br>
  </blockquote>
  <br>
--
  <br>
Igor Clark • POKE • <a class="moz-txt-link-abbreviated" href="http://www.pokelondon.com">www.pokelondon.com</a>
  <br>
  <br>
  <br>
  <br>
  <br>
  <br>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<div
 style="font-family: sans-serif; font-style: normal; font-variant: normal; font-weight: normal; font-size: 12px; line-height: 1.1; font-size-adjust: none; font-stretch: normal; width: 300px; color: rgb(51, 51, 51);">
<p><strong>Phillip B Oldham</strong><br>
The Activity People<br>
<a href="mailto:phill@theactivitypeople.co.uk">phill@theactivitypeople.co.uk</a></p>
<hr size="1">
<p style="font-size: 90%;"><strong>Policies</strong></p>
<p style="font-size: 90%;">This e-mail and its attachments are intended
for the above named recipient(s) only and may be confidential. If they
have come to you in error, please reply to this e-mail and highlight
the error. No action should be taken regarding content, nor must you
copy or show them to anyone.</p>
<p style="font-size: 90%;">This e-mail has been created in the
knowledge that Internet e-mail is not a 100% secure communications
medium, and we have taken steps to ensure that this e-mail and
attachments are free from any virus. We must advise that in keeping
with good computing practice the recipient should ensure they are
completely virus free, and that you understand and observe the lack of
security when e-mailing us.</p>
<hr size="1">
</div>
</div>
</body>
</html>