最近花了一點(diǎn)時(shí)間進(jìn)行了NGINX加TOMCAT7集群壓力測(cè)試，下面通過(guò)對(duì)一些常見(jiàn)問(wèn)題的回答來(lái)說(shuō)明如何調(diào)優(yōu)服務(wù)器的性能，是自己的一些經(jīng)驗(yàn)，且無(wú)實(shí)際數(shù)據(jù)，如有紕漏請(qǐng)見(jiàn)諒。

背景: TOMCAT7已加APR或者NIO。已裝簡(jiǎn)單監(jiān)控JCONSOLE,監(jiān)控服務(wù)器內(nèi)存，線程等基本情況。

問(wèn)題1  一個(gè)Tomcat他的maxThreads到底配置多少合適?
一個(gè)好的maxThreads的配置就是達(dá)到資源的合理化應(yīng)用。

資源池：

在講其它東西之前，我們先引入一個(gè)概念，就是資源池。tomcat7中，他對(duì)http請(qǐng)求的處理，也有一個(gè)池的概念，配置可以參考這里。每一個(gè)請(qǐng)求進(jìn)來(lái)后都是使用線程池中的一個(gè)來(lái)處理，線程池的大小是由maxThreads來(lái)限定的。

異步IO：

當(dāng)前Tomcat通過(guò)使用JAVA NIO或者Apache Portable Runtime這樣的異步IO來(lái)支持性能的優(yōu)化。異步IO就是當(dāng)應(yīng)用需要進(jìn)行耗時(shí)的IO操作時(shí)，向內(nèi)核發(fā)出請(qǐng)求，不用真正等IO操作完成，就去處理其它的請(qǐng)求了，當(dāng)IO真正完成時(shí)會(huì)有回調(diào)或通知機(jī)制通知并完成余下工作。而一般的同步IO是當(dāng)應(yīng)用需要IO操作時(shí)，向操作系統(tǒng)發(fā)出IO Read/Write請(qǐng)求。同時(shí)阻塞當(dāng)前應(yīng)用，并等待IO返回，返回后才進(jìn)行后續(xù)的操作。從這里可以看出異步IO實(shí)際是將請(qǐng)求的處理和IO處理并行了，這樣自然能較大的提高系統(tǒng)的吞吐量。

maxThreads的大小:

第一點(diǎn)：從上面的異步IO的機(jī)制來(lái)看，實(shí)際上我們可能可以用一個(gè)很小的線程池處理較大的連接數(shù)。如當(dāng)前有100個(gè)請(qǐng)求要被處理，處理過(guò)程中50個(gè)進(jìn)程都處于IO等待的狀態(tài)，所以我們實(shí)際可能只需要50就能夠處理那些不處于IO等待狀態(tài)的請(qǐng)求就能滿足需要了。注意在Tomcat中是使用maxConnection這個(gè)配置參數(shù)來(lái)配置Tomcat的同時(shí)處理連接數(shù)的。

第二點(diǎn)：盲目的加大線程數(shù)會(huì)帶來(lái)一些下面的影響。由于Tomcat處理的線程均會(huì)在操作系統(tǒng)中產(chǎn)生對(duì)應(yīng)的實(shí)際線程，這就意味著對(duì)應(yīng)的資源消耗（內(nèi)存，SOCKET等）。另一個(gè)影響就是同時(shí)處理的請(qǐng)求加大可能導(dǎo)致JAVA內(nèi)存回收的問(wèn)題,不同的并發(fā)對(duì)內(nèi)存的占用是不同，而實(shí)際上90%的內(nèi)存都是臨時(shí)變量，可以很快回收。較大的并發(fā)同時(shí)占用較多的臨時(shí)變量就會(huì)導(dǎo)致容易撐滿年青代，從而導(dǎo)致部分內(nèi)存進(jìn)入老年代，從而引起更多的Stop The World，甚至OOM，影響JVM性能。其它的影響還包括更高的CPU占用和更多的硬盤(pán)讀寫(xiě)。這些實(shí)際都跟硬件有關(guān)。

