丫忠最近在修改一些 Nginx 的設定，也看到了一篇關於 Nginx 不錯的文章，是一篇關於Nginx代理Web伺服器設定的測試文章，順便轉貼過來作為以後參考用。
測試目的
（1）弄清楚HTTP Upstream模塊中Server指令的max_fails與fail_timeout參數的關係、它們對後端服務器健康情況的檢查起到了什麼作用、它們的取值對Http proxy模塊中的其它指令是否有直接或間接的影響等……
（2）測試HTTP Proxy模塊中proxy_next_upstream、proxy_connect_timeout、proxy_read_timeout、proxy_send_timeout指令的作用、對nginx性能的影響、對後端服務器響應的處理等……
測試方法
本文測試不會使用壓力測試，所有的測試都是通過瀏覽器手動刷新來實現的。 後端服務器使用簡單的php程序來實現。
測試環境
Nginx負載均衡/反向代理服務器
系統：CentOS 5.4 64bit
Nginx：0.7.65
IP:192.168.108.10
後端web服務器
系統：CentOS 5.4 64bit
Web環境：apache+php
Web-1 IP:192.168.108.163
Web-2 IP:192.168.108.164
本次測試主要針對HTTP Upstream和HTTP Proxy模塊進行，下面測試環境中http upstream 和http proxy模塊參數的初始化設置，後文會針對測試的參數進行相應的修改：
…
upstream test {
server 192.168.108.163 ;
server 192.168.108.164:80;
}server {
listen 80;
server_name .test.com;
index index.php index.html index.htm;location / {
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504 http_404;proxy_connect_timeout 10s;
proxy_read_timeout 2s;
#proxy_send_timeout 10s;
proxy_pass http://test;
}
}
…
提出server指令後面的參數部分，以下摘抄nginx wiki 內容
語法：server name [parameters]
parameters包含：
·weight = NUMBER -設置服務器權重，默認為1。
·max_fails = NUMBER -在一定時間內（這個時間在fail_timeout參數中設置）檢查這個服務器是否可用時產生的最多失敗請求數，默認為1，將其設置為0可以關閉檢查，這些錯誤在proxy_next_upstream或fastcgi_next_upstream （404錯誤不會使max_fails增加）中定義。
·fail_timeout = TIME -在這個時間內產生了max_fails所設置大小的失敗嘗試連接請求後這個服務器可能不可用，同樣它指定了服務器不可用的時間（在下一次嘗試連接請求發起之前），默認為10秒，fail_timeout與前端響應時間沒有直接關係，不過可以使用proxy_connect_timeout和proxy_read_timeout來控制。
·down -標記服務器處於離線狀態，通常和ip_hash一起使用。
·backup – (0.6.7或更高)只用於本服務器，如果所有的非備份服務器都宕機或繁忙。
關於max_fails參數的理解：根據上面的解釋，max_fails默認為1，fail_timeout默認為10秒，也就是說，默認情況下後端服務器在10秒鐘之內可以容許有一次的失敗，如果超過1次則視為該服務器有問題，將該服務器標記為不可用。 等待10秒後再將請求發給該服務器，以此類推進行後端服務器的健康檢查。 但如果我將max_fails設置為0，則代表不對後端服務器進行健康檢查，這樣一來fail_timeout參數也就沒什麼意義了。 那若後端服務器真的出現問題怎麼辦呢？ 上文也說了，可以藉助proxy_connect_timeout和proxy_read_timeout進行控制。
下面介紹http proxy模塊中的相關指令：
proxy_next_upstream
語法： proxy_next_upstream [error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off]
確定在何種情況下請求將轉發到下一個服務器。 轉發請求只發生在沒有數據傳遞到客戶端的過程中。
proxy_connect_timeout
後端服務器連接的超時時間_發起握手等候響應超時時間
proxy_read_timeout
連接成功後_等候後端服務器響應時間_其實已經進入後端的排隊之中等候處理（也可以說是後端服務器處理請求的時間）
proxy_send_timeout
後端服務器數據回傳時間_就是在規定時間之內後端服務器必須傳完所有的數據
proxy_pass
這個指令設置被代理服務器的地址和被映射的URI
開始測試
情況1：後端程序執行時間超過或等於proxy_read_timeout設置值，max_fails=0 關閉後端服務器健康檢查。
| Nginx配置修改內容 | server 192.168.108.163 max_fails = 0; server 192.168.108.164 max_fails = 0; proxy_next_upstream error timeout proxy_read_timeout 2s |
| 後端web服務器 | |
| Web1 test.php | Web2 test.php |
| <?php header(‘RS:Web1′); $t = 2; sleep($t); echo 『sleep {$t}s<br>』; echo 『web-1<br>』; ?> |
<?php header(‘RS:Web2′); $t = 5; sleep($t); echo 『sleep {$t}s<br>』; echo 『web-2<br>』; ?> |
| 備註：
我這裡的兩台後端web服務器，他們的主頁文件均為一個test.php程序，該程序分別sleep了2秒和5秒，等於和超過了proxy_read_timeout的時間，[max_fails=0] 即關閉後端服務器健康檢查。[proxy_next_upstream error timeout] 說明碰到錯誤或超時的情況切到下一個後端服務器。 如此設置後利用curl命令對nginx發起連接請求，看nginx會作何反應。 |
|
| 測試開始：
（1）curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer}www.test.com/test.php 4.008:0.002:4.007 說明： 連續請求3次後得到的http返回結果是一樣的，均為504 Gateway Time-out 錯誤。 這種情況只有在後端服務器都有問題的時才會出現這個錯誤，很顯然我這裡的proxy_read_timeout設置的時間太短，後端程序還沒來得及把程序執行完，nginx就迫不及待的將請求甩給upstream定義的另一台服務器上了，當發現另外一台服務器同樣2秒沒有返回後，nginx這回沒有服務器可用，只有返回504 Gateway Time-out 。 這也是為什麼最後的time_total時間是4秒。 （經查看兩台web服務器的訪問日誌得知，均有一條訪問記錄，且返回代碼為200，說明nginx確實來過，但沒有等到執行完成就匆匆的離去了）如果我有3台服務器，在保證任何不變的情況下，time_total時間一定會是6秒，因為nginx會一個接一個的將3台服務器都走一遍。 ————————————————– ————————————————– ——————- 好了，確認是我proxy_read_timeout設置時間太短後，我將它的值設置為3秒，再通過curl命令訪問： （2）curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php 5.042:0.005:5.042 說明：通過3次連續請求，得到的結果是一樣的，RS:Web1 也就是說我這三次的請求都甩到了web1上。 但我web1中的程序只需要2秒後就可以返回結果，但為什麼我通過nginx代理後時間總是我的程序執行時間+proxy_read_timeout時間呢？ ————————————————– ————————————————– ——————- 繼續將proxy_read_timeout設置為4s （3）curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php 6.004:0.000:6.004 三次請求後結果也是一樣，這次花的時間更長了，但確實是程序執行時間+proxy_read_timeout 時間。 但為什麼每次都需要6秒呢？ 按照upstream中定義的權重應該是平分請求的，最起碼應該有2秒的時候。 經過分析得知：最終返回給用戶請求的是web1，那麼當再次請求的時候一定會分給web2，由於web2是sleep 5秒的，因此經過proxy_read_timeout的時間（4s）後會跳到web1，結果還是web1返回的請求，所花時間就是nginx在web2等待的時間+web1執行的時間，以此類推下一次nginx自然的還會分給web2……。 如果有更多的後端web，則判斷下一個請求服務器可以看當前返回給最終用戶的是那台服務器，然後根據upstream中定義的順序向下查詢（權重一樣的情況） |
|
| 結論：
（1）上面的三次測試分別將proxy_read_timeout的值設置為2s、3s、4s的情況進行的。 最終的測試結果也都在後面做了解釋與說明。 由於我關閉了後端服務器的健康檢查（max_fails=0）因此判斷後端服務器情況的唯一依據便是proxy_read_timeout參數，如果這個參數設置得過小，但後端程序的執行或多或少會超過這個時間的話，這種情況nginx的效率是非常低的。 （2）上面的測試都是後端服務器正常但執行超時的情況下nginx根據proxy_read_timeout和proxy_next_upstream的值來選擇下一個服務器，那如果我後端服務器直接報錯的情況呢？ 可以想到如果報錯信息在proxy_next_upstream 中有定義的話nginx還會跳到下一台服務器。 否則直接將保存信息返回給nginx從而最終呈獻給用戶 |
|
情況2：打開後端服務器健康檢查，測試程序執行時間超過或等於proxy_read_timeout值或後端服務器直接報錯的情況
| Nginx配置修改內容 | server 192.168.108.163 max_fails = 1; server 192.168.108.164 max_fails = 1; proxy_next_upstream error timeout http_500 http_502 http_504 proxy_read_timeout 2s |
|
| 後端web服務器 | ||
| Web1 test.php | Web2 test.php | |
| <?php header(‘RS:Web1′); $t = 2; sleep($t); echo 『sleep {$t}s<br>』; echo 『web-1<br>』; ?> |
<?php header(‘RS:Web2′); header(‘http/1.1 500 Internal Server Error ‘); #$t = 5; #sleep($t); echo 『sleep {$t}s<br>』; echo 『web-2<br>』; ?> |
|
| 備註：
開啟了後端服務器健康檢查 |
||
| 測試開始：
（1）連續測試三次結果如下： curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php 2.005:0.001:2.005 curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php 0.001:0.001:0.001 curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php 2.005:0.001:2.005 說明： 第1次請求所用時間是2秒，web1執行超時，web2返回了500錯誤，upstream沒有更多的後端，因此nginx直接把504扔出來了，同時標記web2，web1不可用。 查看後端2台web服務器的訪問日誌，均有nginx代理的訪問記錄。 （2）修改proxy_read_timeout 3s 連續訪問6次後結果以及2台web服務器的日誌情況 2.003:0.001:2.002 訪問日誌 Web1 Web2 [18/May/2010:15:30:00 說明： 由訪問日誌可知： |
||
| 結論：
（1）proxy_next_upstream參數很有用，他可以避免很多錯誤 |
||
原創文章，轉載請註明: 轉自http://salogs.com
