FastCGI and PHP

[Phillip B Oldham]

Thanks Igor. That makes lots of sense. I appreciate your time.

I'll grab a copy of the fastcgi server code, read the spec, and start 
playing around!

Igor Clark wrote:
> Hi Philip,
>
> 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 
> http://www.fastcgi.com/devkit/doc/fcgi-spec.html
>
> 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.
>
> 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.
>
> There's further discussion of this and FastCGI in general at 
> http://thread.gmane.org/gmane.comp.web.nginx.english/2974/focus=2974
>
> cheers,
> Igor
>
> On 2 Apr 2008, at 08:08, Phillip B Oldham wrote:
>
>> 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?
>>
>> 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.
>>
>> 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.
>>
>> I'm also unsure as to how nginx passes through the fastcgi params we 
>> configure.
>>
>> 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.
>>
>> Thanks.
>> -- 
>>
>> *Phillip B Oldham*
>> The Activity People
>> phill at theactivitypeople.co.uk <mailto:phill at theactivitypeople.co.uk>
>>
>> ------------------------------------------------------------------------
>>
>> *Policies*
>>
>> 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.
>>
>> 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.
>>
>> ------------------------------------------------------------------------
>> <phill.vcf>
>
> -- 
> Igor Clark • POKE • www.pokelondon.com
>
>
>
>
>

-- 

*Phillip B Oldham*
The Activity People
phill at theactivitypeople.co.uk <mailto:phill at theactivitypeople.co.uk>

------------------------------------------------------------------------

*Policies*

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.

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.

------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20080402/127f5d40/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: phill.vcf
Type: text/x-vcard
Size: 261 bytes
Desc: not available
URL: <http://nginx.org/pipermail/nginx/attachments/20080402/127f5d40/attachment.vcf>