第三點(diǎn)： 我們可以通過(guò)配置一個(gè)較合理的資源池，由于資源充裕，單個(gè)請(qǐng)求處理迅速，這樣能達(dá)到最優(yōu)的系統(tǒng)效率。但是有的時(shí)候我們并不總是追求這樣的一種情況。比如下載時(shí)，單個(gè)請(qǐng)求的響應(yīng)時(shí)間將受限于網(wǎng)絡(luò)，下100M的包可能需要20分鐘，我們就不應(yīng)該通過(guò)一個(gè)較小的資源池來(lái)提升整體的效率，而應(yīng)該配置一個(gè)較大的資源池，讓較多用戶連接上并進(jìn)行下載，否則多數(shù)的用戶都將會(huì)因超時(shí)被拒絕，從而造成連接上的超快，連不上的就直接被拒絕。

第四點(diǎn)：?jiǎn)蝹€(gè)JVM的內(nèi)存分配較大將導(dǎo)致Full Gc(Stop The World)的中斷時(shí)間變得更長(zhǎng)，影響實(shí)時(shí)性。高的可達(dá)10秒以上的停頓，這段時(shí)間所有的東西將被掛起。

配置大小優(yōu)化思路:

配置時(shí)應(yīng)該根據(jù)你應(yīng)用的實(shí)際情況,是最占CPU,內(nèi)存還是IO，最后達(dá)到一個(gè)平衡就好，下面來(lái)說(shuō)明思路。

1. 自行保證服務(wù)器的資源較夠用，如IO、CPU、內(nèi)存。

2. 在硬件較充裕的情況下嘗試以maxThreads配置300、600、1200、1800，分析Tomcat的連接時(shí)間，請(qǐng)求耗時(shí)，吞吐量等參數(shù)。在測(cè)試的時(shí)候需要密切注意硬盤(pán)、帶寬、CPU、內(nèi)存是否處于一個(gè)瓶頸情況下。

3. 其實(shí)所有的東西最后都有一個(gè)極限就是硬件。應(yīng)用分CPU，IO，內(nèi)存密集型，這些都會(huì)成為你最終的限制性因素。一般應(yīng)用根據(jù)自己的特性劃分到不同的機(jī)群中，如CPU密集型的會(huì)分到一群有更好CPU的集群中。這樣可以能充分利用資源。我們以常見(jiàn)的內(nèi)存為最終限制性因素，并假設(shè)CPU足夠好，且IO很少來(lái)說(shuō)明思路。通過(guò)一些壓測(cè)工具，我們能容易的找到一個(gè)在300~8000的并發(fā)數(shù)的情況下一個(gè)性能的拐點(diǎn)，通過(guò)對(duì)比不同線程數(shù)下請(qǐng)求連接時(shí)間、單請(qǐng)求的平均響應(yīng)時(shí)間，總體的吞吐量。這個(gè)拐點(diǎn)往往意味著此時(shí)的內(nèi)存回收出現(xiàn)異常，JVM花了更多的時(shí)間在回收內(nèi)存,我們一般可以通過(guò)打出gc日志，并使用jmeter等工具來(lái)分析得知。此時(shí)你可以嘗試優(yōu)化內(nèi)存結(jié)構(gòu)或加大內(nèi)存 來(lái)解決，若不能解決，可能就意味你前一次的配置就是一個(gè)好的選擇。當(dāng)然這些限制因素是可能互相轉(zhuǎn)換的，可能你增加了內(nèi)存之后內(nèi)存沒(méi)有問(wèn)題了，但是卻導(dǎo)致CPU達(dá)到100%，從而導(dǎo)致性能下降。此時(shí)則要以CPU為最終限制性因素了。

優(yōu)化測(cè)試中陷阱：

以一個(gè)下載服務(wù)器來(lái)例子說(shuō)明。我們以下載10m的包來(lái)做測(cè)試，其實(shí)你會(huì)發(fā)現(xiàn)整個(gè)服務(wù)器的吞吐量很差，響應(yīng)時(shí)間慢。但細(xì)心的人會(huì)發(fā)現(xiàn)此時(shí)連接服務(wù)器的時(shí)間卻是很快的，也就是說(shuō)服務(wù)器很快accpet了你的請(qǐng)求，雖然你的吞吐量不大，處理耗時(shí)也大。原因是什么呢,其實(shí)是你的帶寬已經(jīng)被占滿了，你會(huì)發(fā)現(xiàn)并發(fā)下載10個(gè)文件就能占滿你的所有帶寬。所以此時(shí)呢你的測(cè)試時(shí)的對(duì)比對(duì)象變成了對(duì)比連接時(shí)間會(huì)更加合理。

