# 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.)
    # 這里的數值不能超過 CPU 的總核數，因為在單個核上部署超過 1 個 Nginx 服務進程并不起到提高性能的作用。
    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 最大可用文件描述符數量，同時需要配置操作系統的 "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 單個進程可服務的客戶端數量，（最大值客戶端數 = 單進程連接數 * 進程數 ）
    # 最大客戶端數同時也受操作系統 socket 連接數的影響（最大 64K ）
    worker_connections 4000;
 
    # essential for linux, optmized to serve many clients with each thread
    # Linux 關鍵配置，允許單個線程處理多個客戶端請求。
    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.
    # 允許盡可能地處理更多的連接數，如果 worker_connections 配置太低，會產生大量的無效連接請求。
    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（文件描述符/文件句柄）
    # 在我的設備環境中，通過修改以下配置，性能從 560k 請求/秒 提升到 904k 請求/秒。
    # 我建議你對以下配置嘗試不同的組合，而不是直接使用這幾個數據。
    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 存儲設備，或者直接關閉日志。
    # 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 選項，使用內核的 FD 文件傳輸功能，這個比在用戶態用 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 應答首部與數據內容在同一個報文中發出。
    # 這個選項使服務器在 sendfile 時可以提前準備 HTTP 首部，能夠達到優化吞吐的效果。
    tcp_nopush on;
 
    # don't buffer data-sends (disable Nagle algorithm). Good for sending frequent small bursts of data in real time.
    # 不要緩存 data-sends （關閉 Nagle 算法），這個能夠提高高頻發送小數據報文的實時性。
    tcp_nodelay on;
 
    # Timeout for keep-alive connections. Server will close connections after this time.
    # 配置連接 keep-alive 超時時間，服務器將在超時之后關閉相應的連接。
    keepalive_timeout 30;
 
    # Number of requests a client can make over the keep-alive connection. This is set high for testing.
    # 單個客戶端在 keep-alive 連接上可以發送的請求數量，在測試環境中，需要配置個比較大的值。
    keepalive_requests 100000;
 
    # allow the server to close the connection after a client stops responding. Frees up socket-associated memory.
    # 允許服務器在客戶端停止發送應答之后關閉連接，以便釋放連接相應的 socket 內存開銷。
    reset_timedout_connection on;
 
    # send the client a "request timed out" if the body is not loaded by this time. Default 60.
    # 配置客戶端數據請求超時時間，默認是 60 秒。
    client_body_timeout 10;
 
    # If the client stops reading data, free up the stale client connection after this much time. Default 60.
    # 客戶端數據讀超時配置，客戶端停止讀取數據，超時時間后斷開相應連接，默認是 60 秒。
    send_timeout 2;
 
    # Compression. Reduces the amount of data that needs to be transferred over the network
    # 壓縮參數配置，減少在網絡上所傳輸的數據量。
    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].";

內核調優：
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 # 調高系統的 IP 以及端口數據限制，從可以接受更多的連接 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 # 設置協議棧可以緩存的報文數閥值，超過閥值的報文將被內核丟棄 net.ipv4.tcp_max_syn_backlog = 3240000   # increase socket listen backlog # 調高 socket 偵聽數閥值 net.core.somaxconn = 3240000 net.ipv4.tcp_max_tw_buckets = 1440000   # Increase TCP buffer sizes # 調大 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配置性能優化

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

基本的 (優化過的)配置

我們將修改的唯一文件是nginx.conf，其中包含Nginx不同模塊的所有設置。你應該能夠在服務器的/etc/nginx目錄中找到nginx.conf。首先，我們將談論一些全局設置，然后按文件中的模塊挨個來，談一下哪些設置能夠讓你在大量客戶端訪問時擁有良好的性能，為什么它們會提高性能。本文的結尾有一個完整的配置文件。

高層的配置

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

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

user和pid應該按默認設置 - 我們不會更改這些內容，因為更改與否沒有什么不同。

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

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

Events模塊

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

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

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

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

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

use 設置用于復用客戶端線程的輪詢方法。如果你使用Linux 2.6+，你應該使用epoll。如果你使用*BSD，你應該使用kqueue。

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

HTTP 模塊

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

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

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

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

