Windows環境下的Nginx高并發實現

文/岳晉 溫宇 黃旻亮

1 引言

Nginx是高性能的Http和反向代理服務器，在Linux環境下，其可以采用epoll作為網絡I/O模型。在高并發連接的情況下，其是Apache服務器不錯的替代品。Nginx具有高并發連接、內存占用低、成本低等特點。

Nginx運行時，會存在一個主進程和多個工作進程。工作進程的數目可以在配置文件中進行指定，通常設置為CPU的核數。主進程用于管理工作進程的運行，并處置工作進程的異常情況。借助于主進程和工作進程的模式，Nginx可以實現平滑升級、配置即時生效等功能。而工作進程的任務相對單一，主要用于處理業務請求，它們彼此獨立，互不影響。此外，借助于異步非阻塞的工作機制，Nginx可以處理上萬的并發請求。

反向代理是Nginx的主要應用場景之一。反向代理是相對于正向代理來說，一般情況下，內網的客戶機通過代理服務器訪問公網上服務的這種模式是正向代理。與此相反，當代理服務器的作用是將后臺服務器隱藏起來，并根據客戶機的請求，分發給后臺服務器的這種方式是反向代理。Nginx反向代理的原理如圖1所示。

圖1中，Nginx代理服務器接收到來自客戶端的請求，根據自己的配置，決定將該請求轉發給哪個業務服務器。當業務服務器處理完該請求后，將響應結果交給Nginx代理服務器，Nginx代理服務器再將響應內容返回給客戶機。

反向代理可以保護后端服務器，此外，還可以用作負載均衡，來平衡后端服務器的性能壓力。Nginx通過proxy_pass命令和upstream模塊，就可以實現反向代理。如果后臺服務和Nginx在同一機器上，但運行在不同的端口上，Nginx可以將請求轉發到后臺服務運行的端口上。通常情況下，后臺服務和Nginx不在一臺服務器上，這時候Nginx可以將請求發送給upstream模塊，再通過upstream模塊轉發給后臺服務器。而且在upstream模塊中，也可以進行負載均衡相關的配置。

Nginx的另一主要應用場景是負載均衡。負載均衡是在各服務器之間均衡業務壓力，Nginx的負載均衡策略包括輪詢、指定權重、fair、ip_hash和url_hash等。

2 Nginx性能調優相關配置

2.1 stub_status監控模塊

Windows版本的Nginx默認開啟了stub_status模塊來查看Nginx的一些狀態信息。此外，還需要在nginx.conf（Nginx的主要配置文件）中增加如下配置。

location/nginx_status{

stub_status;

allow 127.0.0.1;

}

這樣，通過訪問對應的url就可以打開監控頁面。監控頁面上的監控數據如下所示：

Active connections: 6

Server accepts handled requests:

12053 12053 17528

Reading: 0 Writing: 2 Waiting: 4

其中，active connection 6; 對上游服務發起的連接數，需要注意的是，如果reading或者writing的值很高，說明正在處理的數據量較大，可能是因為后臺服務處理慢，這個時候需要對后臺進行優化。

在使用長連接的情況下，waiting的值代表有多少個連接在等待新的請求。waiting表明Nginx已經將請求處理完畢，并且把數據返回給了客戶端，該連接已經閑置，正在等待下一次請求。因此，這個值比較高說明請求處理得很快。一般應是writing和reading越小越好，而waiting越高越高。

2.2 優化性能相關的配置參數

為獲取較高的并發性能，需要對Nginx的主要配置參數進行調優。主要的配置參數及調優如下。

2.2.1 multi_accept on

如果multi_accept被禁止了，Nginx的一個工作進程只能同時接受一個新的連接，否則，一個工作進程可以接受所有的新連接。這個時候在監控頁面上看到的active connections通常是很低的，因此，需要開啟該參數，該配置對于提高Nginx的并發至為關鍵。

2.2.2 worker_processes

worker_processes后面的數值一般設置為CPU的核數，代表Nginx開啟的工作進程的數目。例如，worker_processes 8代表開啟8個工作進程。

2.2.3 worker_connections

配置一個工作進程能夠處理的并發連接請求的數目。考慮高并發場景，將其設置為一個比較大的值。例如，worker_connections 40960，在Windows服務器下，該參數一般不超過65535。

2.2.4 worker_rlimit_nofile

配置一個工作進程能夠打開的文件句柄數上限。在高并發場景下，也需要設置為比較大的值，例如，worker_limit_nofile 40960。

2.2.5 sendfile

將該參數打開可以提高發送文件的效率，采用如下配置打開此參數，sendfile on。

圖1：Nginx反向代理處理流程

2.2.6 tcp_nopush

打開tcp_nopush后，將會在發送響應時，把整個響應頭放在一個tcp包中發送，能夠達到優化吞吐的效果，建議打開。

2.2.7 tcp_nodelay

該參數打開后，會關閉Nagle算法，保證高頻發送小數據報文的實時性，建議打開。

2.2.8 access_log

設置為on時，會保存Nginx代理的訪問請求。將這個設置關閉，會降低磁盤IO而提升速度。在生產環境，當確保Nginx不會出現問題后，可以將該參數設置為off。

2.2.9 gzip

該參數設置是否壓縮發送數據，建議打開。gzip_comp_level 數據壓縮的等級，可以是1～9的任意一個值，9表示最慢但最高比例的壓縮。gzip_types 設置gzip的類型。

2.2.10 open_file_cache

open_file_cache 緩存最大數目及超時時間。open_file_cache_vaild 用于設置檢測緩存源文件是否超時的時間間隔。open_file_cache_min_uses設置緩存文件最小訪問次數。open_file_cache_errors設置是否保存緩存文件的錯誤信息。

2.2.11 proxy_buffering