當(dāng)然你也可以通過(guò)減少包的大小，比如降到 1k，以使帶寬不成為瓶頸.這樣可能測(cè)試出來(lái)你的服務(wù)器并發(fā)極限量，但該并發(fā)量可能并不能反應(yīng)出實(shí)際下載的情況，實(shí)際的情況就是帶寬容易被占滿,下載服務(wù)器會(huì)有一個(gè)很大量的連接存在的情況。

問(wèn)題2. NGINX到底能帶來(lái)怎么樣的性能提升，或者說(shuō)有什么好處？
1. 測(cè)試后發(fā)現(xiàn)，NGINX并不能加快響應(yīng)的速度，為什么呢，因?yàn)檫@是由于NGINX會(huì)代理你同后端的請(qǐng)求。也就意味著你原來(lái)只需要建立同服務(wù)器的一次連接即可完成請(qǐng)求，現(xiàn)在變成了先同NGINX建立連接，NGINX再同后端建立連接。所以引入NGINX后帶來(lái)了更多的時(shí)間消耗，兩倍的SOCKET連接消耗。

2. 引入后的好處體現(xiàn)如下。

1) 整體的性能會(huì)有提升，通過(guò)實(shí)測(cè)后發(fā)現(xiàn)能很大程度上降低最大返回耗時(shí)的情況。請(qǐng)求返回更穩(wěn)定。

2) 降低后端的資源消耗。原來(lái)由于客戶端網(wǎng)絡(luò)較慢等因素會(huì)讓后端在返回?cái)?shù)據(jù)時(shí)處于繁忙的情況，占用資源。通過(guò)NGINX向后端代理，同時(shí)由于NGINX的緩存機(jī)制，后端可以快速返回，并將資源更集中用到處理請(qǐng)求上，這樣可以發(fā)揮后端的能力。NGINX在保持大量連接這塊就得很優(yōu)秀，內(nèi)存，CPU都占用很少。

3) 支持非常方便的擴(kuò)展，高可用性等。

基本的 (優(yōu)化過(guò)的)配置

