nginx配置文件大解析（优化）
配置文件的设置包含：
main 全局设置
server 主机设置
upstream 负载均衡服务器设置
location 部分用于匹配网页设置
关系： server继承main；
location继承server；
upstream不会继承也不会被继承
1、 user nginx1;
#运行用户和组；默认用户为nobody；
0 12:28 ? 00:00:00 nginx:
2、 worker_processes 16;
#工作进程数，建议设置为等于CPU总核心数
ps -ef 时注意观察worker_processes
3、 worker_rlimit_nofile 4096;
#每个进程打开的文件句柄数=系统总数/4 不要设置成65535
4、 error_log /usr/log/nginxa1/logs/error.
#全局错误日志存放路径；级别：debug | info | notice | warn | error | crit
5、 pid logs/nginx.
#pid文件；
6、 #工作模式及连接数上限
#每个进程的最大连接数，不要动不动就65535；
worker_connections 4096;
#使用epoll（linux2.6的高性能方式）
#参考事件模型，use [ kqueue | rtsig | epoll | /dev/poll | select | poll ]; epoll模型是Linux 2.6以上版本内核中的高性能网络I/O模型，如果跑在FreeBSD上面，就用kqueue模型。
#使用epoll（linux2.6的高性能方式）
7、#设定http标签，利用它的反向代理功能提供负载均衡支持
#mimie.types 浏览器请求的文件媒体类型
include mime.
#用来告诉浏览器请求的文件媒体类型
default_type application/octet-
#设定日志格式
log_format main '$remote_addr - $remote_user [$time_local] &$request& '
'$status $body_bytes_sent &$http_referer& '
'&$http_user_agent& &$http_x_forwarded_for&';
$remote_addr直接客户端地址
$http_x_forwarded_for 间接客户端地址（一般前面会有代理服务器）
$remote_user 远程客户端用户名称
$time_local记录访问时间与时区
$request用户的请求,使用的HTTP协议
$status 返回状态,200,404,304等
$body_bytes_sents发送的body字节数
$http_referer 引用页(从哪个链接访问来的)
$http_user_agent客户端浏览器
#设置请求日志
access_log /usr/log/nginxa1/logs/access.
#include指令，可以包含任何你想要包含的配置文件，支持文件名匹配。
#include extra/bbs.[root@client scripts]# cat cut_log.sh
#日志切割脚本范例：
cd /application/nginx/logs
mv www_access.log www_access_$(date +%F -d -1day).log
/application/nginx/sbin/nginx -s reload
[root@client scripts]# crontab -l|tail -2
#cut nginx log by day by oldboy at 201409
00 00 * * * /bin/sh /server/scripts/cut_log.sh &/dev/null 2&&1
#日志分析软件：syslog、rsyslog、Awstats（svn文档）、flume、logstash、scrilbe、kafka、
8、 设定请求缓冲
#接收header的缓冲区大小
client_header_buffer_size 128k;
该指令用于设置客户端请求的Header头缓冲区大小，默认值为4KB。
large_client_header_buffers 4 256k;
#客户端包体缓冲区大小
client_body_buffer_size 1024k;
#设置客户端能够上传的文件大小，默认为1m
client_max_body_size 8m;
#开启高效文件传输模式，sendfile指令指定nginx是否调用sendfile函数来输出文件，对于普通应用设为 on，如果用来进行下载等应用磁盘IO重负载应用，可设置为off，以平衡磁盘与网络I/O处理速度，降低系统的负载。注意：如果图片显示不正常把这个改 成off。
#开启目录列表访问，合适下载服务器，默认关闭。
#防止网络阻塞
#防止网络阻塞
#长连接超时时间，单位是秒
keepalive_timeout 120;
#charset GBK;
#长连接保持时间
keepalive_timeout 120;
#不显示Nginx版本号
#服务器名字的hash表大小
server_names_hash_bucket_size 64;
server_names_hash_max_size: 512
9、#开启gzip模块，要求安装gzip 在运行./config时要指定
#最小压缩文件大小，默认0
gzip_min_length 1100;
#压缩缓冲区
gzip_buffers 4 16k;
gzip_types text/plain application/x-javascript text/css application/
#压缩比率，1压缩比最小速度最快；9压缩比最大，传输快，但速度慢，比较消耗cpu资源；
gzip_comp_level 9;
#压缩通过代理的所有文件
#vary header支持
#前端服务缓存压缩
#压缩版本（默认1.1，前端为squid2.5使用1.0）
gzip_http_version 1.0;
#输出缓冲区
output_buffers 4 32k;
postpone_output 1460;
#此功能同apache的mod_deflate压缩功能，依赖ngx_http_gzip_module模块，默认已安装
10、代理设置；
#代理连接超时时间
proxy_connect_timeout 120;
#代理发送超时时间
proxy_send_timeout 120;
#代理读超时时间
proxy_read_timeout 120;
#设置从后端被代理服务器的响应内容缓冲区大小
proxy_buffer_size 512k;
#开启从后端被代理服务器的响应内容缓冲.
#设置从被代理的后端服务器取得的响应内容缓冲区的大小和数量
proxy_buffers 32 512k;
#客户端发送header超时
client_header_timeout 3m;
#客户端发送内容超时
client_body_timeout 3m;
#发送到客户端超时
send_timeout 3m;
#proxy_buffers缓冲区，网页平均在32k以下的设置
proxy_buffers 4 32k;
#高负荷下缓冲大小（proxy_buffers*2）
proxy_busy_buffers_size 64k; #
#设定缓存文件夹大小，大于这个值，将从upstream服务器传
proxy_temp_file_write_size 64k;
负载均衡器发给web_server的优化；
参数如下：
proxy_set_header Host $
proxy_set_header X-Real-IP $remote_
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_
client_max_body_size 50m;
client_body_buffer_size 256k;
proxy_connect_timeout 30;
proxy_send_timeout 30;
proxy_read_timeout 60;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
proxy_next_upstream error timeout invalid_header http_500 http_503 http_404;
proxy_max_temp_file_size 128m;
proxy_store_access user:rw group:rw all:r;
#proxy_temp_path /dev/shm/nginx_
#proxy_temp_path /data2/nginx_
11、根据cpu核数优化优化进程数；
查看cpu核数
grep &physical id & /proc/cpuinfo
physical id : 0
address sizes : 40 bits physical, 48 bits virtual
physical id : 0
address sizes : 40 bits physical, 48 bits virtual
调度硬件分配
不同的cpu对应配置参考如下
四核cpu服务器参数配置：
worker_cpu_affinity 00 1000;
#nginx进程CPU亲和力，即把不同的进程分给不同的CPU处理。这里00 1000是掩 码，分别代表第1、2、3、4颗cpu核心。
八核cpu服务器参数配置：
worker_cpu_affinity 00 00 00000;
worker_cpu_affinity 00 10 ;
taskset 调整cpu分配
另外(taskset - retrieve or set a process&s CPU affinity)命令本身也有分配CPU的功能。
例如：taskset -c 1,2,3 /etc/init.d/mysql start
资料：/edwardlost/archive//1858991.html
12、fastcgi 参数调整 秒
fastcgi调优（配合PHP引擎动态服务）
fastcgi_connect_timeout 300;
#指定连接到后端FastCGI的超时时间
fastcgi_send_timeout 300;
#向FastCGI传送请求的超时时间，这个值是指已经完成两次握手后向FastCGI传送请求的超时时间。
fastcgi_read_timeout 300;
#指定接收FastCGI应答的超时时间，这个值是指已经完成两次握手后接收FastCGI应答的超时时间。
fastcgi_buffer_size 64k;
#指定读取FastCGI应答第一部分需要用多大的缓冲区，这个值表示将使用1个64KB的缓冲区读取应答的第一部分（应答头），可以设置为fastcgi_buffers选项指定的缓冲区大小。
fastcgi_buffers 4 64k;
#指定本地需要用多少和多大的缓冲区来缓冲FastCGI的应答请求。如果一个PHP脚本所产生的页面大小为256KB，那么会为其分配4个64KB的缓冲区来缓存；如果页面大小大于256KB，那么大于256KB的部分会缓存到fastcgi_temp指定的路径中，但是这并不是好方法，因为内存中的数据处理速度要快于硬盘。一般这个值应该为站点中PHP脚本所产生的页面大小的中间值，如果站点大部分脚本所产生的页面大小为256KB，那么可以把这个值设置为&16 16k&、&4 64k&等。
fastcgi_busy_buffers_size 128k;
#建议为fastcgi_buffers的两倍
fastcgi_temp_file_write_size 128k;
#在写入fastcgi_temp_path时将用多大的数据块，默认值是fastcgi_buffers的两倍，设置上述数值设置太小时若负载上来时可能报 502 Bad Gateway
fastcgi_cache oldboy_nginx
#表示开启FastCGI缓存并为其指定一个名称。开启缓存非常有用，可以有效降低CPU的负载，并且防止502错误的发生，但是开启缓存也可能会引起其它问题，要根据具体情况选择。
fastcgi_cache_valid 200 302 1h;
#用来指定应答代码的缓存时间，实例中的值表示将200和302应答缓存一个小时
fastcgi_cache_valid 301 1d;
#将301应答缓存1天
fastcgi_cache_valid any 1m;
#将其它应答缓存为1分钟
fastcgi_cache_min_uses 1;
#缓存在fastcgi_cache_path指令inactive参数值时间内的最少使用次数
####进程交互会产生零时文件
13、upstream的负载均衡
upstream xxxx.xx.net{
#weigth参数表示权值，权值越高被分配到的几率
#sru_id=a:index=1 ,srun_id=b:index=2, srun_id=c:index=3,srun_id=d:index=4
server 10.110.5.81:8081 max_fails=3 fail_timeout=30s srun_id=a;
server 10.110.5.82:8081 max_fails=3 fail_timeout=30s srun_id=b;
server 10.110.5.83:8084 max_fails=3 fail_timeout=30s srun_id=c;
server 10.110.5.84:8084 max_fails=3 fail_timeout=30s srun_id=d;
#保证按照seesion分发
jvm_route $cookie_JSESSIONID|
#jvm_route $cookie_JSESSIONID|
#weight=NUMBER &&设置服务器的权重，权重数高被分配访问数越高，默认权重1.
#max_fails=NUMBER&&在参数fail_timeout指定的时间内对后端服务器请求失败的次数，如果检测到后端服务器无法连接及发生服务器错误（404错误除外），则标记为失败。默认值为1.设置为0这关闭这项检查
#fail_timeout=TIME&&在经历参数max_fails设置的失败次数后，暂停的时间
#down&&标记服务器为永久离线状态，用于ip_hash指令
#backup&&仅仅在非backup服务器全部繁忙的时候才启动
#upstream模块拥有以下变量：
# $upstream_addr:处理请求的upstream服务器地址
# $upstream_status:upstream服务器的应答状态
# $upstream_response_time:Upstream服务器响应时间（毫秒），多个响应以逗号和冒号分隔。
# $upstream_http_$HEADER:任意的HTTP协议头信息，例如:$upstream_http_host
14、第一个虚拟服务器
#侦听192.168.8.x的80端口
listen 80;
#主机名地址，可以是ip，或者主机名，多个空格隔开
server_name 10.10.70.
#定义服务器的默认网站根目录位置
root html/
#定义首页索引文件的名称
index index.php index.html index.
15、设定查看状态标签status
listen 80;
server_name status.xxx.
16、301重定向
listen 80;
server_name blog.etiantian.
root html/
index index.html index.
rewrite ^/(.*) http://www.etiantian.org/$1
#访问域名下的所有内容跳转到www.etiantian.org /前为域名；
#为防止别人恶意绑定域名可以使用ip地址重定向；
#输入ip访问的是第一个域名；
#.*为内容；$接受；permanent表示永久跳转；
17、expires 缓存功能
#针对网站运营中的（不经常变化的）图片推送到客户端的浏览器进行缓存；
优势： 节省宽带 ；减少服务器压力，支持高的并发；浏览器加快，提升用户体验；
劣势： 网站跟新内容后客户端可能是旧的；测试的时候希望是新的，总是看不到；广告。统计的代码不准确。
根据业务需求设置expires的过期时间；
图片更改（重新上传）； 时间1年-10年
广告，统计，不缓存 ；
网站改版 元素要改名js ，css ；
缓存cdn的资源 （***图片） 清理源站图片；让其清理缓存。 （接口 API 或者是web界面管理）
例 ：location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
expires 3650d;
location 满足条件执行。满足.执行...
location ~ .*\.(js|css)?$
expires 30d;
#server标签里；date -s && 修改时间 hwlock -c 写入系统时间；
18、防盗链
#表示对哪种类型的文件实行防盗链 ~ .*\.(wma|wmv|asf|mp3|mmf|zip|rar|jpg|gif|png|swf|flv)$ {
valid_referers none blocked *. ;
#来源判断；
if($invalid_referer) {
#rewrite ^/ /error.
#返回结果，可以指定具体的图片；
return403; }
19、url访问控制（文件、图片、ip都可以设置）：
location ~ ^/images/.*\.(php|php5)$
location ~ ^/static/.*\.(php|php5)$
location ~* ^/data/(attachment|avatar)/.*\.(php|php5)$
#附件和头像
location /admin/ { return 403; }
location /templates/ { return 403; }
#返回状态返回码；location是有顺序的，根据规则调整；
20、伪静态：
待补~~！！！
21、robot.txt 机器人设置
查看： /robots.txt
使用：网站的收录几率降低；
不使用：降低网站的资源消耗；
范例：根据不同的浏览器访问设置：
if ($http_user_agent ~* &Firefox|MSIE&)
return 403;
22、保证网站不遭受木马侵入
1、站点内所有目录和文件的用户和组都因该为root！
2、站点内所有目录权限默认为755；（不能往目录放文件）
3、站点内所有文件权限默认为644；（不能改文件）
注意 网站服务的程序使用的用户不可以使用root。
解决方案：找到上传的目录，授权nginx 可以访问；比较安全！
架构上优化：动态web集群 （架三个web服务，正常浏览、上传、下载各一个服务器）适合所有的web服务器 ；
mount 挂载优化 ： mount -o nosuid,noexec,nodev
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467142',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'您的浏览器已经禁用了脚本，这可能会影响您正常使用本站的功能。
高并发下的 Nginx 优化方案
我已经谈过一些关于的常见问题，其中有一些是关于如何优化Nginx，很多Nginx新用户是从Apache迁移过来的，因些他们过去常常调整配置和执行魔术操作来确保服务器高效运行。
我有一些坏消息要告诉你，你不能像Apache一样优化Nginx。它没有魔术配置来减半负载或是让运行速度加快一倍。高兴的是，Nginx已经优化的非常好了，当你决定使用Nginx并用，或是命令安装的时候它就已经进行了最佳优化。 (注意那些库经常过期，Wiki的安装页面上通常有最新的库)
就是说，很多影响Nginx行为的参数其默认值并不是完全适合高并发的情况。我们也要考虑Nginx运行所在的平台，优化我们的操作系统当有一些限制的时候。
总的来说，我们无法优化单个连接的负载时间，但是我们可以确保Nginx的高并发处理环境。当然， 对于高并发我指的是每秒数百个请求连接，大多数人不需要了解这些。假如你太好奇或是想知道那就继续读吧。
首先，我们需要认识到Nginx几乎可能需要在所有的平台上使用，MacOS，，，，Windows甚至一些更深奥的系统。他们大部分(这么翻译好些)实现了高性能的基于事件的polling方法，不幸的是Nginx的只支持其中4个系统。在四个系统中我倾向于FreeBSD，但你不会看到太大的性能差异，所以选择的操作系统让你用起来顺手，比选择最优化的操作系统更重要。
我想你一定猜到了windows不在其中。 Windows上的nginx确实没有什么理由让你值得使用。 Windows有自己的一套处理事件polling。 所以nginx的作者选择了不支持。 因此默认的还是使用select() 这种不是很高效而且性能会下降很多的方式。(初次翻译不是很好希望多多指教)
第二个最大的限制， 也是大多数人会遇到的问题是和操作系统相关的。 打开一个窗口， 使用命令切换到Nginx的运行用户， 运行命令` -a`。 这些值也会在Nginx在运行中对它进行限制。 在许多操作系统中， &open files&的值是相当有限的， 在我使用的操作系统中， 它的值是 1024。 如果Nginx在运行中操作了这个限制他会记录error log(24： Too many open files) 接着返回一个操作给客户端。 当然Nginx可以处理的文件数可以更大你也可以针对操作系统做一些改动， 你可以放心的去增加这个值。
两种方式可以实现， 你可以通过ulimit设置os的：&open files&， 你还可以通过(nginx)配置
来申明你期望的值。
Nginx 限制
除了注意操作系统的限制， 现在我来深入到Nginx本身，看看一些指令和方法，我们可以用它来调整Nginx。
Worker Processes(用英文会更好一些)
是Nginx的主干， 一旦主进程绑定到指定的和端口，就会使用nginx指定的用户孵化出子进程， 之后他们会处理所有的工作。 Workers 不是多线程的， 所以不能扩展它超过CPU的核数。 所以我们应该理解设置多个(&1)workers的原理， 通常一个CPU核对应一个worker。 过犹不及，2-4个workers会伤害CPU， 在CPU成为问题之前Nginx会遇到其他的瓶颈。而通常你只是看到了空闲的进程。(这段翻的太烂了希望大家多多改进)
当你正在处理下面这种情况， 你有很多的阻塞(blocking)磁盘IO，这是你可以适当增加worker_process的值。 你需要针您的配置进行测试，检查静态文件的等待时间(waiting )， 如果值比较大，可以适当的增加worker_process。(这段翻译完有想哭的感觉)
Worker Connections
是个稍稍有点怪的概念。 我不是很了解这个指令的目的， 但是它有效的限制了在同一时间内每个worker可以维护的连接数。 如果我没猜错的话， 这个配置是为了确保在keep-alive配置不正确的情况下， 当你使用的端口将要耗尽之时，增加连接数。(这个翻译的好难不知道是否正确因为作者也是forced to guess 我也只能被逼去猜了望指正)
默认的值是1024。 我们假设一个李兰奇一般情况下打开2个连接来通过管道获取网站资源，也就是最多可以同时处理512个用户的请求。听起来实在是太少了，但是我们在想一下默认的keepalive-timeout是65(在默认配置文件里面提供了65这个值， 如果没有设置该值，默认值是75，请参考wiki )，也就是说我们实际上每秒只能处理8个连接。 显然这个值高于许多人期望的(我没觉得高呵呵)， 尤其是考虑到我们通常会设置2-4个workers。 但是对于流量较大的网站 使用keep-alive是值得的。(翻译完了又想哭了)
此外，我们还必须考虑反向代理， 这将打开一个额外的连接到后台，但是，自Nginx的不支持持久连接到后台，这不是太大的问题，除非你有长时间运行的后台进程。
所有关于worker连接的配置应该是相当清楚的，如果你流量增加了，你要相应的增加worker连接的数量。 2048对于大多数人来说应该是满足了，但老实说，如果你的流量增长了，那么对于workers的数量值应该是多少应该是很清楚的。
CPU 亲和力
设置CPU的亲和力，基本上意味着你告诉每个程序使用的CPU核心，而他们将只使用这个CPU核心。关于这一条，我不想说很多，但你要知道，如果你准备这样做，则必须非常小心。 要知道，你操作系统的 CPU 调度器处理负载均衡的能力要远远超过你。当然，如果你认为你的 CPU 负载均衡有问题，在调度层面上优化它，可能的话找一个替代的调度器。除非你知道你在做什么，否则不要碰这个。
Keep Alive
是 HTTP的一个特性， 它允许客户端维护与服务器已经创建的连接进行一批请求的处理直到指定的超时时间到达。 这个实际上不会在很大程度上改变我们的Nginxserver的性能， 因为Nginx能够很好的处理空闲的连接。 Nginx的作者声称10，000个空闲的连接智慧使用2。5兆内存(unbelievable)， 我个人的使用来说这个值也是靠谱的。
我在这篇性能文章里面提到这个原因非常简单。 对于最终用户来说keep alive对加载时间有着巨大的影响。 这是最重要的指标之一也是我们不断优化的原因。如果你的网站对用户来说感觉加载起来很快，他们就会很开心。 Amazon和一些其他的大型在线零售商做过许多类似的研究表明， 网站的加载时间和网站订单的完成有着直接的关系。
为什么keep alive有着如此巨大的影响， 应该是显而易见的， 那就是你避免为所有的HTTP请求创建各自的连接， 这是非常低效的。 也许你不需要把keepalive-timeout设置为65， 但是10-20应该是比较通用的选择，正如上面一段所说， Nginx会很好的处理这方面。
tcp_nodelay 和 tcp_nopush
这两个指令也许是最难理解的nginx配置， 他们对于nginx的影响在网络的较低层。 你可以简单的认为这些指令决定了操作系统如何处理网络缓存和他们何时将这些缓存输出到最终用户(客户端)。 我只能建议大家如果你之前不了解这些概念你最好不要动它。 他们不会显著的改善或者改变性能， 所以最好使用他们的默认值。
因为我们要处理nginx带来的所有可能的限制， 所以我们现在需要弄清楚如何有效的利用我们的服务器。为了做到这点我们需要看一下硬件层面的东西，由于大部分服务器瓶颈都会发生在这里。
一般服务器主要还有3个方面的瓶颈。 CPU，内存和IO。 Nginx在CPU的利用方面是非常高效的， 所以我会坦白的告诉你这不会成为瓶颈。 同样nginx在使用内存方面也是很高效的，这也不会成为瓶颈。 现在只剩下IO这个服务器瓶颈的罪魁祸首了。(搞得像找罪犯一样)
如果你经常使用服务器，那么你可能经历过这样认识。硬盘驱动器是真的，真的很慢。从硬盘驱动器读取可能是对服务器最昂贵的操作。 所以自然得出的结论是，为了避免IO瓶颈， 我们需要大量的减少nginx对硬盘驱动器的读写。
要做到这一点，我们可以通过修改Nginx的行为，以减少磁盘写操作，以及确保对nginx的内存限制，允许它避免磁盘访问。
Access Logs
默认情况下，Nginx的每个请求都会记录在磁盘上的日志文件中，你可以使用这个方法进行统计，安全问题检查等， 带着这会在一定程度上带来IO使用成本。 如果你不打算用这些访问日志来做一些检查或其他用途， 你可以直接关闭它以避免对磁盘写操作， 但是如果你需要访问日志，你可以考虑保存日志到内存中。这将会比直接写到磁盘上快很多，并且明显减少IO的使用。
如果你只打算使用访问日志进行统计，你可以考虑使用其他的比如google analytics来取代(ga和access log还是有区别的 不能简单的取代哦)，或者你只记录访问请求的部分信息而不是全部。
Error Logs
我内心小小的挣扎了一把，我是否要在这里阐述这个error log 指令呢，因为也许你根本不希望关闭error log， 特别是考虑到实际应用中错误日志的量会很少。 但是考虑到这里指令有一个小小的地方需要引起大家注意， 错误日志的等级参数你是可以指定的， 如果你指定的太低了他会记录404错误甚至是debug信息。 在实际的应用中可以将它设置为warn级别，将会是绰绰有余的并且能降低IO。
从文件系统中读取文件由2部分组成，打开和关闭文件。 考虑到这是一个有阻塞的操作，因此不要忽略这部分。 因此， 对于我们来说缓存打开文件的描述符是非常好的，这就是指令的由来。 链接的wiki地址里对于使用和配置它有着非常好的说明， 所以我建议你去拜读一下。
配置Nginx缓存的大小是一个非常重要的事情。 如果缓存大小设置的太小， Nginx将不得不把上游(用英文upsteams会更好)的相应结果存放到临时的缓存文件里面，这将会同时增加IO的读写操作， 而且流量越大问题越多。
指令用来指定处理客户端请求的缓冲区大小， 这个代表了访问请求的body。 这是用来处理POST的数据，也就是通过提交表单，文件上传等请求的数据。 如果你需要处理很多大的POST请求的，你必须确保缓存区要设置的足够大。
指令用来处理上流(upstream)的响应结果， 也就是 Apache等。它的概念其实和上面提到的差不多， 如果缓冲区不足够大数据将在返回给用户使用之前被保存到磁盘上。 注意Nginx将这个buffer数据同步的传输给客户端之前，有一个缓存上限， 保存到磁盘也同样受限。 这个上线是通过fastcgi_max_temp_file_size和proxy_max_temp_file_size来设置的。 另外对于代理的连接你也可以通过把proxy_buffering设置成off来彻底的关闭缓存。(通常这不是一个好办法)。
彻底移除磁盘IO
最好的减少磁盘IO的方法无疑是不使用磁盘， 如果你的的应用只有少量的数据传输，你可以将数据都放入内存，这样就可以彻底不用考虑磁盘IO的阻塞了。 当然默认情况下你的操作系统也会缓存频繁访问的磁盘扇区， 所以内存越大磁盘的IO就会用到的越少。 这就意味着你可以通过增加内存来解决IO的瓶颈。 数据量越多，需要的内存越大。
为了好玩，我们假设你有了足够大的内存来缓存你的所有数据。 这意味着理论上你的IO读速度达到了3-6gbps。 但是你没有那么快的网络通道。 不幸的是，我们可以优化的网络IO是有限的，我们要通过网络传输数据，所以还将受制于网络IO。 唯一真正有效的方法是尽量减少数据量或压缩。
幸运的是Nginx提供了模块， 它可以使我们在将数据传输给客户端之前压缩它， 这将大大减少数据的大小。 一般来说gzip_comp_level的值不会在性能方面有多大的差别，设为为4-5即可。 一味的增加它是没有意义的只是浪费的CPU的周期。
你也可以通过一些javascript和css缩小工具来减少传输文件大小。 但这些不是和Nginx很相关所以我相信你通过google可以获取更多的相关信息。
英文原文：
收藏Ctrl+D
关注Linux/Unix应用技术、业界新闻，同时也发布开源、移动互联网等新鲜资讯！
—— Powered　——运行在