# This number should be, at maximum, the number of CPU cores on your system.
    # (since nginx doesn't benefit from more than one worker per CPU.)
    # 這里的數(shù)值不能超過 CPU 的總核數(shù)，因為在單個核上部署超過 1 個 Nginx 服務(wù)進程并不起到提高性能的作用。
    worker_processes 24;
 
    # Number of file descriptors used for Nginx. This is set in the OS with 'ulimit -n 200000'
    # or using /etc/security/limits.conf
    # Nginx 最大可用文件描述符數(shù)量，同時需要配置操作系統(tǒng)的 "ulimit -n 200000"，或者在 /etc/security/limits.conf 中配置。 
    worker_rlimit_nofile 200000;
 
    # only log critical errors
    # 只記錄 critical 級別的錯誤日志
    error_log /var/log/nginx/error.log crit
 
    # Determines how many clients will be served by each worker process.
    # (Max clients = worker_connections * worker_processes)
    # "Max clients" is also limited by the number of socket connections available on the system (~64k)
    # 配置單個 Nginx 單個進程可服務(wù)的客戶端數(shù)量，（最大值客戶端數(shù) = 單進程連接數(shù) * 進程數(shù) ）
    # 最大客戶端數(shù)同時也受操作系統(tǒng) socket 連接數(shù)的影響（最大 64K ）
    worker_connections 4000;
 
    # essential for linux, optmized to serve many clients with each thread
    # Linux 關(guān)鍵配置，允許單個線程處理多個客戶端請求。
    use epoll;
 
    # Accept as many connections as possible, after nginx gets notification about a new connection.
    # May flood worker_connections, if that option is set too low.
    # 允許盡可能地處理更多的連接數(shù)，如果 worker_connections 配置太低，會產(chǎn)生大量的無效連接請求。
    multi_accept on;
 
    # Caches information about open FDs, freqently accessed files.
    # Changing this setting, in my environment, brought performance up from 560k req/sec, to 904k req/sec.
    # I recommend using some varient of these options, though not the specific values listed below.
    # 緩存高頻操作文件的FDs（文件描述符/文件句柄）
    # 在我的設(shè)備環(huán)境中，通過修改以下配置，性能從 560k 請求/秒 提升到 904k 請求/秒。
    # 我建議你對以下配置嘗試不同的組合，而不是直接使用這幾個數(shù)據(jù)。
    open_file_cache max=200000 inactive=20s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 2;
    open_file_cache_errors on;
 
    # Buffer log writes to speed up IO, or disable them altogether
    # 將日志寫入高速 IO 存儲設(shè)備，或者直接關(guān)閉日志。
    # access_log /var/log/nginx/access.log main buffer=16k;
    access_log off;
 
    # Sendfile copies data between one FD and other from within the kernel.
    # More efficient than read() + write(), since the requires transferring data to and from the user space.
    # 開啟 sendfile 選項，使用內(nèi)核的 FD 文件傳輸功能，這個比在用戶態(tài)用 read() + write() 的方式更加高效。
    sendfile on;
 
    # Tcp_nopush causes nginx to attempt to send its HTTP response head in one packet,
    # instead of using partial frames. This is useful for prepending headers before calling sendfile,
    # or for throughput optimization.
    # 打開 tcp_nopush 選項，Nginux 允許將 HTTP 應(yīng)答首部與數(shù)據(jù)內(nèi)容在同一個報文中發(fā)出。
    # 這個選項使服務(wù)器在 sendfile 時可以提前準備 HTTP 首部，能夠達到優(yōu)化吞吐的效果。
    tcp_nopush on;
 
    # don't buffer data-sends (disable Nagle algorithm). Good for sending frequent small bursts of data in real time.
    # 不要緩存 data-sends （關(guān)閉 Nagle 算法），這個能夠提高高頻發(fā)送小數(shù)據(jù)報文的實時性。
    tcp_nodelay on;
 
    # Timeout for keep-alive connections. Server will close connections after this time.
    # 配置連接 keep-alive 超時時間，服務(wù)器將在超時之后關(guān)閉相應(yīng)的連接。
    keepalive_timeout 30;
 
    # Number of requests a client can make over the keep-alive connection. This is set high for testing.
    # 單個客戶端在 keep-alive 連接上可以發(fā)送的請求數(shù)量，在測試環(huán)境中，需要配置個比較大的值。
    keepalive_requests 100000;
 
    # allow the server to close the connection after a client stops responding. Frees up socket-associated memory.
    # 允許服務(wù)器在客戶端停止發(fā)送應(yīng)答之后關(guān)閉連接，以便釋放連接相應(yīng)的 socket 內(nèi)存開銷。
    reset_timedout_connection on;
 
    # send the client a "request timed out" if the body is not loaded by this time. Default 60.
    # 配置客戶端數(shù)據(jù)請求超時時間，默認是 60 秒。
    client_body_timeout 10;
 
    # If the client stops reading data, free up the stale client connection after this much time. Default 60.
    # 客戶端數(shù)據(jù)讀超時配置，客戶端停止讀取數(shù)據(jù)，超時時間后斷開相應(yīng)連接，默認是 60 秒。
    send_timeout 2;
 
    # Compression. Reduces the amount of data that needs to be transferred over the network
    # 壓縮參數(shù)配置，減少在網(wǎng)絡(luò)上所傳輸?shù)臄?shù)據(jù)量。
    gzip on;
    gzip_min_length 10240;
    gzip_proxied expired no-cache no-store private auth;
    gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml;
    gzip_disable "MSIE [1-6].";