我們將修改的唯一文件是nginx.conf，其中包含Nginx不同模塊的所有設(shè)置。你應(yīng)該能夠在服務(wù)器的/etc/nginx目錄中找到nginx.conf。首先，我們將談?wù)撘恍┤衷O(shè)置，然后按文件中的模塊挨個(gè)來(lái)，談一下哪些設(shè)置能夠讓你在大量客戶端訪問(wèn)時(shí)擁有良好的xìng能，為什么它們會(huì)提高xìng能。本文的結(jié)尾有一個(gè)完整的配置文件。
nginx要開(kāi)啟的進(jìn)程數(shù) 一般等于cpu的總核數(shù) 其實(shí)一般情況下開(kāi)4個(gè)或8個(gè)就可 我開(kāi)2個(gè)
以了 多了沒(méi)有太多用
每個(gè)nginx進(jìn)程消耗的內(nèi)存10兆的模樣
worker_cpu_affinity
僅適用于linux，使用該選項(xiàng)可以綁定worker進(jìn)程和CPU（2.4內(nèi)核的機(jī)器用不
了）
假如是8 cpu 分配如下：
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000
00100000 01000000 10000000
nginx可以使用多個(gè)worker進(jìn)程，原因如下：
to use SMP
to decrease latency when workers blockend on disk I/O
to limit number of connections per process when select()/poll() is
used
The worker_processes and worker_connections from the event sections
allows you to calculate maxclients value: k
max_clients = worker_processes * worker_connections
worker_rlimit_nofile 102400;
每個(gè)nginx進(jìn)程打開(kāi)文件描述符最大數(shù)目 配置要和系統(tǒng)的單進(jìn)程打開(kāi)文件數(shù)一
致,linux 2.6內(nèi)核下開(kāi)啟文件打開(kāi)數(shù)為65535，worker_rlimit_nofile就相應(yīng)
應(yīng)該填寫(xiě)65535
nginx調(diào)度時(shí)分配請(qǐng)求到進(jìn)程并不是那么的均衡，假如超過(guò)會(huì)返回502錯(cuò)誤。我
這里寫(xiě)的大一點(diǎn)
use epoll
Nginx使用了最新的epoll（Linux 2.6內(nèi)核）和kqueue（freebsd）網(wǎng)絡(luò)I/O模
型，而Apache則使用的是傳統(tǒng)的select模型。
處理大量的連接的讀寫(xiě)，Apache所采用的select網(wǎng)絡(luò)I/O模型非常低效。
在高并發(fā)服務(wù)器中，輪詢I/O是最耗時(shí)間的操作 目前Linux下能夠承受高并發(fā)
訪問(wèn)的Squid、Memcached都采用的是epoll網(wǎng)絡(luò)I/O模型。
worker_connections 65535;
每個(gè)工作進(jìn)程允許最大的同時(shí)連接數(shù) （Maxclient = work_processes *　worker_connections）
keepalive_timeout 75
keepalive超時(shí)時(shí)間
這里需要注意官方的一句話：
The parameters can differ from each other. Line Keep-Alive:
timeout=time understands Mozilla and Konqueror. MSIE itself shuts
keep-alive connection approximately after 60 seconds.
client_header_buffer_size 16k
large_client_header_buffers 4 32k
客戶請(qǐng)求頭緩沖大小
nginx默認(rèn)會(huì)用client_header_buffer_size這個(gè)buffer來(lái)讀取header值，如果
header過(guò)大，它會(huì)使用large_client_header_buffers來(lái)讀取
如果設(shè)置過(guò)小HTTP頭/Cookie過(guò)大 會(huì)報(bào)400 錯(cuò)誤 nginx 400 bad request
求行如果超過(guò)buffer，就會(huì)報(bào)HTTP 414錯(cuò)誤(URI Too Long)
nginx接受最長(zhǎng)的HTTP頭部大小必須比其中一個(gè)buffer大，否則就會(huì)報(bào)400的
HTTP錯(cuò)誤(Bad Request)。
open_file_cache max 102400
使用字段:http, server, location 這個(gè)指令指定緩存是否啟用,如果啟用,將記錄文件以下信息: ·打開(kāi)的文件描述符,大小信息和修改時(shí)間. ·存在的目錄信息. ·在搜索文件過(guò)程中的錯(cuò)誤信息 -- 沒(méi)有這個(gè)文件,無(wú)法正確讀取,參考o(jì)pen_file_cache_errors 指令選項(xiàng):
·max - 指定緩存的最大數(shù)目,如果緩存溢出,最長(zhǎng)使用過(guò)的文件(LRU)將被移除
例: open_file_cache max=1000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on;
open_file_cache_errors
語(yǔ)法:open_file_cache_errors on | off 默認(rèn)值:open_file_cache_errors off 使用字段:http, server, location 這個(gè)指令指定是否在搜索一個(gè)文件是記錄cache錯(cuò)誤.
open_file_cache_min_uses
語(yǔ)法:open_file_cache_min_uses number 默認(rèn)值:open_file_cache_min_uses 1 使用字段:http, server, location 這個(gè)指令指定了在open_file_cache指令無(wú)效的參數(shù)中一定的時(shí)間范圍內(nèi)可以使用的最小文件數(shù),如 果使用更大的值,文件描述符在cache中總是打開(kāi)狀態(tài).
open_file_cache_valid
語(yǔ)法:open_file_cache_valid time 默認(rèn)值:open_file_cache_valid 60 使用字段:http, server, location 這個(gè)指令指定了何時(shí)需要檢查open_file_cache中緩存項(xiàng)目的有效信息.

開(kāi)啟gzip
gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types text/plain application/x-javascript text/css
application/xml;
gzip_vary on;
緩存靜態(tài)文件：
location ~* ^.+\.(swf|gif|png|jpg|js|css)$ {
root /usr/local/ku6/ktv/show.ku6.com/;
expires 1m;
}

優(yōu)化Linux內(nèi)核參數(shù)
vi /etc/sysctl.conf

# Add
net.ipv4.tcp_max_syn_backlog = 65536
net.core.netdev_max_backlog = 32768
net.core.somaxconn = 32768
net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_tw_recycle = 1
#net.ipv4.tcp_tw_len = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_mem = 94500000 915000000 927000000
net.ipv4.tcp_max_orphans = 3276800
#net.ipv4.tcp_fin_timeout = 30
#net.ipv4.tcp_keepalive_time = 120
net.ipv4.ip_local_port_range = 1024 65535
附錄：一些錯(cuò)誤排查

