Hello Denis!

Thanks for your explanations.

2009/10/13 Denis F. Latypoff <denis@gostats.ru>:
> Tuesday, October 13, 2009, 9:20:00 PM, you wrote:
>> Is there no such option just because nobody implemented it? Or is it
>> because of some kind of technical constraint?
>
> Yes. It's because of FastCGI protocol internals. It splits "stream"
> into blocks max 32KB each. Each block has header info (how many bytes
> it contains, etc). So nginx can't send content to the client until it
> get the whole block from upstream.

I agree that when a FastCGI backend sends a record to the web server,
the web server must wait for the complete record before forwarding it
to the client. This implies a lot of buffering if the records sent by
the FastCGI backend are very long.

Alternatively, the FastCGI backend can choose to send very short
records (for example 50 bytes) and then the web server must be able to
forward each record immediately after reception, without any
buffering.

Source: the FastCGI specification
(http://www.fastcgi.com/drupal/node/6?q=node/22) and its Python
implementation (http://trac.saddi.com/flup/browser/flup/server/fcgi_base.py)

But even when the records sent by the FastCGI backend are very short
(around 50 bytes), Nginx doesn't send them immediately. Nginx seems to
buffer over FastCGI record boundaries. Am I correct?

>> Is it difficult to implement the option "fastcgi_buffering off", using
>> the same technique as in the source code of module HTTP proxy?
>
> It is not possible. See comment above.

May be we can force Nginx to send data back to the client just after
having received each FastCGI record? Is it possible?

Thanks a lot for your advice,
Cheers,

Nicolas Grilly