tcp_nopush 告訴nginx在一個數據包里發送所有頭文件，而不一個接一個的發送。

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

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

access_log 設置nginx是否將存儲訪問日志。關閉這個選項可以讓讀取磁盤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鏈接超時時間。服務器將在這個超時時間過后關閉鏈接。我們將它設置低些可以讓ngnix持續工作的時間更長。

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

reset_timeout_connection 告訴nginx關閉不響應的客戶端連接。這將會釋放那個客戶端所占有的內存空間。

send_timeout 指定客戶端的響應超時時間。這個設置不會用于整個轉發器，而是在兩次客戶端讀取操作之間。如果在這段時間內，客戶端沒有讀取任何數據，nginx就會關閉連接。

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

limit_conn_zone 設置用于保存各種key（比如當前連接數）的共享內存的參數。5m就是5兆字節，這個值應該被設置的足夠大以存儲（32K*5）32byte狀態或者（16K*5）64byte狀態。

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

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

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

default_type 設置文件使用的默認的MIME-type。

charset 設置我們的頭文件中的默認的字符集

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壓縮的形式發送數據。這將會減少我們發送的數據量。

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

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

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

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

gzip_comp_level 設置數據的壓縮等級。這個等級可以是1-9之間的任意數值，9是最慢但是壓縮比最大的。我們設置為4，這是一個比較折中的設置。

gzip_type 設置需要壓縮的數據格式。上面例子中已經有一些了，你也可以再添加更多的格式。

# 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 打開緩存的同時也指定了緩存最大數目，以及緩存的時間。我們可以設置一個相對高的最大時間，這樣我們可以在它們不活動超過20秒后清除掉。

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

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

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

一個完整的配置

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使設置生效。

sudo service nginx restart 

php高并發大流量站點nginx優化

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

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

1.TCP sockets 與Unix sockets

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

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

2.禁用或者優化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.優化輸出緩存

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.優化worker processes

 nginx是多進程的而不是多線程的，對于進程相關的配置我們需要如下優化。

 首先看一下服務器的處理器數。

cat /proc/cpuinfo | grep processor

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

# We have 16 cores 
worker_processes 16; 

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

 記住multi_accept 必須打開。

nginx大流量負載調優

lnmp已經成為比較流行的網站服務器端技術配備。越來越多的人開始不滿足于能使用nginx，更多人開始關注如何能優化nginx的處理能力。

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

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

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

優化nginx包括兩方面：

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

2.另一個就是和優化nginx的配置，這是中小型網站可以重點優化的部分。

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

所謂負載調優，就是提高單臺機器處理效率，降低單臺機器的負載。

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

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

nginx推薦優化內容：

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

多以優化的第一步就是設置open files為ulimit

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

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

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

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

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

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

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

4. Keep Alive

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

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

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

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

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

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

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

fastcgi_buffers，proxy_buffers 處理后端（PHP,

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

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

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

網絡帶寬買你能買的起的最大帶寬，nginx的gzip模塊可以用來壓縮傳輸數據，通常gzip_comp_level 設為 4-5，再高就是浪費cpu了。同時也可以采用css，js壓縮技術，當然這些技術就與nginx優化無關了。。

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

ps
說道系統的擴展性通常有scale、和extension，區別是前者是數量上擴展，后者是功能上擴展。

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

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

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

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

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

keepalive超時時間。

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

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

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

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

關于內核參數的優化：
 

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

允許系統打開的端口范圍。

啟用timewait快速回收。

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

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

web應用中listen函數的backlog默認會給我們內核參數的net.core.somaxconn限制到128，而nginx定義的NGX_LISTEN_BACKLOG默認為511，所以有必要調整這個值。

每個網絡接口接收數據包的速率比內核處理這些包的速率快時，允許送到隊列的數據包的最大數目。

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

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

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

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

在內核放棄建立連接之前發送SYN包的數量。

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

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

下面貼一個完整的內核優化設置：
 

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

關于FastCGI的幾個指令：
 

這個指令為FastCGI緩存指定一個路徑，目錄結構等級，關鍵字區域存儲時間和非活動刪除時間。

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

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

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

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

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

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

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

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

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

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

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

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

最多打開文件數。

每個進程在重置之前能夠執行的最多請求數。