php-cgi進(jìn)程數(shù)不夠用、php執(zhí)行時(shí)間長(zhǎng)（mysql慢）、或者是php-cgi進(jìn)程死掉
，都會(huì)出現(xiàn)502錯(cuò)誤
一般來(lái)說(shuō)Nginx 502 Bad Gateway和php-fpm.conf的設(shè)置有關(guān)，而Nginx 504 Gateway Time-out則是與nginx.conf的設(shè)置有關(guān)
1、查看當(dāng)前的PHP FastCGI進(jìn)程數(shù)是否夠用：
netstat -anpo | grep "php-cgi" | wc -l
如果實(shí)際使用的“FastCGI進(jìn)程數(shù)”接近預(yù)設(shè)的“FastCGI進(jìn)程數(shù)”，那么
，說(shuō)明“FastCGI進(jìn)程數(shù)”不夠用，需要增大。
2、部分PHP程序的執(zhí)行時(shí)間超過(guò)了Nginx的等待時(shí)間，可以適當(dāng)增加
nginx.conf配置文件中FastCGI的timeout時(shí)間，例如：
http
{
......
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
......
}

413 Request Entity Too Large
增大client_max_body_size
client_max_body_size:指令指定允許客戶端連接的最大請(qǐng)求實(shí)體大小,它出現(xiàn)在請(qǐng)求頭部的Content-Length字段. 如果請(qǐng)求大于指定的值,客戶端將收到一個(gè)"Request Entity Too Large" (413)錯(cuò)誤. 記住,瀏覽器并不知道怎樣顯示這個(gè)錯(cuò)誤.
php.ini中增大
post_max_size 和upload_max_filesize

高層的配置

nginx.conf文件中，Nginx中有shao數(shù)的幾個(gè)高級(jí)配置在模塊部分之上。
user www-data;
pid /var/run/nginx.pid;
worker_processes auto;
worker_rlimit_nofile 100000;

user和pid應(yīng)該按默認(rèn)設(shè)置 - 我們不會(huì)更改這些內(nèi)容，因?yàn)楦呐c否沒(méi)有什么不同。
worker_processes 定義了nginx對(duì)外提供web服務(wù)時(shí)的worker進(jìn)程數(shù)。最優(yōu)值取決于許多因素，包括（但不限于）CPU核的數(shù)量、存儲(chǔ)數(shù)據(jù)的硬盤(pán)數(shù)量及負(fù)載模式。不能確定的時(shí)候，將其設(shè)置為可用的CPU內(nèi)核數(shù)將是一個(gè)好的開(kāi)始（設(shè)置為“auto”將嘗試自動(dòng)檢測(cè)它）。
worker_rlimit_nofile 更改worker進(jìn)程的最大打開(kāi)文件數(shù)限制。如果沒(méi)設(shè)置的話，這個(gè)值為操作系統(tǒng)的限制。設(shè)置后你的操作系統(tǒng)和Nginx可以chǔ理比“ulimit -a”更多的文件，所以把這個(gè)值設(shè)高，這樣nginx就不會(huì)有“too many open files”問(wèn)題了。
Events模塊
events模塊中包含nginx中所有chǔ理連接的設(shè)置。
events {
worker_connections 2048;
multi_accept on;
use epoll;
}

worker_connections 設(shè)置可由一個(gè)worker進(jìn)程同時(shí)打開(kāi)的最大連接數(shù)。如果設(shè)置了上面提到的worker_rlimit_nofile，我們可以將這個(gè)值設(shè)得很高。
記住，最大客戶數(shù)也由系統(tǒng)的可用socket連接數(shù)限制（~ 64K），所以設(shè)置不切實(shí)際的高沒(méi)什么好chǔ。
multi_accept 告訴nginx收到一個(gè)新連接通知后接受盡可能多的連接。
use 設(shè)置用于復(fù)用客戶端線程的輪詢方法。如果你使用Linux 2.6+，你應(yīng)該使用epoll。如果你使用*BSD，你應(yīng)該使用kqueue。
（值得注意的是如果你不知道Nginx該使用哪種輪詢方法的話，它會(huì)選擇一個(gè)最適合你操作系統(tǒng)的）
HTTP 模塊
HTTP模塊控制著nginx httpchǔ理的所有核心特xìng。因?yàn)檫@里只有很shao的配置，所以我們只節(jié)選配置的一小部分。所有這些設(shè)置都應(yīng)該在http模塊中，甚至你不會(huì)特別的注意到這段設(shè)置。
http {
server_tokens off;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
...
}