內(nèi)核調(diào)優(yōu)：
vim /etc/sysctl.conf

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

# Increase system IP port limits to allow for more connections # 調(diào)高系統(tǒng)的 IP 以及端口數(shù)據(jù)限制，從可以接受更多的連接 net.ipv4.ip_local_port_range = 2000 65000   net.ipv4.tcp_window_scaling = 1   # number of packets to keep in backlog before the kernel starts dropping them # 設(shè)置協(xié)議棧可以緩存的報文數(shù)閥值，超過閥值的報文將被內(nèi)核丟棄 net.ipv4.tcp_max_syn_backlog = 3240000   # increase socket listen backlog # 調(diào)高 socket 偵聽數(shù)閥值 net.core.somaxconn = 3240000 net.ipv4.tcp_max_tw_buckets = 1440000   # Increase TCP buffer sizes # 調(diào)大 TCP 存儲大小 net.core.rmem_default = 8388608 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.ipv4.tcp_congestion_control = cubic

sysctl -p /etc/sysctl.conf

Nginx配置性能優(yōu)化

大多數(shù)的Nginx安裝指南告訴你如下基礎(chǔ)知識——通過apt-get安裝，修改這里或那里的幾行配置，好了，你已經(jīng)有了一個Web服務(wù)器了。而且，在大多數(shù)情況下，一個常規(guī)安裝的nginx對你的網(wǎng)站來說已經(jīng)能很好地工作了。然而，如果你真的想擠壓出Nginx的性能，你必須更深入一些。在本指南中，我將解釋Nginx的那些設(shè)置可以微調(diào)，以優(yōu)化處理大量客戶端時的性能。需要注意一點，這不是一個全面的微調(diào)指南。這是一個簡單的預(yù)覽——那些可以通過微調(diào)來提高性能設(shè)置的概述。你的情況可能不同。

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

我們將修改的唯一文件是nginx.conf，其中包含Nginx不同模塊的所有設(shè)置。你應(yīng)該能夠在服務(wù)器的/etc/nginx目錄中找到nginx.conf。首先，我們將談?wù)撘恍┤衷O(shè)置，然后按文件中的模塊挨個來，談一下哪些設(shè)置能夠讓你在大量客戶端訪問時擁有良好的性能，為什么它們會提高性能。本文的結(jié)尾有一個完整的配置文件。

高層的配置

nginx.conf文件中，Nginx中有少數(shù)的幾個高級配置在模塊部分之上。

user www-data; 
pid /var/run/nginx.pid; 
worker_processes auto; 
worker_rlimit_nofile 100000; 

user和pid應(yīng)該按默認設(shè)置 - 我們不會更改這些內(nèi)容，因為更改與否沒有什么不同。

worker_processes 定義了nginx對外提供web服務(wù)時的worker進程數(shù)。最優(yōu)值取決于許多因素，包括（但不限于）CPU核的數(shù)量、存儲數(shù)據(jù)的硬盤數(shù)量及負載模式。不能確定的時候，將其設(shè)置為可用的CPU內(nèi)核數(shù)將是一個好的開始（設(shè)置為“auto”將嘗試自動檢測它）。