proxy_buffering該參數用于設置是否開啟響應內容的緩沖。如果關閉該參數，那么proxy_buffers和proxy_busy_buffers_size的配置將無效。但是，proxy_buffer_size是否生效與proxy_buffering參數的設置無關。如果開啟proxy_buffering下，響應內容會被Nginx先存入緩沖區中，之后再傳遞給客戶端。緩存區的臨時文件由proxy_max_temp_file_size

和proxy_temp_file_write_size決定。當內存中的無非存儲響應內容時，會在磁盤中存儲部分響應內容。

當關閉proxy_buffering后，Nginx不再緩存后端返回的響應內容，而是直接傳遞給客戶端。proxy_buffers配置接收一次響應的buffer個數和每個buffer的大小。proxy_busy_buffers_size 如果系統很忙的時候，可以申請更大的proxy_buffers，官方推薦乘2。proxy_temp_path path配置臨時文件目錄，proxy_temp_file_write_size緩存臨時文件的大小，proxy_max_temp_file_size 配置所有臨時文件的總大小。配置實例如下，

proxy_buffering on;

proxy_buffer_size 64k; proxy_buffers 4 32k;

proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k; proxy_max_temp_file_size 1024m;

2.2.12 keepalive

為提高并發能力，需要對長連接進行優化。主要包括keepalive_timeout和keepalive_requests，keepalive_timeout表 示keepAlive的超時時間，也就是在超時時間內，如果客戶端沒有后續請求過來，Nginx就會斷掉這個Tcp連接。如果設置為0，表示禁用keepAlive。keepalive_timeout表示一個長連接，Nginx處理的請求上限，keepalive_timeout可以根據實際情況設置為一個較大的值。

3 Windows服務器下實現Nginx高并發的關鍵操作

3.1 采用Windows專用版本的Nginx

圖2：10秒思考時間下，LoadRunner模擬5000用戶并發壓測某業務結果

在實際壓測并發能力的過程中，發現當并發超過1023后，Nginx會拒絕連接，并打印錯誤日志“maximum number of descriptors supported by select() is 1024 while waiting for request”。主要原因是在Windows環境下，盡管修改了worker_connections，但無法生效。為解決此問題，可以在網站http://nginx.org/en/download.html上獲取修改了最大文件描述符限制的Nginx版本，該版本的Nginx盡管無非使用epoll機制，但該專用版本已經提供了盡可能多的功能，并針對Windows環境做了優化，其可以支持每秒幾千到幾萬的并發請求。并且，其商業版本也可以提供付費的技術支持服務。因此，在Windows環境下，為提高并發能力，需使用Windows專用版本的Nginx。

3.2 解決高并發情形下的Windows服務器TCP連接端口耗盡問題

在每秒創建的新連接比較多且持續創建的情況下，運行一段時間后，Nginx會拒絕連接，并打印錯誤日志。“An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue is full while connecting to upstream”，該 報錯的原因主要有兩種情況，第一種就是TCP連接端口耗盡，第二種是超過了socket隊列能夠處理的最大連接。其中，第二種情況可以通過配置backlog解決，如，listen 8080 backlog=40960。

第一種TCP連接端口耗盡的情況，在Windows環境下比較難處理。Windows server 2008在默認情況下，給TCP連接提供的端口只有16384個，可以通過在命令行輸入“netsh int ipv4 show dynamicport tcp”查看。對于每個新的客戶端連接，Nginx除了和客戶端建立連接外，和后端服務器也建立了一個臨時的TCP連接。這個臨時的TCP連接就是端口耗盡的根源

根據TCP/IP原理，TCP連接在進行“四次揮手”斷開連接時，首先斷開連接的一方會進入“timewait”狀態，在timewait狀態內，由（源ip，源端口，目的ip，目的端口）組成的四元組是不允許被重用的。

針對TCP連接端口耗盡問題，在Windows服務器上，可以通過多種方式改善該問題，第一種是通過“netsh int ipv4 set dynamicport tcp start=5000 num=60000”，增加TCP連接的可用端口數。第二種是通過在注冊表的HKEY_LOCAL_MACHINESYSTEMCurrentControlSetserviceTcpipParameters增加TcpTimedWaitDelay的REG_DWORD參數，并將其設置為30。這種方法是將TCP連接timewait的時間（范圍為30秒到240秒）降低為30秒，修改完成后，重啟機器生效。

此外，還可以對客戶端請求進行限速，對單個ip短時間內多個TCP連接排隊處理。

另外，可以在upstream中配置keepalive xxx，其中xxx可以設置為1000。原因是nginx和后端服務器之間的連接為短連接，且無連接復用，這樣在高并發場景下，會造成端口的耗盡。通過以上配置，并配合proxy_http_version 1.1和proxy_set_header Connection ""，就可以較好地解決端口耗盡問題。

通過對配置的調優，在Windows環境下，也達到了上萬的活躍連接數，如下監控數據所示。

Active connections: 10003

Server accepts handled requests:

559064 559064 7196725

Reading: 0 Writing: 6678 Waiting: 3324

使用Nginx反向代理某一Web服務，并使用LoadRunner進行壓力測試，模擬5000用戶并發訪問該服務，其測試結果如圖2所示。

圖2中，第一行的圖代表用戶的并發數，其是從0逐漸增加到5000，然后再下降到0。第二行的圖是HPS（hits per second）的結果圖，圖中瞬時HPS可以達到2500以上，說明該方案在Windows環境下可以提供較高的并發能力。

4 結論

Windows環境下，Nginx的并發性能會存在一定的瓶頸。本文通過對Nginx的主要配置進行調優，并采用Windows專用版本的Nginx，較好地解決了高并發情形下TCP連接端口耗盡等性能瓶頸，并實現了Windows生產環境下的Nginx高并發處理。