server_tokens  并不會(huì)讓nginx執(zhí)行的速度更快，但它可以關(guān)閉在錯(cuò)誤頁(yè)面中的nginx版本數(shù)字，這樣對(duì)于安全xìng是有好chǔ的。
sendfile 可以讓sendfile()發(fā)揮作用。sendfile()可以在磁盤(pán)和TCP socket之間互相拷貝數(shù)據(jù)(或任意兩個(gè)文件描述符)。Pre-sendfile是傳送數(shù)據(jù)之前在用戶空間申請(qǐng)數(shù)據(jù)緩沖區(qū)。之后用read()將數(shù)據(jù)從文件拷貝到這個(gè)緩沖區(qū)，write()將緩沖區(qū)數(shù)據(jù)寫(xiě)入網(wǎng)絡(luò)。sendfile()是立即將數(shù)據(jù)從磁盤(pán)讀到OS緩存。因?yàn)檫@種拷貝是在內(nèi)核完成的，sendfile()要比組合read()和write()以及打開(kāi)關(guān)閉丟棄緩沖更加有效(更多有關(guān)于sendfile)。
tcp_nopush 告訴nginx在一個(gè)數(shù)據(jù)包里發(fā)送所有頭文件，而不一個(gè)接一個(gè)的發(fā)送。
tcp_nodelay 告訴nginx不要緩存數(shù)據(jù)，而是一段一段的發(fā)送--當(dāng)需要及時(shí)發(fā)送數(shù)據(jù)時(shí)，就應(yīng)該給應(yīng)用設(shè)置這個(gè)屬xìng，這樣發(fā)送一小塊數(shù)據(jù)信息時(shí)就不能立即得到返回值。
access_log off;
error_log /var/log/nginx/error.log crit;

access_log 設(shè)置nginx是否將存儲(chǔ)訪問(wèn)日志。關(guān)閉這個(gè)選項(xiàng)可以讓讀取磁盤(pán)IO操作更快(aka,YOLO)
error_log 告訴nginx只能記錄嚴(yán)重的錯(cuò)誤：
keepalive_timeout 10;
client_header_timeout 10;
client_body_timeout 10;
reset_timedout_connection on;
send_timeout 10;

keepalive_timeout  給客戶端分配keep-alive鏈接超時(shí)時(shí)間。服務(wù)器將在這個(gè)超時(shí)時(shí)間過(guò)后關(guān)閉鏈接。我們將它設(shè)置低些可以讓ngnix持續(xù)工作的時(shí)間更長(zhǎng)。
client_header_timeout 和client_body_timeout 設(shè)置請(qǐng)求頭和請(qǐng)求體(各自)的超時(shí)時(shí)間。我們也可以把這個(gè)設(shè)置低些。
reset_timeout_connection 告訴nginx關(guān)閉不響應(yīng)的客戶端連接。這將會(huì)釋放那個(gè)客戶端所占有的內(nèi)存空間。
send_timeout 指定客戶端的響應(yīng)超時(shí)時(shí)間。這個(gè)設(shè)置不會(huì)用于整個(gè)轉(zhuǎn)發(fā)器，而是在兩次客戶端讀取操作之間。如果在這段時(shí)間內(nèi)，客戶端沒(méi)有讀取任何數(shù)據(jù)，nginx就會(huì)關(guān)閉連接。
limit_conn_zone $binary_remote_addr zone=addr:5m;
limit_conn addr 100;

limit_conn_zone 設(shè)置用于保存各種key（比如當(dāng)前連接數(shù)）的共享內(nèi)存的參數(shù)。5m就是5兆字節(jié)，這個(gè)值應(yīng)該被設(shè)置的足夠大以存儲(chǔ)（32K*5）32byte狀態(tài)或者（16K*5）64byte狀態(tài)。
limit_conn 為給定的key設(shè)置最大連接數(shù)。這里key是addr，我們?cè)O(shè)置的值是100，也就是說(shuō)我們?cè)试S每一個(gè)IP地址最多同時(shí)打開(kāi)有100個(gè)連接。
include /etc/nginx/mime.types;
default_type text/html;
charset UTF-8;