worker_rlimit_nofile 更改worker進程的最大打開文件數(shù)限制。如果沒設(shè)置的話，這個值為操作系統(tǒng)的限制。設(shè)置后你的操作系統(tǒng)和Nginx可以處理比“ulimit -a”更多的文件，所以把這個值設(shè)高，這樣nginx就不會有“too many open files”問題了。

Events模塊

events模塊中包含nginx中所有處理連接的設(shè)置。

events { 
worker_connections 2048; 
multi_accept on; 
use epoll; 
} 

worker_connections 設(shè)置可由一個worker進程同時打開的最大連接數(shù)。如果設(shè)置了上面提到的worker_rlimit_nofile，我們可以將這個值設(shè)得很高。

記住，最大客戶數(shù)也由系統(tǒng)的可用socket連接數(shù)限制（~ 64K），所以設(shè)置不切實際的高沒什么好處。

multi_accept 告訴nginx收到一個新連接通知后接受盡可能多的連接。

use 設(shè)置用于復(fù)用客戶端線程的輪詢方法。如果你使用Linux 2.6+，你應(yīng)該使用epoll。如果你使用*BSD，你應(yīng)該使用kqueue。

（值得注意的是如果你不知道Nginx該使用哪種輪詢方法的話，它會選擇一個最適合你操作系統(tǒng)的）

HTTP 模塊

HTTP模塊控制著nginx http處理的所有核心特性。因為這里只有很少的配置，所以我們只節(jié)選配置的一小部分。所有這些設(shè)置都應(yīng)該在http模塊中，甚至你不會特別的注意到這段設(shè)置。

http { 
server_tokens off; 
sendfile on; 
tcp_nopush on; 
tcp_nodelay on; 
... 
} 

server_tokens  并不會讓nginx執(zhí)行的速度更快，但它可以關(guān)閉在錯誤頁面中的nginx版本數(shù)字，這樣對于安全性是有好處的。

sendfile 可以讓sendfile()發(fā)揮作用。sendfile()可以在磁盤和TCP socket之間互相拷貝數(shù)據(jù)(或任意兩個文件描述符)。Pre-sendfile是傳送數(shù)據(jù)之前在用戶空間申請數(shù)據(jù)緩沖區(qū)。之后用read()將數(shù)據(jù)從文件拷貝到這個緩沖區(qū)，write()將緩沖區(qū)數(shù)據(jù)寫入網(wǎng)絡(luò)。sendfile()是立即將數(shù)據(jù)從磁盤讀到OS緩存。因為這種拷貝是在內(nèi)核完成的，sendfile()要比組合read()和write()以及打開關(guān)閉丟棄緩沖更加有效(更多有關(guān)于sendfile)。

tcp_nopush 告訴nginx在一個數(shù)據(jù)包里發(fā)送所有頭文件，而不一個接一個的發(fā)送。

tcp_nodelay 告訴nginx不要緩存數(shù)據(jù)，而是一段一段的發(fā)送--當需要及時發(fā)送數(shù)據(jù)時，就應(yīng)該給應(yīng)用設(shè)置這個屬性，這樣發(fā)送一小塊數(shù)據(jù)信息時就不能立即得到返回值。

access_log off; 
error_log /var/log/nginx/error.log crit; 

access_log 設(shè)置nginx是否將存儲訪問日志。關(guān)閉這個選項可以讓讀取磁盤IO操作更快(aka,YOLO)

error_log 告訴nginx只能記錄嚴重的錯誤：

keepalive_timeout 10; 
client_header_timeout 10; 
client_body_timeout 10; 
reset_timedout_connection on; 
send_timeout 10; 

keepalive_timeout  給客戶端分配keep-alive鏈接超時時間。服務(wù)器將在這個超時時間過后關(guān)閉鏈接。我們將它設(shè)置低些可以讓ngnix持續(xù)工作的時間更長。

client_header_timeout 和client_body_timeout 設(shè)置請求頭和請求體(各自)的超時時間。我們也可以把這個設(shè)置低些。

reset_timeout_connection 告訴nginx關(guān)閉不響應(yīng)的客戶端連接。這將會釋放那個客戶端所占有的內(nèi)存空間。

