Nginx 做爲web server 的優化要點

經常使用優化要點

nginx使用的是固定數量的workers, 每一個worker都處理進入的請求。最佳實踐是每一個CPU內核配置一個worker.

如何知道您的系統有幾個CPU？

$ grep ^processor /proc/cpuinfo | wc -l

對於一個四核處理器，配置文件相似：

# One worker per CPU-core.

worker_processes  4;
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;
    # Your content here ..
}

這裏咱們提升了 worker_connections 設置，定義了每一個worker進程能處理多少鏈接。

服務器的最大鏈接數量是：

worker_processes * worker_connections (= 32384 本例中)

這裏啓用了 multi_accept，該配置項使nginx能儘快接收儘量多的請求，減小客戶端的鏈接初始化時間。

最後，本例中使用了 epoll 的事件模型，這也是最佳實踐建議。

壓縮

不少用戶會啓用 gzip壓縮模塊，使得返回客戶端的內容更簡短，傳輸更快。

可是壓縮會消耗用戶服務器資源，經過監控CPU使用率（可採用開源Hyperic），若是太高，能夠考慮禁用壓縮。

一般只壓縮大文件，避免壓縮那些壓縮效果很差的文件，例如圖片，可執行文件等二進制文件。

用戶可參考下面配置：

gzip  on;
gzip_vary on;
gzip_min_length 10240;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml;
gzip_disable "MSIE [1-6]\.";

上面配置，只對文件大於10k的文本文件進行壓縮。

客戶端緩存

若是客戶端（通常是瀏覽器）認爲已經保存了要下載的最新內容，就不會向nginx服務器再發請求。

這須要作一些緩存設置。最簡單的辦法是將全部的圖片，js等靜態內容設置一個固定的時間長度：

location ~* \.(jpg|jpeg|gif|png|css|js|ico|xml)$ {
         access_log        off;
         log_not_found     off;
         expires           30d;
     }

這裏咱們也禁用了媒體文件的日誌，將一些文件後綴文件的過時時間設置爲30天。

文件句柄緩存

若是須要處理大量靜態文件，須要保持這些文件句柄爲打開狀態，避免後續再次打開。

下面示例，既可放在nginx配置的 server 部分，也可放在主 http 塊中。:

open_file_cache          max=2000 inactive=20s;
open_file_cache_valid    60s;
open_file_cache_min_uses 5;
open_file_cache_errors   off;

這裏設置服務器最大緩存2000個打開的文件句柄，關閉20秒內無請求的文件句柄，句柄的有效時間是60秒，而且只有訪問次數超過5次的纔會被緩存。這樣只緩存頻繁訪問的文件，下降文件系統的訪問。

優化PHP

不少站點使用了PHP，例如drupal, wordpress。

因爲nginx沒有本身的mod_php，推薦的方式是使用 PHP-FPM，須要將請求轉發，例如：

# execute all .php files via php-fpm
        location ~ .php$ {
            # connect to a unix domain-socket:
            fastcgi_pass   unix:/var/run/php5-fpm.sock;
            fastcgi_index  index.php;
            fastcgi_param   SCRIPT_FILENAME    $document_root$fastcgi_script_name;
            fastcgi_param   SCRIPT_NAME        $fastcgi_script_name;
            fastcgi_buffer_size 128k;
            fastcgi_buffers 256 16k;
            fastcgi_busy_buffers_size 256k;
            fastcgi_temp_file_write_size 256k;
            # This file is present on Debian systems..
            include fastcgi_params;
        }

注意這裏使用了 Unix domain-socket 鏈接 FPM, 因此須要修改/etc/php5/fpm/pool.d/www.conf 以下：

listen = /var/run/php5-fpm.sock

這保證FPM監聽一個domain socket，而不是默認的（ "listen=127.0.0.1:9000").

默認的PHP-FPM將啓動一些專用的worker，每一個運行一個PHP實例。若是內存足夠，能夠增長worker數量來提高併發吞吐量。

編輯文件 /etc/php5/fpm/pool.d/www.conf,改變數量，例如:

; set a fixed number of php workers
pm = static
; start up 12 php processes
pm.max_children = 12

該值須要根據實際環境調整。調整的依據是使用監控工具所採集的數據。

最後可配置PHP-FPM自動重啓。若是出現問題，例以下面的配置是，在1分鐘內十個子進程死掉，就重啓，容許進程有十秒失去控制。

下面是/etc/php5/fpm/php-fpm.conf 中的全局配置:

emergency_restart_threshold 10
emergency_restart_interval 1m
process_control_timeout 10s

檢驗

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

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

    Connections，Accepts，Handled，Requests，Writing，Waiting

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

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

這裏推薦一個免費開源工具， Hyperic 

相關文章：

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

Hyperic 監控 Nginx1.6 配置過程

下載免費開源Hyperic