# How to disable buffering when using FastCGI?

**URL:** <https://www.ruby-forum.com/t/how-to-disable-buffering-when-using-fastcgi/177212>\
**Category:** NGINX\
**Created:** [October 13, 2009, 1:30pm UTC](https://www.ruby-forum.com/t/how-to-disable-buffering-when-using-fastcgi/177212 "2009-10-13T13:30:34Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![Nicolas\_Grilly](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/77aa72/32.png) [@Nicolas\_Grilly](https://www.ruby-forum.com/u/Nicolas_Grilly)\
**Post date:** [October 13, 2009, 1:30pm UTC](https://www.ruby-forum.com/t/how-to-disable-buffering-when-using-fastcgi/177212/1 "2009-10-13T13:30:34Z")

</div>

Is there a way to disable buffering when using FastCGI? (for a Comet  
style application)

Is there an option “fastcgi\_buffering off”, working like the option  
“proxy\_buffering off” in the HTTP proxy module?

Thanks,

Nicolas Grilly

---

<div class="post-metadata">

**Author:** ![Nicolas\_Grilly](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/77aa72/32.png) [@Nicolas\_Grilly](https://www.ruby-forum.com/u/Nicolas_Grilly)\
**Post date:** [October 13, 2009, 1:32pm UTC](https://www.ruby-forum.com/t/how-to-disable-buffering-when-using-fastcgi/177212/2 "2009-10-13T13:32:54Z")

</div>

Nicolas Grilly wrote:

> Is there a way to disable buffering when using FastCGI? (for a Comet  
> style application)
> 
> Is there an option “fastcgi\_buffering off”, working like the option  
> “proxy\_buffering off” in the HTTP proxy module?

Have you tried:

fastcgi\_buffers 0 0;

?

–

_Phillip B Oldham_  
ActivityHQ  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

* * *

_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.

---

<div class="post-metadata">

**Author:** ![Nicolas\_Grilly](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/77aa72/32.png) [@Nicolas\_Grilly](https://www.ruby-forum.com/u/Nicolas_Grilly)\
**Post date:** [October 13, 2009, 2:21pm UTC](https://www.ruby-forum.com/t/how-to-disable-buffering-when-using-fastcgi/177212/3 "2009-10-13T14:21:30Z")

</div>

Hello!

On Tue, Oct 13, 2009 at 12:17:05PM +0200, Nicolas Grilly wrote:

> Is there a way to disable buffering when using FastCGI? (for a Comet  
> style application)
> 
> Is there an option “fastcgi\_buffering off”, working like the option  
> “proxy\_buffering off” in the HTTP proxy module?

No, there is no such option. Buffering can’t be disabled for  
fastcgi.

Maxim D.

---

<div class="post-metadata">

**Author:** ![Nicolas\_Grilly](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/77aa72/32.png) [@Nicolas\_Grilly](https://www.ruby-forum.com/u/Nicolas_Grilly)\
**Post date:** [October 13, 2009, 4:21pm UTC](https://www.ruby-forum.com/t/how-to-disable-buffering-when-using-fastcgi/177212/4 "2009-10-13T16:21:30Z")

</div>

2009/10/13 Phillip O. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

> Nicolas Grilly wrote:  
> Is there a way to disable buffering when using FastCGI? (for a Comet  
> style application)
> 
> Is there an option “fastcgi\_buffering off”, working like the option  
> “proxy\_buffering off” in the HTTP proxy module?
> 
> Have you tried:
> 
> fastcgi\_buffers 0 0;

Yes, I have tried this option, but it disables buffering only for the  
FastCGI module, not for the output filters (especially gzip and SSL  
modules). So, this option is not enough to completely disable  
buffering.

---

<div class="post-metadata">

**Author:** ![Nicolas\_Grilly](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/77aa72/32.png) [@Nicolas\_Grilly](https://www.ruby-forum.com/u/Nicolas_Grilly)\
**Post date:** [October 13, 2009, 4:54pm UTC](https://www.ruby-forum.com/t/how-to-disable-buffering-when-using-fastcgi/177212/5 "2009-10-13T16:54:18Z")

</div>

Hello Nicolas,

Tuesday, October 13, 2009, 9:20:00 PM, you wrote:

> > fastcgi.  
> > Hello Maxim,

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

> Do you recommend to people developing Comet style application to use  
> HTTP proxying instead of FastCGI?

Yes. Nginx can establish pipe between backend and client just after  
headers are sent in case when proxy\_buffering = off and gzip = off.

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

> Thanks for your advice,

---

<div class="post-metadata">

**Author:** ![Nicolas\_Grilly](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/77aa72/32.png) [@Nicolas\_Grilly](https://www.ruby-forum.com/u/Nicolas_Grilly)\
**Post date:** [October 13, 2009, 4:26pm UTC](https://www.ruby-forum.com/t/how-to-disable-buffering-when-using-fastcgi/177212/6 "2009-10-13T16:26:12Z")

</div>

On Tue, Oct 13, 2009 at 13:19, Maxim D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> On Tue, Oct 13, 2009 at 12:17:05PM +0200, Nicolas Grilly wrote:
> 
> > Is there a way to disable buffering when using FastCGI? (for a Comet  
> > style application)
> > 
> > Is there an option “fastcgi\_buffering off”, working like the option  
> > “proxy\_buffering off” in the HTTP proxy module?
> 
> No, there is no such option. šBuffering can’t be disabled for  
> fastcgi.

Hello Maxim,

Is there no such option just because nobody implemented it? Or is it  
because of some kind of technical constraint?

Do you recommend to people developing Comet style application to use  
HTTP proxying instead of FastCGI?

Is it difficult to implement the option “fastcgi\_buffering off”, using  
the same technique as in the source code of module HTTP proxy?

Thanks for your advice,

Nicolas Grilly

---

<div class="post-metadata">

**Author:** ![Nicolas\_Grilly](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/77aa72/32.png) [@Nicolas\_Grilly](https://www.ruby-forum.com/u/Nicolas_Grilly)\
**Post date:** [October 13, 2009, 7:35pm UTC](https://www.ruby-forum.com/t/how-to-disable-buffering-when-using-fastcgi/177212/7 "2009-10-13T19:35:16Z")

</div>

Hello!

On Tue, Oct 13, 2009 at 04:20:00PM +0200, Nicolas Grilly wrote:

> > fastcgi.
> 
> Hello Maxim,
> 
> Is there no such option just because nobody implemented it? Or is it  
> because of some kind of technical constraint?

Something like this. FastCGI requires buffer processing which  
isn’t compatible with current code for unbuffered connections.

> Do you recommend to people developing Comet style application to use  
> HTTP proxying instead of FastCGI?

For now you should either close & reopen connections, or use HTTP  
proxy instead.

> Is it difficult to implement the option “fastcgi\_buffering off”, using  
> the same technique as in the source code of module HTTP proxy?

Current “proxy\_buffering off” implementation is something wierd  
and should be nuked, IMHO. The same implementation for FastCGI  
just won’t work.

I believe buffering control in upstream module (which includes  
fastcgi, proxy and memcached) should be changed to something more  
flexible. In particular, fastcgi should be aware of FastCGI  
record boundaries, and shouldn’t try to buffer too much as long as  
it got full record.

I’ve posted some preliminary patches for this as a part of backend  
keepalive support work, but they are a bit stale now.

Maxim D.

---

<div class="post-metadata">

**Author:** ![Nicolas\_Grilly](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/77aa72/32.png) [@Nicolas\_Grilly](https://www.ruby-forum.com/u/Nicolas_Grilly)\
**Post date:** [October 13, 2009, 8:36pm UTC](https://www.ruby-forum.com/t/how-to-disable-buffering-when-using-fastcgi/177212/8 "2009-10-13T20:36:44Z")

</div>

Hello again Maxim,

2009/10/13 Maxim D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

> On Tue, Oct 13, 2009 at 04:20:00PM +0200, Nicolas Grilly wrote:
> 
> > Is there no such option just because nobody implemented it? Or is it  
> > because of some kind of technical constraint?
> 
> Something like this. šFastCGI requires buffer processing which  
> isn’t compatible with current code for unbuffered connections.

Understood.

> > Do you recommend to people developing Comet style application to use  
> > HTTP proxying instead of FastCGI?
> 
> For now you should either close & reopen connections, or use HTTP  
> proxy instead.

So, for now, I guess my best bet is to use HTTP proxying 🙂

> record boundaries, and shouldn’t try to buffer too much as long as  
> it got full record.
> 
> I’ve posted some preliminary patches for this as a part of backend  
> keepalive support work, but they are a bit stale now.

It would be a perfect solution! If the fastcgi module is aware of  
FastCGI record boundaries and stops buffering after having received a  
full record, then the problem is solved. This gives to the FastCGI  
backend complete control over the amount of buffering, sending short  
records in order to limit buffering, or sending long records (around  
8KB) for normal buffering. Is it your plan for the future of the  
upstream module?

Cheers,

Nicolas

---

<div class="post-metadata">

**Author:** ![Nicolas\_Grilly](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/77aa72/32.png) [@Nicolas\_Grilly](https://www.ruby-forum.com/u/Nicolas_Grilly)\
**Post date:** [October 13, 2009, 8:20pm UTC](https://www.ruby-forum.com/t/how-to-disable-buffering-when-using-fastcgi/177212/9 "2009-10-13T20:20:57Z")

</div>

Hello Denis!

Thanks for your explanations.

2009/10/13 Denis F. Latypoff [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

> 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](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](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

---

<div class="post-metadata">

**Author:** ![Nicolas\_Grilly](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/77aa72/32.png) [@Nicolas\_Grilly](https://www.ruby-forum.com/u/Nicolas_Grilly)\
**Post date:** [October 14, 2009, 2:31pm UTC](https://www.ruby-forum.com/t/how-to-disable-buffering-when-using-fastcgi/177212/10 "2009-10-14T14:31:39Z")

</div>

Hello Maxim,

2009/10/13 Maxim D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

> to optimize brain-damaged backends. šBut as long as fastcgi  
> finished record and not started another one - it’s probably a good  
> idea to pass data we got so far downstream. šAnd current aproach  
> won’t work with keepalive connections anyway.
> 
> But please keep in mind that I’m not Igor.

Thank you for your explanations! I will keep an eye on the evolution  
of the FastCGI buffering, but I understand this is a complex topic. In  
the meantime, I will use HTTP proxying.

Nicolas Grilly

---

<div class="post-metadata">

**Author:** ![Nicolas\_Grilly](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/77aa72/32.png) [@Nicolas\_Grilly](https://www.ruby-forum.com/u/Nicolas_Grilly)\
**Post date:** [October 13, 2009, 9:52pm UTC](https://www.ruby-forum.com/t/how-to-disable-buffering-when-using-fastcgi/177212/11 "2009-10-13T21:52:16Z")

</div>

Hello!

On Tue, Oct 13, 2009 at 08:24:53PM +0200, Nicolas Grilly wrote:

[…]

> > record boundaries, and shouldn’t try to buffer too much as long as  
> > 8KB) for normal buffering. Is it your plan for the future of the  
> > upstream module?

Complete control isn’t really good thing, as it limits the ability  
to optimize brain-damaged backends. But as long as fastcgi  
finished record and not started another one - it’s probably a good  
idea to pass data we got so far downstream. And current aproach  
won’t work with keepalive connections anyway.

But please keep in mind that I’m not Igor.

Maxim D.