send_timeout 指定客戶端的響應(yīng)超時時間。這個設(shè)置不會用于整個轉(zhuǎn)發(fā)器，而是在兩次客戶端讀取操作之間。如果在這段時間內(nèi)，客戶端沒有讀取任何數(shù)據(jù)，nginx就會關(guān)閉連接。

limit_conn_zone $binary_remote_addr zone=addr:5m; 
limit_conn addr 100; 

limit_conn_zone 設(shè)置用于保存各種key（比如當前連接數(shù)）的共享內(nèi)存的參數(shù)。5m就是5兆字節(jié)，這個值應(yīng)該被設(shè)置的足夠大以存儲（32K*5）32byte狀態(tài)或者（16K*5）64byte狀態(tài)。

limit_conn 為給定的key設(shè)置最大連接數(shù)。這里key是addr，我們設(shè)置的值是100，也就是說我們允許每一個IP地址最多同時打開有100個連接。

include /etc/nginx/mime.types; 
default_type text/html; 
charset UTF-8; 

include 只是一個在當前文件中包含另一個文件內(nèi)容的指令。這里我們使用它來加載稍后會用到的一系列的MIME類型。

default_type 設(shè)置文件使用的默認的MIME-type。

charset 設(shè)置我們的頭文件中的默認的字符集

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ù)。這將會減少我們發(fā)送的數(shù)據(jù)量。

gzip_disable 為指定的客戶端禁用gzip功能。我們設(shè)置成IE6或者更低版本以使我們的方案能夠廣泛兼容。

gzip_static 告訴nginx在壓縮資源之前，先查找是否有預(yù)先gzip處理過的資源。這要求你預(yù)先壓縮你的文件（在這個例子中被注釋掉了），從而允許你使用最高壓縮比，這樣nginx就不用再壓縮這些文件了（想要更詳盡的gzip_static的信息，請點擊這里）。

gzip_proxied 允許或者禁止壓縮基于請求和響應(yīng)的響應(yīng)流。我們設(shè)置為any，意味著將會壓縮所有的請求。

gzip_min_length 設(shè)置對數(shù)據(jù)啟用壓縮的最少字節(jié)數(shù)。如果一個請求小于1000字節(jié)，我們最好不要壓縮它，因為壓縮這些小的數(shù)據(jù)會降低處理此請求的所有進程的速度。

gzip_comp_level 設(shè)置數(shù)據(jù)的壓縮等級。這個等級可以是1-9之間的任意數(shù)值，9是最慢但是壓縮比最大的。我們設(shè)置為4，這是一個比較折中的設(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è)置一個相對高的最大時間，這樣我們可以在它們不活動超過20秒后清除掉。

open_file_cache_valid 在open_file_cache中指定檢測正確信息的間隔時間。

open_file_cache_min_uses 定義了open_file_cache中指令參數(shù)不活動時間期間里最小的文件數(shù)。

open_file_cache_errors 指定了當搜索一個文件時是否緩存錯誤信息，也包括再次給配置中添加文件。我們也包括了服務(wù)器模塊，這些是在不同文件中定義的。如果你的服務(wù)器模塊不在這些位置，你就得修改這一行來指定正確的位置。

