最近花了一點(diǎn)時(shí)間進(jìn)行了NGINX加TOMCAT7集群壓力測試，下面通過對一些常見問題的回答來說明如何調(diào)優(yōu)服務(wù)器的性能，是自己的一些經(jīng)驗(yàn)，且無實(shí)際數(shù)據(jù)，如有紕漏請見諒。
背景: TOMCAT7已加APR或者NIO。已裝簡單監(jiān)控JCONSOLE,監(jiān)控服務(wù)器內(nèi)存，線程等基本情況。
問題1 一個(gè)Tomcat他的maxThreads到底配置多少合適?
一個(gè)好的maxThreads的配置就是達(dá)到資源的合理化應(yīng)用。
資源池：
在講其它東西之前，我們先引入一個(gè)概念，就是資源池。tomcat7中，他對http請求的處理，也有一個(gè)池的概念，配置可以參考這里。每一個(gè)請求進(jìn)來后都是使用線程池中的一個(gè)來處理，線程池的大小是由maxThreads來限定的。
異步IO：
當(dāng)前Tomcat通過使用JAVA NIO或者Apache Portable Runtime這樣的異步IO來支持性能的優(yōu)化。異步IO就是當(dāng)應(yīng)用需要進(jìn)行耗時(shí)的IO操作時(shí)，向內(nèi)核發(fā)出請求，不用真正等IO操作完成，就去處理其它的請求了，當(dāng)IO真正完成時(shí)會(huì)有回調(diào)或通知機(jī)制通知并完成余下工作。而一般的同步IO是當(dāng)應(yīng)用需要IO操作時(shí)，向操作系統(tǒng)發(fā)出IO Read/Write請求。同時(shí)阻塞當(dāng)前應(yīng)用，并等待IO返回，返回后才進(jìn)行后續(xù)的操作。從這里可以看出異步IO實(shí)際是將請求的處理和IO處理并行了，這樣自然能較大的提高系統(tǒng)的吞吐量。
maxThreads的大小:
第一點(diǎn)：從上面的異步IO的機(jī)制來看，實(shí)際上我們可能可以用一個(gè)很小的線程池處理較大的連接數(shù)。如當(dāng)前有100個(gè)請求要被處理，處理過程中50個(gè)進(jìn)程都處于IO等待的狀態(tài)，所以我們實(shí)際可能只需要50就能夠處理那些不處于IO等待狀態(tài)的請求就能滿足需要了。注意在Tomcat中是使用maxConnection這個(gè)配置參數(shù)來配置Tomcat的同時(shí)處理連接數(shù)的。
第二點(diǎn)：盲目的加大線程數(shù)會(huì)帶來一些下面的影響。由于Tomcat處理的線程均會(huì)在操作系統(tǒng)中產(chǎn)生對應(yīng)的實(shí)際線程，這就意味著對應(yīng)的資源消耗（內(nèi)存，SOCKET等）。另一個(gè)影響就是同時(shí)處理的請求加大可能導(dǎo)致JAVA內(nèi)存回收的問題,不同的并發(fā)對內(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占用和更多的硬盤讀寫。這些實(shí)際都跟硬件有關(guān)。
第三點(diǎn)： 我們可以通過配置一個(gè)較合理的資源池，由于資源充裕，單個(gè)請求處理迅速，這樣能達(dá)到最優(yōu)的系統(tǒng)效率。但是有的時(shí)候我們并不總是追求這樣的一種情況。比如下載時(shí)，單個(gè)請求的響應(yīng)時(shí)間將受限于網(wǎng)絡(luò)，下100M的包可能需要20分鐘，我們就不應(yīng)該通過一個(gè)較小的資源池來提升整體的效率，而應(yīng)該配置一個(gè)較大的資源池，讓較多用戶連接上并進(jìn)行下載，否則多數(shù)的用戶都將會(huì)因超時(shí)被拒絕，從而造成連接上的超快，連不上的就直接被拒絕。
第四點(diǎn)：單個(gè)JVM的內(nèi)存分配較大將導(dǎo)致Full Gc(Stop The World)的中斷時(shí)間變得更長，影響實(shí)時(shí)性。高的可達(dá)10秒以上的停頓，這段時(shí)間所有的東西將被掛起。
配置大小優(yōu)化思路:
配置時(shí)應(yīng)該根據(jù)你應(yīng)用的實(shí)際情況,是最占CPU,內(nèi)存還是IO，最后達(dá)到一個(gè)平衡就好，下面來說明思路。
1. 自行保證服務(wù)器的資源較夠用，如IO、CPU、內(nèi)存。
2. 在硬件較充裕的情況下嘗試以maxThreads配置300、600、1200、1800，分析Tomcat的連接時(shí)間，請求耗時(shí)，吞吐量等參數(shù)。在測試的時(shí)候需要密切注意硬盤、帶寬、CPU、內(nèi)存是否處于一個(gè)瓶頸情況下。
3. 其實(shí)所有的東西最后都有一個(gè)極限就是硬件。應(yīng)用分CPU，IO，內(nèi)存密集型，這些都會(huì)成為你最終的限制性因素。一般應(yīng)用根據(jù)自己的特性劃分到不同的機(jī)群中，如CPU密集型的會(huì)分到一群有更好CPU的集群中。這樣可以能充分利用資源。我們以常見的內(nèi)存為最終限制性因素，并假設(shè)CPU足夠好，且IO很少來說明思路。通過一些壓測工具，我們能容易的找到一個(gè)在300~8000的并發(fā)數(shù)的情況下一個(gè)性能的拐點(diǎn)，通過對比不同線程數(shù)下請求連接時(shí)間、單請求的平均響應(yīng)時(shí)間，總體的吞吐量。這個(gè)拐點(diǎn)往往意味著此時(shí)的內(nèi)存回收出現(xiàn)異常，JVM花了更多的時(shí)間在回收內(nèi)存,我們一般可以通過打出gc日志，并使用jmeter等工具來分析得知。此時(shí)你可以嘗試優(yōu)化內(nèi)存結(jié)構(gòu)或加大內(nèi)存 來解決，若不能解決，可能就意味你前一次的配置就是一個(gè)好的選擇。當(dāng)然這些限制因素是可能互相轉(zhuǎn)換的，可能你增加了內(nèi)存之后內(nèi)存沒有問題了，但是卻導(dǎo)致CPU達(dá)到100%，從而導(dǎo)致性能下降。此時(shí)則要以CPU為最終限制性因素了。
優(yōu)化測試中陷阱：
以一個(gè)下載服務(wù)器來例子說明。我們以下載10m的包來做測試，其實(shí)你會(huì)發(fā)現(xiàn)整個(gè)服務(wù)器的吞吐量很差，響應(yīng)時(shí)間慢。但細(xì)心的人會(huì)發(fā)現(xiàn)此時(shí)連接服務(wù)器的時(shí)間卻是很快的，也就是說服務(wù)器很快accpet了你的請求，雖然你的吞吐量不大，處理耗時(shí)也大。原因是什么呢,其實(shí)是你的帶寬已經(jīng)被占滿了，你會(huì)發(fā)現(xiàn)并發(fā)下載10個(gè)文件就能占滿你的所有帶寬。所以此時(shí)呢你的測試時(shí)的對比對象變成了對比連接時(shí)間會(huì)更加合理。
當(dāng)然你也可以通過減少包的大小，比如降到 1k，以使帶寬不成為瓶頸.這樣可能測試出來你的服務(wù)器并發(fā)極限量，但該并發(fā)量可能并不能反應(yīng)出實(shí)際下載的情況，實(shí)際的情況就是帶寬容易被占滿,下載服務(wù)器會(huì)有一個(gè)很大量的連接存在的情況。
問題2. NGINX到底能帶來怎么樣的性能提升，或者說有什么好處？
1. 測試后發(fā)現(xiàn)，NGINX并不能加快響應(yīng)的速度，為什么呢，因?yàn)檫@是由于NGINX會(huì)代理你同后端的請求。也就意味著你原來只需要建立同服務(wù)器的一次連接即可完成請求，現(xiàn)在變成了先同NGINX建立連接，NGINX再同后端建立連接。所以引入NGINX后帶來了更多的時(shí)間消耗，兩倍的SOCKET連接消耗。
2. 引入后的好處體現(xiàn)如下。
1) 整體的性能會(huì)有提升，通過實(shí)測后發(fā)現(xiàn)能很大程度上降低最大返回耗時(shí)的情況。請求返回更穩(wěn)定。
2) 降低后端的資源消耗。原來由于客戶端網(wǎng)絡(luò)較慢等因素會(huì)讓后端在返回?cái)?shù)據(jù)時(shí)處于繁忙的情況，占用資源。通過NGINX向后端代理，同時(shí)由于NGINX的緩存機(jī)制，后端可以快速返回，并將資源更集中用到處理請求上，這樣可以發(fā)揮后端的能力。NGINX在保持大量連接這塊就得很優(yōu)秀，內(nèi)存，CPU都占用很少。
3) 支持非常方便的擴(kuò)展，高可用性等。
基本的 (優(yōu)化過的)配置
我們將修改的唯一文件是nginx.conf，其中包含Nginx不同模塊的所有設(shè)置。你應(yīng)該能夠在服務(wù)器的/etc/nginx目錄中找到nginx.conf。首先，我們將談?wù)撘恍┤衷O(shè)置，然后按文件中的模塊挨個(gè)來，談一下哪些設(shè)置能夠讓你在大量客戶端訪問時(shí)擁有良好的xìng能，為什么它們會(huì)提高xìng能。本文的結(jié)尾有一個(gè)完整的配置文件。
nginx要開啟的進(jìn)程數(shù) 一般等于cpu的總核數(shù) 其實(shí)一般情況下開4個(gè)或8個(gè)就可 我開2個(gè)
以了 多了沒有太多用
每個(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)程打開文件描述符最大數(shù)目 配置要和系統(tǒng)的單進(jìn)程打開文件數(shù)一
致,linux 2.6內(nèi)核下開啟文件打開數(shù)為65535，worker_rlimit_nofile就相應(yīng)
應(yīng)該填寫65535
nginx調(diào)度時(shí)分配請求到進(jìn)程并不是那么的均衡，假如超過會(huì)返回502錯(cuò)誤。我
這里寫的大一點(diǎn)
use epoll
Nginx使用了最新的epoll（Linux 2.6內(nèi)核）和kqueue（freebsd）網(wǎng)絡(luò)I/O模
型，而Apache則使用的是傳統(tǒng)的select模型。
處理大量的連接的讀寫，Apache所采用的select網(wǎng)絡(luò)I/O模型非常低效。
在高并發(fā)服務(wù)器中，輪詢I/O是最耗時(shí)間的操作 目前Linux下能夠承受高并發(fā)
訪問的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
客戶請求頭緩沖大小
nginx默認(rèn)會(huì)用client_header_buffer_size這個(gè)buffer來讀取header值，如果
header過大，它會(huì)使用large_client_header_buffers來讀取
如果設(shè)置過小HTTP頭/Cookie過大 會(huì)報(bào)400 錯(cuò)誤 nginx 400 bad request
求行如果超過buffer，就會(huì)報(bào)HTTP 414錯(cuò)誤(URI Too Long)
nginx接受最長的HTTP頭部大小必須比其中一個(gè)buffer大，否則就會(huì)報(bào)400的
HTTP錯(cuò)誤(Bad Request)。
open_file_cache max 102400
使用字段:http, server, location 這個(gè)指令指定緩存是否啟用,如果啟用,將記錄文件以下信息: ·打開的文件描述符,大小信息和修改時(shí)間. ·存在的目錄信息. ·在搜索文件過程中的錯(cuò)誤信息 -- 沒有這個(gè)文件,無法正確讀取,參考o(jì)pen_file_cache_errors 指令選項(xiàng):
·max - 指定緩存的最大數(shù)目,如果緩存溢出,最長使用過的文件(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
語法: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
語法:open_file_cache_min_uses number 默認(rèn)值:open_file_cache_min_uses 1 使用字段:http, server, location 這個(gè)指令指定了在open_file_cache指令無效的參數(shù)中一定的時(shí)間范圍內(nèi)可以使用的最小文件數(shù),如 果使用更大的值,文件描述符在cache中總是打開狀態(tài).
open_file_cache_valid
語法:open_file_cache_valid time 默認(rèn)值:open_file_cache_valid 60 使用字段:http, server, location 這個(gè)指令指定了何時(shí)需要檢查open_file_cache中緩存項(xiàng)目的有效信息.
開啟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í)間長（mysql慢）、或者是php-cgi進(jìn)程死掉
，都會(huì)出現(xiàn)502錯(cuò)誤
一般來說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ù)”，那么
，說明“FastCGI進(jìn)程數(shù)”不夠用，需要增大。
2、部分PHP程序的執(zhí)行時(shí)間超過了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:指令指定允許客戶端連接的最大請求實(shí)體大小,它出現(xiàn)在請求頭部的Content-Length字段. 如果請求大于指定的值,客戶端將收到一個(gè)"Request Entity Too Large" (413)錯(cuò)誤. 記住,瀏覽器并不知道怎樣顯示這個(gè)錯(cuò)誤.
php.ini中增大
post_max_size 和upload_max_filesize
高層的配置
nginx.conf文件中，Nginx中有shao數(shù)的幾個(gè)高級配置在模塊部分之上。
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否沒有什么不同。
worker_processes 定義了nginx對外提供web服務(wù)時(shí)的worker進(jìn)程數(shù)。最優(yōu)值取決于許多因素，包括（但不限于）CPU核的數(shù)量、存儲數(shù)據(jù)的硬盤數(shù)量及負(fù)載模式。不能確定的時(shí)候，將其設(shè)置為可用的CPU內(nèi)核數(shù)將是一個(gè)好的開始（設(shè)置為“auto”將嘗試自動(dòng)檢測它）。
worker_rlimit_nofile 更改worker進(jìn)程的最大打開文件數(shù)限制。如果沒設(shè)置的話，這個(gè)值為操作系統(tǒng)的限制。設(shè)置后你的操作系統(tǒng)和Nginx可以chǔ理比“ulimit -a”更多的文件，所以把這個(gè)值設(shè)高，這樣nginx就不會(huì)有“too many open files”問題了。
Events模塊
events模塊中包含nginx中所有chǔ理連接的設(shè)置。
events {
worker_connections 2048;
multi_accept on;
use epoll;
}
worker_connections 設(shè)置可由一個(gè)worker進(jìn)程同時(shí)打開的最大連接數(shù)。如果設(shè)置了上面提到的worker_rlimit_nofile，我們可以將這個(gè)值設(shè)得很高。
記住，最大客戶數(shù)也由系統(tǒng)的可用socket連接數(shù)限制（~ 64K），所以設(shè)置不切實(shí)際的高沒什么好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ò)誤頁面中的nginx版本數(shù)字，這樣對于安全xìng是有好chǔ的。
sendfile 可以讓sendfile()發(fā)揮作用。sendfile()可以在磁盤和TCP socket之間互相拷貝數(shù)據(jù)(或任意兩個(gè)文件描述符)。Pre-sendfile是傳送數(shù)據(jù)之前在用戶空間申請數(shù)據(jù)緩沖區(qū)。之后用read()將數(shù)據(jù)從文件拷貝到這個(gè)緩沖區(qū)，write()將緩沖區(qū)數(shù)據(jù)寫入網(wǎng)絡(luò)。sendfile()是立即將數(shù)據(jù)從磁盤讀到OS緩存。因?yàn)檫@種拷貝是在內(nèi)核完成的，sendfile()要比組合read()和write()以及打開關(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是否將存儲訪問日志。關(guān)閉這個(gè)選項(xiàng)可以讓讀取磁盤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ān)閉鏈接。我們將它設(shè)置低些可以讓ngnix持續(xù)工作的時(shí)間更長。
client_header_timeout 和client_body_timeout 設(shè)置請求頭和請求體(各自)的超時(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)，客戶端沒有讀取任何數(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è)置的足夠大以存儲（32K*5）32byte狀態(tài)或者（16K*5）64byte狀態(tài)。
limit_conn 為給定的key設(shè)置最大連接數(shù)。這里key是addr，我們設(shè)置的值是100，也就是說我們允許每一個(gè)IP地址最多同時(shí)打開有100個(gè)連接。
include /etc/nginx/mime.types;
default_type text/html;
charset UTF-8;
include 只是一個(gè)在當(dāng)前文件中包含另一個(gè)文件內(nè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功能。我們設(shè)置成IE6或者更低版本以使我們的方案能夠廣泛兼容。
gzip_static 告訴nginx在壓縮資源之前，先查找是否有預(yù)先gzipchǔ理過的資源。這要求你預(yù)先壓縮你的文件（在這個(gè)例子中被注釋掉了），從而允許你使用最高壓縮比，這樣nginx就不用再壓縮這些文件了（想要更詳盡的gzip_static的信息，請點(diǎn)擊這里）。
gzip_proxied 允許或者禁止壓縮基于請求和響應(yīng)的響應(yīng)流。我們設(shè)置為any，意味著將會(huì)壓縮所有的請求。
gzip_min_length 設(shè)置對數(shù)據(jù)啟用壓縮的最shao字節(jié)數(shù)。如果一個(gè)請求小于1000字節(jié)，我們最好不要壓縮它，因?yàn)閴嚎s這些小的數(shù)據(jù)會(huì)降低chǔ理此請求的所有進(jìn)程的速度。
gzip_comp_level 設(shè)置數(shù)據(jù)的壓縮等級。這個(gè)等級可以是1-9之間的任意數(shù)值，9是最慢但是壓縮比最大的。我們設(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 打開緩存的同時(shí)也指定了緩存最大數(shù)目，以及緩存的時(shí)間。我們可以設(shè)置一個(gè)相對高的最大時(shí)間，這樣我們可以在它們不活動(dòng)超過20秒后清除掉。
open_file_cache_valid 在open_file_cache中指定檢測正確信息的間隔時(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ù)器模塊不在這些位置，你就得修改這一行來指定正確的位置。
一個(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
