我基本都是用同一个配置文件来配置centos下的lnmp组合，从来没有出现过问题。最近在一个vps上安装了同样的环境后，10多人在线后网站打开非常慢。
有几次直接达到了nginx中设置的最大超时300秒。结果nginx向客户端浏览器发送了504网关超时错误代码，分析后更改了几个配置文件。
最后避免了这种情况。
从错误代码来看，基本可以确定与nginx本身无关，主要是提交给php-fpm的请求未能给出正确的反馈。一般情况下，提交动态请求时，nginx会直接将请求传递给php-fpm。
Php-fpm重新分配php-cgi进程来处理相关的请求，然后依次返回它们。最后nginx把结果反馈给客户端浏览器，但是我的vps目前运行的是纯php的应用内容。其实所有用户的请求都是PHP请求。
有的耗时较长，php-cgi进程总是满的，而php- fpm本身的配置文件只打开10组php-cgi进程，这样如果在线用户多一点，请求就不能正常处理，就会出错。
大概分析了原因，下面就比较容易做了。首先，改变php-fpm的几个配置：
将max_children从之前的10改为现在的30，这样可以保证足够的php-cgi进程可以使用；
将request_terminate_timeout由0s改为60s，这样php-cgi进程处理脚本的超时为60s，可以防止所有进程被挂起，提高利用效率。
然后，nginx的几个配置项被更改，以减少FastCGI请求的数量，并尽量保持缓冲区不变：
fastcgi_buffers由4 64k改为2 256k
fastcgi_buffer_size由64k改为128K
fastcgi_busy_buffers_size由128K改为256K
Fastcgi _ temporary _ file _ write _ size changed from 128K to 256K.
好了，重新加载php-fpm和nginx的配置，再测试一遍。到现在两周没有504网关超时，这是一个效果。
另一个例子：
用ie很正常。别人也用FF。但是一个人使用FF浏览并报告错误502。
查看后台error日志，发现一句
upstream sent too big header while reading response header from upstream
就是反馈回来的头部信息太大
一般应该是cookie里面带的
怀疑是FF里面的某个插件引起返回太多的头部信息
一个个排查.最后发现是FireBug导致的
既然是fastcgi返回的头部太大.应该可以配置
查找资料后发现应该是和fastcgi_buffer_*有关的
将相关配置增大.发现问题解决
这边使用的是
fastcgi_buffer_size 32k;
fastcgi_buffers 8 32k;
比原来的默认4k/8k要大许多
http400错：
nginx的HTTP400错误，而且这个HTTP400错误并不是每次都会出现的，查了一下发现nginx 400错误是由于request header过大，
通常是由于cookie中写入了较长的字符串所引起的。解决方法是不要在cookie里记录过多数据，
如果实在需要的话可以考虑调整在nginx.conf中的client_header_buffer_size(默认1k)
若cookie太大，可能还需要调整large_client_header_buffers(默认4k)，该参数说明如下：
请求行如果超过buffer，就会报HTTP 414错误(URI Too Long)
nginx接受最长的HTTP头部大小必须比其中一个buffer大，否则就会报400的HTTP错误(Bad Request)。
http413错：
在上传时nginx返回了413错误，查看log文件，显示的错误信息是：”413 Request Entity Too Large”, 于是在网上找了下“nginx 413错误”发现需要做以下设置：
在nginx.conf增加client_max_body_size的设置， 这个值默认是1m，可以增加到8m