譯者：AlfredCheung

在搭建高吞吐量web應(yīng)用這個(gè)議題上，NginX和Node.js可謂是天生一對(duì)。他們都是基于事件驅(qū)動(dòng)模型而設(shè)計(jì)，可以輕易突破Apache等傳統(tǒng)web服務(wù)器的C10K瓶頸。預(yù)設(shè)的配置已經(jīng)可以獲得很高的并發(fā)，不過(guò)，要是大家想在廉價(jià)硬件上做到每秒數(shù)千以上的請(qǐng)求，還是有一些工作要做的。

這篇文章假定讀者們使用NginX的HttpProxyModule來(lái)為上游的node.js服務(wù)器充當(dāng)反向代理。我們將介紹Ubuntu 10.04以上系統(tǒng)sysctl的調(diào)優(yōu)，以及node.js應(yīng)用與NginX的調(diào)優(yōu)。當(dāng)然，如果大家用的是Debian系統(tǒng)，也能達(dá)到同樣的目標(biāo)，只不過(guò)調(diào)優(yōu)的方法有所不同而已。

網(wǎng)絡(luò)調(diào)優(yōu)

如果不先對(duì)Nginx和Node.js的底層傳輸機(jī)制有所了解，并進(jìn)行針對(duì)性?xún)?yōu)化，可能對(duì)兩者再細(xì)致的調(diào)優(yōu)也會(huì)徒勞無(wú)功。一般情況下，Nginx通過(guò)TCP socket來(lái)連接客戶(hù)端與上游應(yīng)用。

我們的系統(tǒng)對(duì)TCP有許多門(mén)限值與限制，通過(guò)內(nèi)核參數(shù)來(lái)設(shè)定。這些參數(shù)的默認(rèn)值往往是為一般的用途而定的，并不能滿(mǎn)足web服務(wù)器所需的高流量、短生命的要求。

這里列出了調(diào)優(yōu)TCP可供候選的一些參數(shù)。為使它們生效，可以將它們放在/etc/sysctl.conf文件里，或者放入一個(gè)新配置文件，比如/etc/sysctl.d/99-tuning.conf，然后運(yùn)行sysctl -p，讓內(nèi)核裝載它們。我們是用sysctl-cookbook來(lái)干這個(gè)體力活。

需要注意的是，這里列出來(lái)的值是可以安全使用的，但還是建議大家研究一下每個(gè)參數(shù)的含義，以便根據(jù)自己的負(fù)荷、硬件和使用情況選擇一個(gè)更加合適的值。

• net.ipv4.ip_local_port_range='1024 65000'
• net.ipv4.tcp_tw_reuse='1'
• net.ipv4.tcp_fin_timeout='15'
• net.core.netdev_max_backlog='4096'
• net.core.rmem_max='16777216'
• net.core.somaxconn='4096'
• net.core.wmem_max='16777216'
• net.ipv4.tcp_max_syn_backlog='20480'
• net.ipv4.tcp_max_tw_buckets='400000'
• net.ipv4.tcp_no_metrics_save='1'
• net.ipv4.tcp_rmem='4096 87380 16777216'
• net.ipv4.tcp_syn_retries='2'
• net.ipv4.tcp_synack_retries='2'
• net.ipv4.tcp_wmem='4096 65536 16777216'
• vm.min_free_kbytes='65536'

重點(diǎn)說(shuō)明其中幾個(gè)重要的。

net.ipv4.ip_local_port_range

為了替上游的應(yīng)用服務(wù)下游的客戶(hù)端，NginX必須打開(kāi)兩條TCP連接，一條連接客戶(hù)端，一條連接應(yīng)用。在服務(wù)器收到很多連接時(shí)，系統(tǒng)的可用端口將很快被耗盡。通過(guò)修改net.ipv4.ip_local_port_range參數(shù)，可以將可用端口的范圍改大。如果在/var/log/syslog中發(fā)現(xiàn)有這樣的錯(cuò)誤: “possible SYN flooding on port 80. Sending cookies”，即表明系統(tǒng)找不到可用端口。增大net.ipv4.ip_local_port_range參數(shù)可以減少這個(gè)錯(cuò)誤。

net.ipv4.tcp_tw_reuse

當(dāng)服務(wù)器需要在大量TCP連接之間切換時(shí)，會(huì)產(chǎn)生大量處于TIME_WAIT狀態(tài)的連接。TIME_WAIT意味著連接本身是關(guān)閉的，但資源還沒(méi)有釋放。將net_ipv4_tcp_tw_reuse設(shè)置為1是讓內(nèi)核在安全時(shí)盡量回收連接，這比重新建立新連接要便宜得多。

net.ipv4.tcp_fin_timeout

這是處于TIME_WAIT狀態(tài)的連接在回收前必須等待的最小時(shí)間。改小它可以加快回收。

如何檢查連接狀態(tài)

使用netstat:

• netstat -tan | awk '{print $6}' | sort | uniq -c

或使用ss:

• ss -s

• NginX

隨著web服務(wù)器的負(fù)載逐漸升高，我們就會(huì)開(kāi)始遭遇NginX的某些奇怪限制。連接被丟棄，內(nèi)核不停報(bào)SYN flood。而這時(shí)，平均負(fù)荷和CPU使用率都很小，服務(wù)器明明是可以處理更多連接的狀態(tài)，真令人沮喪。

經(jīng)過(guò)調(diào)查，發(fā)現(xiàn)有非常多處于TIME_WAIT狀態(tài)的連接。這是其中一個(gè)服務(wù)器的輸出:

• ss -s
• Total: 388 (kernel 541)
• TCP:   47461 (estab 311, closed 47135, orphaned 4, synrecv 0, timewait 47135/0), ports 33938
• Transport Total     IP        IPv6
• *          541       -         -        
• RAW        0         0         0        
• UDP        13        10        3        
• TCP        326       325       1        
• INET       339       335       4        
• FRAG       0         0         0

有47135個(gè)TIME_WAIT連接！而且，從ss可以看出，它們都是已經(jīng)關(guān)閉的連接。這說(shuō)明，服務(wù)器已經(jīng)消耗了絕大部分可用端口，同時(shí)也暗示我們，服務(wù)器是為每個(gè)連接都分配了新端口。調(diào)優(yōu)網(wǎng)絡(luò)對(duì)這個(gè)問(wèn)題有一點(diǎn)幫助，但是端口仍然不夠用。

經(jīng)過(guò)繼續(xù)研究，我找到了一個(gè)關(guān)于上行連接keepalive指令的文檔，它寫(xiě)道:

設(shè)置通往上游服務(wù)器的最大空閑�；钸B接數(shù)，這些連接會(huì)被保留在工作進(jìn)程的緩存中。

有趣。理論上，這個(gè)設(shè)置是通過(guò)在緩存的連接上傳遞請(qǐng)求來(lái)盡可能減少連接的浪費(fèi)。文檔中還提到，我們應(yīng)該把proxy_http_version設(shè)為"1.1"，并清除"Connection"頭部。經(jīng)過(guò)進(jìn)一步的研究，我發(fā)現(xiàn)這是一種很好的想法，因?yàn)镠TTP/1.1相比HTTP1.0，大大優(yōu)化了TCP連接的使用率，而Nginx默認(rèn)用的是HTTP/1.0。

標(biāo)簽： 網(wǎng)站負(fù)載 負(fù)載網(wǎng)絡(luò)優(yōu)化 Node.js 

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。