NGINX應用效能優化指南(第四部分) 負載均衡

2021-09-17 18:55:35 字數 2256 閱讀 5178

【編者的話】本文是「nginx應用效能優化指南」系列文章的第四篇,主要介紹了如何從負載均衡方面實現nginx應用效能優化。\

\ nginx允許使用upstream指令配置後台。最值得注意的是會話持久化和負載均衡策略。\

在會話持久化方面,有三個有用的變數需要考慮:\

往返時間; \

用於會話持久化的**tcp cwnd; \

持久化會話數。

\ rtt非常低則可以在**和應用伺服器之間快速建立連線,並快速提高**的吞吐量。因此,對於(傳統的)集中配置後台,熱連線確實可以減少處理未快取請求的工作。\

不過,如果你已經部署了反向**,將未快取請求引向遠端源伺服器(例如海岸到海岸80毫秒),保持連線可以節省大量的連線建立時間——尤其是當你必須提供加密吞吐量的時候。(回想一下,新建乙個tls隧道需要消耗3個rtt進行協商。)\

對於遠端後台,你可能也會想用tcp_slow_start_after_idle(在sys.net.ipv4中)。這決定了cwnd的大小是否會在連線空閒(乙個rto)後恢復到初始值。通常,在正常情況下,那個行為是啟用的,而且是期望的行為。但是,如果你在使用乙個專用的點對點連線,那麼你會希望禁用它,因為那不太可能遇到擁塞。bdp也不大可能變化。\

現在,我知道你在想什麼:我沒有乙個專用連線,但讓我貪心一次,無論如何都試一試!但下注時要考慮風險和回報。\

在比較當前擁塞視窗大小和你對未來bdp(比如平均吞吐率乘以平均rtt)的推測時,分析真就派上用場了。還有一點值得考慮:對頻寬成本的影響,假設資料不全在遠端。\

另外,如果你的bdp與初始擁塞視窗相比非常大,那麼就要重新配置初始cwnd。此外,對於在快速lan(像aws ec2)上集中部署的後台,可能就不需要檢查其中任何一項了。\

持久化後台連線\

指令keepalive(會話持久化)設定每個工作程序同上游伺服器保持的最大空閒連線數。換句話說,當乙個工作程序的連線超出了keepalive設定的數量,它會開始關閉最近最少使用的空閒連線,直到達到那個數值。可以將它想象成每個工作程序的連線池。\

支援後台keepalive需要http/1.1,因為,我們需要設定proxy_http_version指令,並清除connection頭。對於nginx:

upstream backend \server \}\
\

在設定keepalive的值時要記住以下幾點:\

\ 除非你已經配置了輪詢負載均衡,否則很難**每個應用伺服器上的連線分配。更準確地說,那取決於你的負載均衡策略、每個請求的處置以及請求時間。\

當每個工作程序都與同乙個後台伺服器建立其所有的連線時,(不大可能發生的)最壞場景就會出現。不過,那充分表明負載均衡策略需要重新考慮了。\

注意:如果你在應用程式伺服器上執行著乙個預設nginx配置,其worker_connections上限會被設定為512.\

\

\\

nginx提供了如下負載均衡策略:\

加權輪詢; \

hash:基於使用者定義鍵的雜湊; \

least_conn:最少活動連線數; \

least_time:nginx plus提供了最少平均響應時間策略。

在效能方面,least_time可能是首選,但是如果你的後台由相同的高效能應用伺服器組成,那麼這種策略跟你關係就不大了。此外,haship_hash提供了有用的選項。例如,如果應用伺服器需要一段時間載入使用者資料,將同乙個使用者傳送給相同的後台伺服器可能會受益於快取命中。\

客戶端的ip位址由$remote_addr變數提供。但是留心客戶端ip雜湊,因為乙個ip位址可能表示來自同乙個nat的多個使用者(比如公司辦公室或學校)。\

檢視英文原文:感謝郭蕾對本文的審校。

\

Android應用效能優化

記憶體,ui,電量 1.記憶體 首先簡單介紹一下android系統記憶體管理機制.記憶體共享 預設情況 string vmheapsize systemproperties.get dalvik.vm.heapsize 16m 只有16m.可以通過在device.mk檔案中設定 product pr...

Android應用效能優化

1 anr 2 listview 卡頓,不流暢 3 activity啟動慢 4 動畫不流暢,啟動前卡頓 5 自定義view啟動慢 6 oom 7 資料庫大量操作 8 長時間執行後,程式變慢 1 語言層解決問題,語法上提高效能 2 合理的資料結構和演算法 3 布局優化,布局深度控制 4 工作執行緒與u...

Web應用效能優化思路

瓶頸是什麼?一條4車道的公路,執行非常順暢,突然出了點事故,事故車導致某個地方只剩下1車道,然後就開始堵車,因為四輛車同時塞向乙個車道裡。把這個事故清除了,故障車拖走了,道路會開始恢復了通暢。這個道理誰都懂,但偏偏有些傻瓜交警去把4車道變成8車道,但卻不清理事故路段。乙個web應用,不管是何種語言開...