場景:
a公司有100人,a公司只有一個公網ip,假設a公司可能有100個人同時在下載你的網站文件。
但是,你的連接數限制配置為:
limit_conn_zone?$binary_remote_addr?zone=perip:1m; server?{ ?--- ?limit_conn?perip?1; ?limit_rate?1024k; ?--- }
允許單個連接數,單個連接數最大帶寬為1m。
這樣就會有99個人的請求狀態為 503, 其他人如果想下載就必須人工等待(nginx不會通知用戶說a用戶下載完了,該你b用戶下載了)。這樣造成的用戶體驗極差。但是優點也很明顯,帶寬很快就會降下來。
可能有人就要問了,你限制成很低的連接數是想搞事情?no,絕對不是。前面的100個人同時下載網站資源的情況有多大呢?沒做過統計,但是可能性極小。并且前端頁面和下載資源不共用一個域名,所以不會影響到前端頁面的訪問。
那都是誰在大量使用連接數呢?分兩類:
-
下載工具類(迅雷)。
-
各種各樣的采集程序。
-
同時進行多個下載任務。
小明快樂的在看電視,瞥了左邊頻幕一眼,握草,帶寬又滿了,來吧,限速吧,
limit_conn_zone?$binary_remote_addr?zone=perip:1m; server?{ ?--- ?limit_rate?1024k; ?--- }
小明做了如上限速,ok,我告訴你們誰被限速了,當然是瀏覽器下載用戶,360瀏覽器的下載器都不一定能限制,好的,來算算速度吧。
瀏覽器: 2014k
下載器: 1024 * 15(最大連接數) * vip
采集器: 1024 * 連接數
所以我們得到如下結論:
帶寬有限,同個ip同時下載的情況很小的,或者說是可以預知的業務,盡量將連接數限制的小一點。
反之,別限制了。就降低單個連接數帶寬吧!要知道大家誰沒事會用瀏覽器自帶下載器下載呢?
注:本文只探討nginx限速模塊在不同業務下的限速
彩蛋:偶爾發現,將連接數限制為1迅雷不能高速下載了。
? 版權聲明
文章版權歸作者所有,未經允許請勿轉載。
THE END