dyups模組對nginx效能影響
測試不同場景下dyup模組對nginx效能的影響，並以此為參考制定後續優化方案
公司採用dyups+tengine實現後端業務的動態發現，隨著業務增長以及新平台上線，我們nginx集群中的upstream總節點成倍增長。在此背景下，我們發現節點數較多的大業務集群滾動公升級時，nginx集群的響應時間會急劇增加。
在公司大佬原始碼解讀和測試後，我們定位到是大致原因是nginx的 worker會定期檢查共享記憶體從佇列裡讀取dyups更新指令，而由於有鎖的存在，同一時間只能有乙個worker進行dyups更新操作。當dyups變更的集群節點數較多時，dyups更新的時間會比較長，而worker準備執行dyups更新但上乙個worker
未完成dyups更新操作時，此worker阻塞住，不會繼續處理業務請求。若平台不停呼叫dyups變更upstream節點，隨著時間的推移，阻塞的worker會越來越多，會急劇降低nginx的效能。
下面我畫乙個理想情況下的簡單模型介紹一下幾種場景
假設worker檢查共享記憶體的時間點是均勻分布的
t1 t2 ... tn 為worker1 worker2 ... workern 檢查共享記憶體的時間點。一共有n個worker
t1 t2 ... tn 為worker1 worker2 ... workern 更新完dyups的時間點
此時每個worker更新完dyups時下乙個worker還未檢查共享記憶體，此時nginx的響應時間會稍漲，但總體影響較小
當t1時，worker1 執行完dyups變更，而worker2和worker3會被阻塞住。當t3時，worker4-worker7會被阻塞住。我們可以發現，隨著時間推移，阻塞的worker會越來越多
當dyups更新時間 大於 worker檢查共享記憶體時間間隔（dyups_read_msg_timeout ）/ worker數量 時，會必然出現worker阻塞的情況
tm時，workerm的下一次檢查共享記憶體的輪訓間隔已經到了，但workerm 的dyups更新還未完成，此時所有worker 都已經被阻塞住，nginx已經完全無法處理業務請求
要注意的是場景2之後由於會存在worker被阻塞的情況，此時nginx效能會處於非常不穩定的狀態，線上一定要避免達到此場景
伺服器: m02 20×2cores 256gb mem 兩台，一台作為nginx伺服器，另一台作為後端和客戶端伺服器
系統版本: centos 7.3
nginx版本: tengine/2.3.2(nginx/1.17.3)
背景流量: 10000 qps 由wrk作為客戶端
後端服務: flask * 40 例項，業務平均處理時長 0.1s
1. 變更的集群數量對nginx效能的影響
2. upstream總節點數對（1）的影響
3. dyups變更持續時間對nginx效能的影響
4. dyups變更間隔對nginx效能的影響
5. 開啟和關閉check模組對dyups模組和nginx效能的影響
6. worker 數量對dyups效能的影響
nginx總節點數為10000，變更間隔為1s，dyups變更的集群節點數為300、350、400、450和500時對 nginx效能的影響
upstream總節點數為10000、9000、8000、7000和6000，變更間隔為1s時，dyups變更的集群節點數對 nginx效能的影響
upstream總節點數為10000，變更間隔為1s，變更集群節點數為350時。變更持續時間對nginx效能的影響
upstream總節點數為10000，變更集群節點數為350，變更間隔為2s、1.5s、1s、0.5s時，nginx效能的影響
upstream總節點數為10000，變更間隔為1s，只關閉變更集群的主動健康檢查，dyups變更的集群節點數對 nginx效能的影響
upstream總節點數為10000，變更間隔為1s，關閉所有upstream主動健康檢查，dyups變更的集群節點數對 nginx效能的影響
在上述測試之外又做了一些關於引數的測試，但未記錄資料，下面只說結論
dyups_read_msg_timeout 這個指令設定了worker從共享記憶體中讀取指令的時間間隔。
調整此引數可以有效提高dyups的效能。但由於會影響dyups的時效性，所以調整需要慎重
dyups_trylock off 開啟此引數將獲得更好的效能，但它可能不穩定，並且當更新請求與其他請求衝突時，您將獲得「 409」。
開啟此引數時，當dyups未更新完時，nginx會拒絕新的修改dyups請求，並返回409狀態碼。這個實際上相當於強制提高了變更dyups間隔，由此避免worker阻塞惡化的場景出現
根據上面實驗結果，有以下優化方向
1. 減少單台nginx 總upstream節點數
2. 限制客戶端呼叫dyups頻率 ，儘量減少修改dyups總時間
3. 調大 dyups_read_msg_timeout （此引數會降低dyups時效性），開啟dyups_trylock
4. 棄用check模組，使用其他主動健康檢查方式
sendfile 對Nginx效能的提公升
linux kernel 2.2之前，如圖 讀寫資料基本都是使用read系統呼叫和write系呼叫，以nginx來說如果乙個請求建立，從磁碟的檔案到網路連線之間會通過硬體 dma 核心層 使用者層多次讀寫系統來完成檔案資料的複製傳輸 從核心層用read系統呼叫讀到使用者層，再從使用者層用write系...
對nginx和apache模組開發
簡要先介紹一下 1 nginx處理過程是非同步的，類似於醫院機構，效率比較高 apache處理過程是同步的，採用程序或者執行緒模型或者程序執行緒混合模型，請求過來一直處理到請求結束，中間過程一般不打斷 2 各有各的優點，apache模組開發較簡單，功能齊全，nginx模組開發較複雜，功能相對不齊全 ...
效能優化 Nginx 02 新增新模組
1 模組引數資訊參考 進入nginx解壓目錄 cd usr local src package nginx 1.16.1 2 例如 新增檢視狀態的模組，構建 3 重新編譯生成二進位制檔案 make 4 更新nginx命令 4.1 手動操作 備份原來的nginx檔案 cp usr local ngin...