include 只是一個(gè)在當(dāng)前文件中包含另一個(gè)文件內(nèi)容的指令。這里我們使用它來(lái)加載稍后會(huì)用到的一系列的MIME類型。
default_type 設(shè)置文件使用的默認(rèn)的MIME-type。
charset 設(shè)置我們的頭文件中的默認(rèn)的字符集
gzip on;
gzip_disable "msie6";
# gzip_static on;
gzip_proxied any;
gzip_min_length 1000;
gzip_comp_level 4;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

gzip 是告訴nginx采用gzip壓縮的形式發(fā)送數(shù)據(jù)。這將會(huì)減shao我們發(fā)送的數(shù)據(jù)量。
gzip_disable 為指定的客戶端禁用gzip功能。我們?cè)O(shè)置成IE6或者更低版本以使我們的方案能夠廣泛兼容。
gzip_static 告訴nginx在壓縮資源之前，先查找是否有預(yù)先gzipchǔ理過(guò)的資源。這要求你預(yù)先壓縮你的文件（在這個(gè)例子中被注釋掉了），從而允許你使用最高壓縮比，這樣nginx就不用再壓縮這些文件了（想要更詳盡的gzip_static的信息，請(qǐng)點(diǎn)擊這里）。
gzip_proxied 允許或者禁止壓縮基于請(qǐng)求和響應(yīng)的響應(yīng)流。我們?cè)O(shè)置為any，意味著將會(huì)壓縮所有的請(qǐng)求。
gzip_min_length 設(shè)置對(duì)數(shù)據(jù)啟用壓縮的最shao字節(jié)數(shù)。如果一個(gè)請(qǐng)求小于1000字節(jié)，我們最好不要壓縮它，因?yàn)閴嚎s這些小的數(shù)據(jù)會(huì)降低chǔ理此請(qǐng)求的所有進(jìn)程的速度。
gzip_comp_level 設(shè)置數(shù)據(jù)的壓縮等級(jí)。這個(gè)等級(jí)可以是1-9之間的任意數(shù)值，9是最慢但是壓縮比最大的。我們?cè)O(shè)置為4，這是一個(gè)比較折中的設(shè)置。
gzip_type 設(shè)置需要壓縮的數(shù)據(jù)格式。上面例子中已經(jīng)有一些了，你也可以再添加更多的格式。
# cache informations about file descriptors, frequently accessed files
# can boost performance, but you need to test those values
open_file_cache max=100000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
##
# Virtual Host Configs
# aka our settings for specific servers
##
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

open_file_cache 打開(kāi)緩存的同時(shí)也指定了緩存最大數(shù)目，以及緩存的時(shí)間。我們可以設(shè)置一個(gè)相對(duì)高的最大時(shí)間，這樣我們可以在它們不活動(dòng)超過(guò)20秒后清除掉。
open_file_cache_valid 在open_file_cache中指定檢測(cè)正確信息的間隔時(shí)間。
open_file_cache_min_uses 定義了open_file_cache中指令參數(shù)不活動(dòng)時(shí)間期間里最小的文件數(shù)。
open_file_cache_errors 指定了當(dāng)搜索一個(gè)文件時(shí)是否緩存錯(cuò)誤信息，也包括再次給配置中添加文件。我們也包括了服務(wù)器模塊，這些是在不同文件中定義的。如果你的服務(wù)器模塊不在這些位置，你就得修改這一行來(lái)指定正確的位置。

一個(gè)完整的配置

user www-data;
pid /var/run/nginx.pid;
worker_processes auto;
worker_rlimit_nofile 100000;
events {
worker_connections 2048;
multi_accept on;
use epoll;
}
http {
server_tokens off;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
access_log off;
error_log /var/log/nginx/error.log crit;
keepalive_timeout 10;
client_header_timeout 10;
client_body_timeout 10;
reset_timedout_connection on;
send_timeout 10;
limit_conn_zone $binary_remote_addr zone=addr:5m;
limit_conn addr 100;
include /etc/nginx/mime.types;
default_type text/html;
charset UTF-8;
gzip on;
gzip_disable "msie6";
gzip_proxied any;
gzip_min_length 1000;
gzip_comp_level 6;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
open_file_cache max=100000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}

編輯完配置后，確認(rèn)重啟nginx使設(shè)置生效。
sudo service nginx restart