Ideal setting of "fastcgi_buffers" with large files

[Phillip Oldham]

w3wsrmn wrote:
> Howdy,
>
> For cases when large files are served via FastCGI, what might be the ideal settings for the "fastcgi_buffers" directive, in order to prevent the warning:
> "an upstream response is buffered to a temporary file /usr/local/nginx/fastcgi_temp/0/00/0000000000 while reading upstream" ?
>
> For example, to prevent the warning when serving a 6144 kilobyte file, which of the three methods would yield the best performance?
>
> A large number of small buffers:
> fastcgi_buffers 768 8k
>
> A small number of large buffers:
> fastcgi_buffers 8 768k
>
> A near balance between the buffers and size:
> fastcgi_buffers 64 96k
>
>
> Or does it not matter which method is used?
It would be better to tell nginx to serve the file rather than have an 
upstream/fastcgi program serve it - nginx can generally handle many, 
many more connections than your fast-cgi backend so try and make nginx 
do as much of the work as possible.

Take a look at: http://wiki.nginx.org/NginxXSendfile - using this means 
your PHP/fast-cgi thread can exit once it's returned the header and then 
move on to accept another connection.

-- 

*Phillip B Oldham*
ActivityHQ
phill at activityhq.com <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/20091203/cdbafa6e/attachment.html>