一個完整的配置

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/*; 
} 

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

sudo service nginx restart 

php高并發(fā)大流量站點nginx優(yōu)化

http://www.cnblogs.com/dawnlee/p/5142724.html

我們的站點目前能應(yīng)對千萬級PV以及百萬級的并發(fā)，對php+nginx的優(yōu)化有一點點心得，寫下來做一些記錄。

1.TCP sockets 與Unix sockets

　Unix sockets比TCP sockets提供更好一些的性能（因為I/O數(shù)據(jù)讀寫少，上下文切換少）。

upstream backend 
{ 
  server unix:/var/run/fastcgi.sock; 
  # server 127.0.0.1:8080; 
}

2.禁用或者優(yōu)化access_log

 大流量訪問時，較大的訪問會導致訪問日志對磁盤的讀寫非常大。如果不需要日志的話，可以禁用掉。

access_log off; 
log_not_found off; 

或者打開緩沖

access_log /var/log/nginx/access.log main buffer=32k;

3.打開Gzip

gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
gzip_vary on;
gzip_proxied expired no-cache no-store private auth;
gzip_disable "MSIE [1-6]\.";

4.優(yōu)化輸出緩存

fastcgi_buffers 256 16k; 
fastcgi_buffer_size 128k; 
fastcgi_connect_timeout 3s; 
fastcgi_send_timeout 120s; 
fastcgi_read_timeout 120s; 
fastcgi_busy_buffers_size 256k; 
fastcgi_temp_file_write_size 256k; 

5.優(yōu)化worker processes

 nginx是多進程的而不是多線程的，對于進程相關(guān)的配置我們需要如下優(yōu)化。

 首先看一下服務(wù)器的處理器數(shù)。

cat /proc/cpuinfo | grep processor

 然后設(shè)置worker_processes，進程數(shù)為得到的處理器數(shù)。 worker_connections 是每一個進程可以打開的最大連接數(shù)，可以調(diào)大一些。下面給一個參考。

# We have 16 cores 
worker_processes 16; 

# connections per worker 
events 
{ 
  worker_connections 4096; 
  multi_accept on; 
}

 記住multi_accept 必須打開。

nginx大流量負載調(diào)優(yōu)

lnmp已經(jīng)成為比較流行的網(wǎng)站服務(wù)器端技術(shù)配備。越來越多的人開始不滿足于能使用nginx，更多人開始關(guān)注如何能優(yōu)化nginx的處理能力。

使用nginx的目的就是為了提高并發(fā)處理能力，但是看到有部分人本機部署lanmp，在同一臺機器上使用nginx方向代理apache，就有種脫褲子放屁的感覺。

在window下運行nginx，還要跑出好的效果，同樣是個偽命題，windows下的select模型注定nginx效率不會太高。

最近看了篇英文文章，結(jié)合自己理解，寫給大家看看吧。

優(yōu)化nginx包括兩方面：

1.是自己重寫nginx代碼(比如tengine)、本身nginx的代碼已經(jīng)足夠優(yōu)秀，如果不是每秒幾千的請求，就忽略這個部分吧。

2.另一個就是和優(yōu)化nginx的配置，這是中小型網(wǎng)站可以重點優(yōu)化的部分。

nginx的配置文件是一種聲明式定義，控制nginx的每一個細節(jié)。

所謂負載調(diào)優(yōu)，就是提高單臺機器處理效率，降低單臺機器的負載。

為了提高單臺機器的處理效率，cpu的處理速度是足夠快的，我們能解決的就是降低磁盤I/O、網(wǎng)絡(luò)I/O，減少內(nèi)存使用。

降低單臺機器的負載我們能做的就是負載均衡，把流量打到多臺機器處理。

nginx推薦優(yōu)化內(nèi)容：

1.open files數(shù)量優(yōu)化
ulimit -a查看系統(tǒng)參數(shù)
其中
open files (-n) 1024
表示系統(tǒng)同時最多能打開的文件數(shù)，linux下的所有設(shè)備都可以認為是文件，包括網(wǎng)絡(luò)連接，如果同時超過1024個連接，那么nginx的日志就會報“24: Too many open files”

多以優(yōu)化的第一步就是設(shè)置open files為ulimit

修改/etc/profile,增加
ulimit -n 65535

2.Worker Processes數(shù)量優(yōu)化
通常來說設(shè)置一個cpu核心對應(yīng)一個worker processer，最多不超過4個，提高worker process的值是為了提高計算能力，但一般在越到cpu瓶頸前，你會遇到別的瓶頸(如網(wǎng)絡(luò)問題)。

只有當你要處理大量靜態(tài)文件的磁盤I/O時，worker進程是單線程的，所以這個讀取文件的阻塞IO會降低CPU的處理速度，這是可以增加worker進程數(shù)量，其它情況是不需要的。

3.worker進程連接數(shù)優(yōu)化(Worker Connections)
默認情況下這個值是worker_connections 1024，也就是說考慮到keep-alive超時65秒，每個瀏覽器平均消耗兩個鏈接(chrome會同時打開多個連接來提到加載速度)。

那么默認情況下nginx平均每秒能處理1024/65/2=8，那么8*86440=64w，差不多相當于每天有60萬ip。

多以普通網(wǎng)站默認值就可以了，如果你的流量一直提升，可以考慮增加這個值為2048或者更高。

3. CPU Affinity
用來設(shè)置worker進程使用哪個cpu核心處理請求并且一直使用這個cpu核心。如果你不知道cpu調(diào)度，最好別碰這個，操作系統(tǒng)比你更懂如何調(diào)度。

4. Keep Alive

Keep alive 沒有數(shù)據(jù)傳輸?shù)那闆r下保持客戶端和服務(wù)端的連接，也就是保持空連接一段時間，避免重現(xiàn)建立鏈接的時間消耗。nginx處理空連接的效率非常高，1萬個空連接大約消耗2.5M內(nèi)存。如果流量非常大的網(wǎng)站，減少建立連接的時間開銷是非常客觀的。keep alive的值設(shè)置在10-20s之間比較合理。

5. tcp_nodelay 和 tcp_nopush優(yōu)化
這兩個指令影響nginx的底層網(wǎng)絡(luò)，它們決定操作系統(tǒng)如何處理網(wǎng)絡(luò)層buffer和什么時候把buffer內(nèi)容刷新給終端用戶。如果你不懂，就可以保持這兩個指令默認不變，對nginx性能影響不明顯。

6. access日志優(yōu)化
默認情況下，access日志會記錄所有請求到日志文件，寫操作會增加IO操作，如果不需要統(tǒng)計信息，可以使用百度統(tǒng)計或者cnzz統(tǒng)計，完全可以關(guān)閉日志，來減少磁盤寫，或者寫入內(nèi)存文件，提高IO效率。

7. Error日志優(yōu)化
錯誤日志會記錄運行中的錯誤，如果設(shè)置的太低，會記錄的信息太多，會產(chǎn)生大量IO，推薦設(shè)置為warn，這樣可以記錄大部分信息，而不會有太多IO

8. Open File Cache
nginx會讀文件系統(tǒng)的許多文件，如果這些文件的描述符能夠緩存起來，那么會提高處理效率。詳見http://wiki.nginx.org/HttpCoreModule#open_file_cache

9. Buffers size優(yōu)化
buffer的大小是你需要調(diào)優(yōu)最重要參數(shù)。如果buffer size太小就會到導致nginx使用臨時文件存儲response，這會引起磁盤讀寫IO，流量越大問題越明顯。

client_body_buffer_size 處理客戶端請求體buffer大小。用來處理POST提交數(shù)據(jù)，上傳文件等。client_body_buffer_size 需要足夠大以容納如果需要上傳POST數(shù)據(jù)。

fastcgi_buffers，proxy_buffers 處理后端（PHP,

Apache）響應(yīng)。如果這個buffer不夠大，同樣會引起磁盤都系IO。需要注意的是它們有一個上限值，這個上限值受 fastcgi_max_temp_file_size 、 proxy_max_temp_file_size控制。

10.磁盤IO
如果能把數(shù)據(jù)全放到內(nèi)存，不使用磁盤就可以完全去掉磁盤IO。 默認情況下操作系統(tǒng)也會緩存頻繁訪問的數(shù)據(jù)以降低IO。所以預(yù)算足夠的情況加，加大內(nèi)存。

11.網(wǎng)絡(luò)IO
假設(shè)我們沒有了磁盤IO，所有數(shù)據(jù)都在內(nèi)存，那么我們的讀IO大概有3-6gbps。這種情況下，如果你網(wǎng)絡(luò)差，一樣會很慢。所以盡可能提高網(wǎng)絡(luò)帶寬，壓縮傳輸數(shù)據(jù)。

網(wǎng)絡(luò)帶寬買你能買的起的最大帶寬，nginx的gzip模塊可以用來壓縮傳輸數(shù)據(jù)，通常gzip_comp_level 設(shè)為 4-5，再高就是浪費cpu了。同時也可以采用css，js壓縮技術(shù)，當然這些技術(shù)就與nginx優(yōu)化無關(guān)了。。

絕招
如果你還想提高nginx處理能力，只能祭出大殺器了。別優(yōu)化了，加機器吧。一點點優(yōu)化是沒有用的，不如擴展機器來的快些。

ps
說道系統(tǒng)的擴展性通常有scale、和extension，區(qū)別是前者是數(shù)量上擴展，后者是功能上擴展。

http://www.cnblogs.com/ldms/p/3525383.html
一般來說nginx配置文件中對優(yōu)化比較有作用的為以下幾項：

為每個進程分配cpu，上例中將8個進程分配到8個cpu，當然可以寫多個，或者將一個進程分配到多個cpu。

這個指令是指當一個nginx進程打開的最多文件描述符數(shù)目，理論值應(yīng)該是最多打開文件數(shù)（ulimit -n）與nginx進程數(shù)相除，但是nginx分配請求并不是那么均勻，所以最好與ulimit -n的值保持一致。

使用epoll的I/O模型，這個不用說了吧。

每個進程允許的最多連接數(shù)，理論上每臺nginx服務(wù)器的最大連接數(shù)為worker_processes*worker_connections。

keepalive超時時間。

客戶端請求頭部的緩沖區(qū)大小，這個可以根據(jù)你的系統(tǒng)分頁大小來設(shè)置，一般一個請求的頭部大小不會超過1k，不過由于一般系統(tǒng)分頁都要大于1k，所以這里設(shè)置為分頁大小。分頁大小可以用命令getconf PAGESIZE取得。

這個將為打開文件指定緩存，默認是沒有啟用的，max指定緩存數(shù)量，建議和打開文件數(shù)一致，inactive是指經(jīng)過多長時間文件沒被請求后刪除緩存。

這個是指多長時間檢查一次緩存的有效信息。

open_file_cache指令中的inactive參數(shù)時間內(nèi)文件的最少使用次數(shù)，如果超過這個數(shù)字，文件描述符一直是在緩存中打開的，如上例，如果有一個文件在inactive時間內(nèi)一次沒被使用，它將被移除。

關(guān)于內(nèi)核參數(shù)的優(yōu)化：
 

timewait的數(shù)量，默認是180000。(Deven:因此如果想把timewait降下了就要把tcp_max_tw_buckets值減小)

允許系統(tǒng)打開的端口范圍。

啟用timewait快速回收。

開啟重用。允許將TIME-WAIT sockets重新用于新的TCP連接。

開啟SYN Cookies，當出現(xiàn)SYN等待隊列溢出時，啟用cookies來處理。

web應(yīng)用中l(wèi)isten函數(shù)的backlog默認會給我們內(nèi)核參數(shù)的net.core.somaxconn限制到128，而nginx定義的NGX_LISTEN_BACKLOG默認為511，所以有必要調(diào)整這個值。

每個網(wǎng)絡(luò)接口接收數(shù)據(jù)包的速率比內(nèi)核處理這些包的速率快時，允許送到隊列的數(shù)據(jù)包的最大數(shù)目。

系統(tǒng)中最多有多少個TCP套接字不被關(guān)聯(lián)到任何一個用戶文件句柄上。如果超過這個數(shù)字，孤兒連接將即刻被復(fù)位并打印出警告信息。這個限制僅僅是為了防止簡單的DoS攻擊，不能過分依靠它或者人為地減小這個值，更應(yīng)該增加這個值(如果增加了內(nèi)存之后)。

記錄的那些尚未收到客戶端確認信息的連接請求的最大值。對于有128M內(nèi)存的系統(tǒng)而言，缺省值是1024，小內(nèi)存的系統(tǒng)則是128。

時間戳可以避免序列號的卷繞。一個1Gbps的鏈路肯定會遇到以前用過的序列號。時間戳能夠讓內(nèi)核接受這種“異常”的數(shù)據(jù)包。這里需要將其關(guān)掉。

為了打開對端的連接，內(nèi)核需要發(fā)送一個SYN并附帶一個回應(yīng)前面一個SYN的ACK。也就是所謂三次握手中的第二次握手。這個設(shè)置決定了內(nèi)核放棄連接之前發(fā)送SYN+ACK包的數(shù)量。

在內(nèi)核放棄建立連接之前發(fā)送SYN包的數(shù)量。

如 果套接字由本端要求關(guān)閉，這個參數(shù) 決定了它保持在FIN-WAIT-2狀態(tài)的時間。對端可以出錯并永遠不關(guān)閉連接，甚至意外當機。缺省值是60秒。2.2 內(nèi)核的通常值是180秒，你可以按這個設(shè)置，但要記住的是，即使你的機器是一個輕載的WEB服務(wù)器，也有因為大量的死套接字而內(nèi)存溢出的風險，F(xiàn)IN- WAIT-2的危險性比FIN-WAIT-1要小，因為它最多只能吃掉1.5K內(nèi)存，但是它們的生存期長些。

當keepalive起用的時候，TCP發(fā)送keepalive消息的頻度。缺省是2小時。

下面貼一個完整的內(nèi)核優(yōu)化設(shè)置：
 

下面是一個簡單的nginx配置文件：

關(guān)于FastCGI的幾個指令：
 

這個指令為FastCGI緩存指定一個路徑，目錄結(jié)構(gòu)等級，關(guān)鍵字區(qū)域存儲時間和非活動刪除時間。

指定連接到后端FastCGI的超時時間。

向FastCGI傳送請求的超時時間，這個值是指已經(jīng)完成兩次握手后向FastCGI傳送請求的超時時間。

接收FastCGI應(yīng)答的超時時間，這個值是指已經(jīng)完成兩次握手后接收FastCGI應(yīng)答的超時時間。

指定讀取FastCGI應(yīng)答第一部分 需要用多大的緩沖區(qū)，這里可以設(shè)置為fastcgi_buffers指令指定的緩沖區(qū)大小，上面的指令指定它將使用1個 16k的緩沖區(qū)去讀取應(yīng)答的第一部分，即應(yīng)答頭，其實這個應(yīng)答頭一般情況下都很小（不會超過1k），但是你如果在fastcgi_buffers指令中指 定了緩沖區(qū)的大小，那么它也會分配一個fastcgi_buffers指定的緩沖區(qū)大小去緩存。

指定本地需要用多少和多大的緩沖區(qū)來 緩沖FastCGI的應(yīng)答，如上所示，如果一個php腳本所產(chǎn)生的頁面大小為256k，則會為其分配16個16k的緩沖區(qū)來緩存，如果大于256k，增大 于256k的部分會緩存到fastcgi_temp指定的路徑中， 當然這對服務(wù)器負載來說是不明智的方案，因為內(nèi)存中處理數(shù)據(jù)速度要快于硬盤，通常這個值 的設(shè)置應(yīng)該選擇一個你的站點中的php腳本所產(chǎn)生的頁面大小的中間值，比如你的站點大部分腳本所產(chǎn)生的頁面大小為 256k就可以把這個值設(shè)置為16 16k，或者4 64k 或者64 4k，但很顯然，后兩種并不是好的設(shè)置方法，因為如果產(chǎn)生的頁面只有32k，如果用4 64k它會分配1個64k的緩沖區(qū)去緩存，而如果使用64 4k它會分配8個4k的緩沖區(qū)去緩存，而如果使用16 16k則它會分配2個16k去緩存頁面，這樣看起來似乎更加合理。

這個指令我也不知道是做什么用，只知道默認值是fastcgi_buffers的兩倍。

在寫入fastcgi_temp_path時將用多大的數(shù)據(jù)塊，默認值是fastcgi_buffers的兩倍。

開啟FastCGI緩存并且為其制定一個名稱。個人感覺開啟緩存非常有用，可以有效降低CPU負載，并且防止502錯誤。但是這個緩存會引起很多問題，因為它緩存的是動態(tài)頁面。具體使用還需根據(jù)自己的需求。

為指定的應(yīng)答代碼指定緩存時間，如上例中將200，302應(yīng)答緩存一小時，301應(yīng)答緩存1天，其他為1分鐘。

緩存在fastcgi_cache_path指令inactive參數(shù)值時間內(nèi)的最少使用次數(shù)，如上例，如果在5分鐘內(nèi)某文件1次也沒有被使用，那么這個文件將被移除。

不知道這個參數(shù)的作用，猜想應(yīng)該是讓nginx知道哪些類型的緩存是沒用的。
以上為nginx中FastCGI相關(guān)參數(shù)，另外，F(xiàn)astCGI自身也有一些配置需要進行優(yōu)化，如果你使用php-fpm來管理FastCGI，可以修改配置文件中的以下值：

同時處理的并發(fā)請求數(shù)，即它將開啟最多60個子線程來處理并發(fā)連接。

最多打開文件數(shù)。

每個進程在重置之前能夠執(zhí)行的最多請求數(shù)。