nginx limit_zone與limit_req_zone測試報告

來源:互聯網
上載者:User

nginx 上有兩個限制串連的模組一個是 limit_zone 另一個是 limie_req_zone,兩個都可以限制串連,但具體有什麼不同呢?
下面是 nginx 官網上給的解釋
limit_req_zone
Limit frequency of connections from a client.
This module allows you to limit the number of requests for a given session, or as a special case, with one address.
Restriction done using leaky bucket.

limit_zone
Limit simultaneous connections from a client.
This module makes it possible to limit the number of simultaneous connections for the assigned session or as a special case, from one address.

按照字面的理解,lit_req_zone的功能是通過 令牌桶原理來限制 使用者的串連頻率,(這個模組允許你去限制單個地址 指定會話或特殊需要 的請求數 )
而 limit_zone 功能是限制一個用戶端的並發串連數。(這個模組可以限制單個地址 的指定會話 或者特殊情況的並發串連數)
一個是限制並發串連一個是限制串連頻率,表面上似乎看不出來有什麼區別,那就看看實際的效果吧~~~
在我的測試機上面加上這兩個參數下面是我的部分設定檔
http{
limit_zone one  $binary_remote_addr  10m;
#limit_req_zone  $binary_remote_addr  zone=req_one:10m rate=1r/s;
server
{
 ......
limit_conn   one  1;
#limit_req   zone=req_one  burst=120;
......
}
    }

解釋一下 limit_zone one  $binary_remote_addr  10m;
這裡的 one 是聲明一個 limit_zone 的名字,$binary_remote_addr是替代 $remore_addr 的變數,10m 是工作階段狀態儲存的空間
limit_conn one 1 ,限制用戶端並發串連數量為1
先測試 limit_zone 這個模組
我找一台機器 用ab 來測試一下 命令格式為
ab -c 100 -t 10 http://192.168.6.26/test.php
test.php 內容是phpinfo
看看日誌裡的訪問

看來也不一定能限制的住1秒鐘1個並發串連,(有網友跟我說這是因為測試的檔案本身太小了才會這樣,有時間一定測試一下),從日誌裡面可以看得出來 除了幾個200以外其他的基本都是503,多數並發訪問都被503了。
我又用ab多運行了一會兒,發現另一種情況


似乎隨著數量的增多效果也會發生一些變化,並不是完全達到模組說明中的效果
看看當前的tcp串連數
# netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
TIME_WAIT 29
FIN_WAIT1 152
FIN_WAIT2 2
ESTABLISHED 26
SYN_RECV 16

這次測試下 limit_req_zone,設定檔稍微改動一下
http{
#limit_zone one  $binary_remote_addr  10m;
limit_req_zone  $binary_remote_addr  zone=req_one:10m rate=1r/s;
server
{
 ......
#limit_conn   one  1;
limit_req   zone=req_one  burst=120;
......
}
    }
restart 一下 nginx
簡單說明一下, rate=1r/s 的意思是每個地址每秒只能請求一次,也就是說根據令牌桶原理 burst=120 一共有120塊令牌,並且每秒鐘只新增1塊令牌,
120塊令牌發完後 多出來的那些請求就會返回503
測試一下
ab -c 100 -t 10 http://192.168.6.26/test.php
看看這時候的訪問日誌

確實是每秒請求一次,那多測試一會兒呢?把時間從10秒增加到30秒

 

這個時候應該是120 已經不夠用了,出現很多503,還有兩種情況會出現,請看圖


這種情況很像是 在隊列裡的一些請求得不到響應而逾時了,但我不確定是不是這種情況。


用戶端自己等不及斷開了,返回499
看看當前的tcp串連數
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
TIME_WAIT 51
FIN_WAIT1 5
ESTABLISHED 155
SYN_RECV 12

雖然這樣會讓nginx 一秒鐘只處理一個請求,但是仍然會有很多還在隊列裡面等待處理,這樣也會佔用很多tcp串連,從上面那條命令的結果中就能看得出來。
如果這樣呢
limit_req   zone=req_one  burst=120 nodelay;
加上 nodelay之後超過 burst大小的請求就會直接 返回503,

也是每秒處理1個請求,但多出來的請求沒有象剛才那樣等待處理,而是直接返回503。
當前的tcp串連
# netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
TIME_WAIT 30
FIN_WAIT1 15
SYN_SENT 7
FIN_WAIT2 1
ESTABLISHED 40
SYN_RECV 37
已串連的數量比上面的少了一些
通過這次測試我發現 這兩種模組都不能做到絕對的限制,但的確已經起到了很大的減少並發和限制串連的作用,在生產環境中具體用哪種或者需要兩種在一起使用就要看各自的需求了。
測試就到這裡,如果文章裡有不對的地方請大家及時指正,謝謝
本文出自 “story的天空” 部落格

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.