一、Nginx性能優(yōu)化

? ?到這里文章的篇幅較長了，最后再來聊一下關(guān)于Nginx的性能優(yōu)化，主要就簡單說說收益最高的幾個優(yōu)化項，在這塊就不再展開敘述了，畢竟影響性能都有多方面原因?qū)е碌模热缇W(wǎng)絡(luò)、服務(wù)器硬件、操作系統(tǒng)、后端服務(wù)、程序自身、數(shù)據(jù)庫服務(wù)等，對于性能調(diào)優(yōu)比較感興趣的可以參考之前《JVM性能調(diào)優(yōu)》中的調(diào)優(yōu)思想。

優(yōu)化一：打開長連接配置

? ?通常Nginx作為代理服務(wù)，負責(zé)分發(fā)客戶端的請求，那么建議開啟HTTP長連接，用戶減少握手的次數(shù)，降低服務(wù)器損耗，具體如下：

upstream xxx {
    # 長連接數(shù)
    keepalive 32;
    # 每個長連接提供的最大請求數(shù)
    keepalived_requests 100;
    # 每個長連接沒有新的請求時，保持的最長時間
    keepalive_timeout 60s;
}

優(yōu)化二、開啟零拷貝技術(shù)

? ?零拷貝這個概念，在大多數(shù)性能較為不錯的中間件中都有出現(xiàn)，例如Kafka、Netty等，而Nginx中也可以配置數(shù)據(jù)零拷貝技術(shù)，如下：

sendfile on; # 開啟零拷貝機制

零拷貝讀取機制與傳統(tǒng)資源讀取機制的區(qū)別：

• 傳統(tǒng)方式：硬件-->內(nèi)核-->用戶空間-->程序空間-->程序內(nèi)核空間-->網(wǎng)絡(luò)套接字
• 零拷貝方式：硬件-->內(nèi)核-->程序內(nèi)核空間-->網(wǎng)絡(luò)套接字

從上述這個過程對比，很輕易就能看出兩者之間的性能區(qū)別。

優(yōu)化三、開啟無延遲或多包共發(fā)機制

? ?在Nginx中有兩個較為關(guān)鍵的性能參數(shù)，即tcp_nodelay、tcp_nopush，開啟方式如下：

tcp_nodelay on;
tcp_nopush on;

TCP/IP協(xié)議中默認是采用了Nagle算法的，即在網(wǎng)絡(luò)數(shù)據(jù)傳輸過程中，每個數(shù)據(jù)報文并不會立馬發(fā)送出去，而是會等待一段時間，將后面的幾個數(shù)據(jù)包一起組合成一個數(shù)據(jù)報文發(fā)送，但這個算法雖然提高了網(wǎng)絡(luò)吞吐量，但是實時性卻降低了。

因此你的項目屬于交互性很強的應(yīng)用，那么可以手動開啟tcp_nodelay配置，讓應(yīng)用程序向內(nèi)核遞交的每個數(shù)據(jù)包都會立即發(fā)送出去。但這樣會產(chǎn)生大量的TCP報文頭，增加很大的網(wǎng)絡(luò)開銷。

相反，有些項目的業(yè)務(wù)對數(shù)據(jù)的實時性要求并不高，追求的則是更高的吞吐，那么則可以開啟tcp_nopush配置項，這個配置就類似于“塞子”的意思，首先將連接塞住，使得數(shù)據(jù)先不發(fā)出去，等到拔去塞子后再發(fā)出去。設(shè)置該選項后，內(nèi)核會盡量把小數(shù)據(jù)包拼接成一個大的數(shù)據(jù)包（一個MTU）再發(fā)送出去.

當(dāng)然若一定時間后（一般為200ms），內(nèi)核仍然沒有積累到一個MTU的量時，也必須發(fā)送現(xiàn)有的數(shù)據(jù)，否則會一直阻塞。

tcp_nodelay、tcp_nopush兩個參數(shù)是“互斥”的，如果追求響應(yīng)速度的應(yīng)用推薦開啟tcp_nodelay參數(shù)，如IM、金融等類型的項目。如果追求吞吐量的應(yīng)用則建議開啟tcp_nopush參數(shù)，如調(diào)度系統(tǒng)、報表系統(tǒng)等。

注意：
①tcp_nodelay一般要建立在開啟了長連接模式的情況下使用。
②tcp_nopush參數(shù)是必須要開啟sendfile參數(shù)才可使用的。

優(yōu)化四、調(diào)整Worker工作進程

? ?Nginx啟動后默認只會開啟一個Worker工作進程處理客戶端請求，而我們可以根據(jù)機器的CPU核數(shù)開啟對應(yīng)數(shù)量的工作進程，以此來提升整體的并發(fā)量支持，如下：

# 自動根據(jù)CPU核心數(shù)調(diào)整Worker進程數(shù)量
worker_processes auto;

工作進程的數(shù)量最高開到8個就OK了，8個之后就不會有再大的性能提升。

同時也可以稍微調(diào)整一下每個工作進程能夠打開的文件句柄數(shù)：

# 每個Worker能打開的文件描述符，最少調(diào)整至1W以上，負荷較高建議2-3W
worker_rlimit_nofile 20000;

操作系統(tǒng)內(nèi)核（kernel）都是利用文件描述符來訪問文件，無論是打開、新建、讀取、寫入文件時，都需要使用文件描述符來指定待操作的文件，因此該值越大，代表一個進程能夠操作的文件越多（但不能超出內(nèi)核限制，最多建議3.8W左右為上限）。

優(yōu)化五、開啟CPU親和機制

? ?對于并發(fā)編程較為熟悉的伙伴都知道，因為進程/線程數(shù)往往都會遠超出系統(tǒng)CPU的核心數(shù)，因為操作系統(tǒng)執(zhí)行的原理本質(zhì)上是采用時間片切換機制，也就是一個CPU核心會在多個進程之間不斷頻繁切換，造成很大的性能損耗。

而CPU親和機制則是指將每個Nginx的工作進程，綁定在固定的CPU核心上，從而減小CPU切換帶來的時間開銷和資源損耗，開啟方式如下：

worker_cpu_affinity auto;

優(yōu)化六、開啟epoll模型及調(diào)整并發(fā)連接數(shù)

? ?在最開始就提到過：Nginx、Redis都是基于多路復(fù)用模型去實現(xiàn)的程序，但最初版的多路復(fù)用模型select/poll最大只能監(jiān)聽1024個連接，而epoll則屬于select/poll接口的增強版，因此采用該模型能夠大程度上提升單個Worker的性能，如下：

events {
    # 使用epoll網(wǎng)絡(luò)模型
    use epoll;
    # 調(diào)整每個Worker能夠處理的連接數(shù)上限
    worker_connections  10240;
}

這里對于select/poll/epoll模型就不展開細說了，后面的IO模型文章中會詳細剖析。

二、放在最后的結(jié)尾

? ?至此，Nginx的大部分內(nèi)容都已闡述完畢，關(guān)于最后一小節(jié)的性能優(yōu)化內(nèi)容，其實在前面就談到的動靜分離、分配緩沖區(qū)、資源緩存、防盜鏈、資源壓縮等內(nèi)容，也都可歸納為性能優(yōu)化的方案。文章來源地址http://www.zghlxwxcb.cn/news/detail-851206.html

到了這里，關(guān)于深入淺出 -- 系統(tǒng)架構(gòu)之負載均衡Nginx的性能優(yōu)化的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！