Nginx 做爲反向Proxy 的優化要點

經常使用優化要點

當nginx用於反向代理時，每一個客戶端將使用兩個鏈接：

一個用於響應客戶端的請求，另外一個用於到後端的訪問；

若是機器是兩核CPU，例如：

$ grep ^proces /proc/cpuinfo | wc -l
2

那麼，能夠從以下配置起步:

# One worker per CPU-core.
worker_processes  2;
events {
    worker_connections  8096;
    multi_accept        on;
    use                 epoll;
}
worker_rlimit_nofile 40000;
http {
    sendfile           on;
    tcp_nopush         on;
    tcp_nodelay        on;
    keepalive_timeout  15;
}

標準的代理配置

下面是一個基本的反向代理配置模板，將全部請求都轉發給指定的後端應用。

例如，到http://your.ip:80/的請求都將重定向到 http://127.0.0.1:4433/ 私有服務器:

# One process for each CPU-Core
worker_processes  2;
# Event handler.
events {
    worker_connections  8096;
    multi_accept        on;
    use                 epoll;
}
http {
     # Basic reverse proxy server
     upstream backend  {
           server 127.0.0.1:4433;
     }
     # *:80 -> 127.0.0.1:4433
     server {
            listen       80;
            server_name  example.com;
            ## send all traffic to the back-end
            location / {
                 proxy_pass        http://backend;
                 proxy_redirect    off;
                 proxy_set_header  X-Forwarded-For $remote_addr;
            }
     }
}

下面，咱們將在此基礎上進行優化。

緩衝控制

若是禁止緩衝，那麼當Nginx一收到後端的反饋就同時傳給客戶端。

nginx 不會從被代理的服務器讀取整個反饋信息。

nginx可從服務器一次接收的最大數據大小由  proxy_buffer_size 控制。

proxy_buffering    off;
proxy_buffer_size  128k;
proxy_buffers 100  128k;

緩存和過時控制

上面的配置是將全部請求都轉發給後端應用。爲避免靜態請求給後端應用帶來的過大負載，咱們能夠將nginx配置爲緩存那些不變的響應數據。

這就意味着nginx不會向後端轉發那些請求。

下面示例，將 *.html, *.gif, 等文件緩存30分鐘。:

http {
     #
     # The path we'll cache to.
     #
     proxy_cache_path /tmp/cache levels=1:2 keys_zone=cache:60m max_size=1G;
}
            ## send all traffic to the back-end
            location / {
                 proxy_pass  http://backend;
                 proxy_redirect off;
                 proxy_set_header        X-Forwarded-For $remote_addr;
                 location ~* \.(html|css|jpg|gif|ico|js)$ {
                        proxy_cache          cache;
                        proxy_cache_key      $host$uri$is_args$args;
                        proxy_cache_valid    200 301 302 30m;
                        expires              30m;
                        proxy_pass  http://backend;
                 }
            }

這裏，咱們將請求緩存到 /tmp/cache，並定義了其大小限制爲1G。同時只容許緩存有效的返回數據，例如:

proxy_cache_valid  200 301 302 30m;

全部響應信息的返回代碼不是 "HTTP (200|301|302) OK" 的都不會被緩存。

對於例如workpress的應用，須要處理cookies 和緩存的過時時間，經過只緩存靜態資源來避免其帶來的問題。

驗證

優化配置的效果須要實踐檢驗，建議部署一個監控工具，監控的內容應包括：

Nginx：開源版提供的監控指標，僅有以下7個指標：

Connections，Accepts，Handled，Requests，Reading，Writing，Waiting，

爲便於分析統計，在Hyperic中可擴展爲10個指標，增長了三個派生指標，每分鐘的接收，請求和處理的數量：

Accepts per Minute，Handled per Minute，Requests per Minute

從操做系統的角度：應包括Nginx進程的CPU使用率，內存佔用，總體CPU使用率，交換區使用率等指標。

若是是在虛擬機上運行，還應關注 操做系統的 ST( Steal Time)指標，判斷是否有超賣，過載等現象；

超賣：超賣是指主機商在一臺服務器上放了太多的VPS帳戶，若是遇到全部的VPS帳戶同時使用全部的資源，就會出現服務器沒法訪問的狀況，嚴重時硬件癱瘓 、數據丟失。但超賣很難察覺。有時經過 ST 指標能夠看到。

參考資源：

http://tweaked.io/guide/nginx-proxying/

網絡管理軟件hyperic hq監控和管理Nginx

Hyperic 監控 Nginx1.6 配置過程

下載免費開源Hyperic