優化思路淺析

要優化 Web 服務器的性能，我們先來看看 Web 服務器在 web 頁面處理上的步驟：

1. Web 瀏覽器向一個特定的服務器發出 Web 頁面請求; 2. Web 服務器接收到 web 頁面請求后，尋找所請求的 web 頁面，并將所請求的 Web 頁面傳送給 Web 瀏覽器; 3. Web 瀏覽器接收到所請求的 web 頁面內容，并將它顯示出來。

上面三個步驟都關系 Web 服務器，但實際 Web 服務器性能相關最大的是在第 2 步，這里 Web 服務器需要尋找來自瀏覽器所請求的 Web 頁面內容。

我們知道，Web 頁面內容有靜態的，也有動態的，靜態的內容，web 服務器可以直接將結果發回給瀏覽器，對于動態內容，則通常需要交給應用服務器先處理，由應用服務器返回結果。

當然，也有 Web 服務器本身可以處理動態內容的，例如 IIS 就可以自已解釋處理 ASP, ASP.NET 這兩種微軟的動態網頁腳本語言。

從上面簡要的分析里，我們大致可以得到這樣的結論，影響 Web 頁面訪問的影響因素會有這幾個：

Web 服務器從磁盤中讀取靜態頁面內容的速度，也即時間;

Web 服務器判定請求內容是靜態還是動態內容的時間;

Web 服務器轉發請求給應用服務器的時間;

應用服務器處理(解釋)動態內容所需的時間;

Web 服務器返回 Web 內容給瀏覽器的響應時間;

Web 服務器接收來自瀏覽器請求的處理性能;

Web 訪問請求數據在網絡上傳輸的時間：包括從瀏覽器到服務器，和從服務器到瀏覽器兩部分;

瀏覽器本地計算和渲染 Web 內容的時間，即接收內容后展現內容的時間。

上面 8 項很容易理解，也很直接，其實還有以下幾項也是關乎 Web 頁面訪問速度體驗的因素，你可以思考下是否如此?或者說是否會影響到頁面訪問性能。

Web 服務器執行安全策略檢查的時間，或者說性能;

Web 服務器讀取日志文件、寫日志內容、關閉對日志文件訪問的時間，先讀后寫再關閉，這三步中的讀與寫又涉及到磁盤訪問性能因素;

同時與 Web 服務器連接會話的客戶端數量大小，即并發訪問量多大。

我們可以將上面一共 11 項影響因素抽像出來，那么就是：

Web 服務器磁盤性能;

Web 服務器與應用服務器交互的性能;

應用服務器處理動態內容的性能，或者說動態內容應用處理性能;

客戶端與 Web 服務器的連接速度，即網絡傳輸性能;

Web 瀏覽器解釋和渲染 Web 內容的性能;

Web 訪問并發性能。

反映到我們進行性能優化，可以入手的角度就有：

增加帶寬，包括服務器和客戶端兩邊的 Internet 連接帶寬;

加快動態內容的處理性能;

盡可能多地使用靜態內容，這樣 Web 服務器就可以無需請求應用服務器，直接將 Web 內容發給瀏覽器端，這里可以入手的方案又有：

動態內容緩存

動態內容靜態化

多臺服務器負載均衡同時處理大量的并發訪問;

提升服務器磁盤訪問性能，也即通常所說的 I/O 性能;

減少網頁中的 HTTP 請求數;

更換更好性能的 Web 服務器;

合理部署服務器，在離客戶端更近的地方部署服務器，已經證明可以明顯地提升訪問性能。

性能優化實踐

經過前面小節的簡要分析，我相信你對優化 Web 服務器有一定的思路了，你可以從硬件層面、軟件層面、Web 代碼三個層面去優化。

下面我們結合一個具體的實例來實踐一回，本文所舉例是一個小型的 Web 站點，部分數據系假設，如有類同，純屬巧合，僅起拋磚引玉之用。在實際工作中，如果碰到大站點，你可以參考此處的分析，修改優化方案。

1. 站點簡介

一個社區論壇站點，采用 Discuz! 論壇程序構建，該程序采用主流的 PHP + MySQL 組成。

網站目前有近 5 萬注冊用戶，絕大多數是國內的用戶，活躍用戶數在一半左右，每天平均 PV 在 15~20 萬，獨立訪問 IP 數在 8000 左右。

2. Web 服務器性能優化需求

網站現部署在國外的服務器，租用虛擬主機來運營，因為訪問量比較大，所以經常會收到虛擬主機服務商的流量很大的通知，要求控制下訪問量。

另外，虛擬主機的服務器在美國，沒有在國內租用虛擬主機的原因是國內網站在備案方面非常繁瑣，在網站一開始運營時數據量和訪問量都比較小，所以對性能要求不高，數據量小，所以服務器在查詢處理數據時速度比較快，也讓人感覺訪問速度不慢，現在隨著數據量和訪問量的不斷上升，訪問速度已明顯下降，到了需要改善訪問性能的時候了。

基于目前該社區網站的情況，提出的優化需求是，國內訪問速度需要提升一倍，目前首頁加載時間需要 40 秒左右，希望優化后能在 20 秒以內將首頁加載完成。

另外提出網站數據能夠每天自動備份一次，備份數據保留一個月的，以便隨時恢復。

上述兩點需求，其中第一條才是性能優化需求，第二條是額外的需求了。

3. 性能優化方案

根據其網站的現狀和優化需求，結合自己的經驗，加上谷歌的搜索，同時與網站主不斷確認溝通，最終得到以下性能優化方案：

由虛擬主機部署改為獨立服務器部署

虛擬主機受限比較多，無法自己自定義配置 Web 服務器，無法配置 PHP 動態緩存，而且獨立服務器可以獨享內存、處理器資源，不再受虛擬主機商對每個虛擬主機用戶的內存和處理器資源占用限制。處理器資源和內存資源，對接受更多并發訪問有直接性能提升效果。

獨立服務器，我們選用 Linode 2048 型號，2G 內存，4 核處理器(Linode 所有 VPS 都是四核處理器)，80G 硬盤空間，800G 網絡流量。

由 Windows 操作系統改為 Linux 操作系統

網站使用的是 PHP + MySQL 程序，PHP 在 Windows 下的性能，受限于 IIS 需要通過 ISAPI 形式調用 PHP，所以性能不如 Linux 下 Apache 直接通過 PHP 模塊解釋 PHP，更不如 Nginx 與 PHP-FPM 的性能，既然使用了獨立服務器，操作系統也可以自己確定，Linux 系統我們選用了熟悉的 Ubuntu Linux Server 10.04(一年前還沒有 12.04)，^-^。

Web 服務器采用 Nginx，而不使用 Apache

選用 Nginx 而不用 Apache 的原因非常直接和干脆，因為站點里有很多靜態的附件文件，在處理靜態內容上，Nginx 性能是 Apache 的差不多 10 倍。

在 PHP 解釋和偽靜態規則方面，Apache 要比 Nginx 強，但這不影響我們放棄它，為緩解這一點，我們在后面對 PHP 進行了動態緩存。

對 PHP 查詢進行動態緩存，使用 eAccelerator 這個加速器

PHP 加速器是一個為了提高 PHP 執行效率，從而緩存起 PHP 的操作碼，這樣 PHP 后面執行就不用解析轉換了，可以直接調用 PHP 操作碼，這樣速度上就提高了不少。

eAccelerator 是一個開源 PHP 加速器，優化和動態內容緩存，提高了 PHP 腳本的緩存性能，使得 PHP 腳本在編譯的狀態下，對服務器的開銷幾乎完全消除。 它還有對腳本起優化作用，以加快其執行效率。使得的 PHP 程序代碼執效率能提高 1-10 倍，這個加速還是非常明顯的。

具體地，我們計劃對 eAccelerator 進行以下設置優化：

緩存使用物理內存來進行，不使用磁盤來緩存。我們知道內存的讀寫性能是硬盤的 N 倍，所以在內存資源可以安排情況下，強烈建議使用內存來保存 eAccelerator 的緩存內容。

緩存大小設置為 32MB，這個值是操作系統默認支持最大的緩存容量。雖然可以通過修改配置文件來加大這個值，但我們覺得沒有必要，所以就放棄了。

Nginx 性能優化

選用了 Nginx，雖然它的性能很好，但我們仍然需要對它進行性能優化，在這個案例中，我們做了以下優化：

使用 8 個進程，每個進程大約需要 20M 內存消耗，這里一共使用了 150M 左右的內存。

充分使用主服務器的 CPU 內核：四核，使用 CPU 粘性配置選項(worker_cpu_affinity)，每核處理器分配兩個進程。

開啟 gzip 壓縮功能：gzip 壓縮對 JS, CSS, XML 壓縮效果非常好，能壓縮一半，即減少一倍的傳輸時間;對圖片文件，JPG 已經壓縮過的，它的壓縮性能要少一些。

圖片本地緩存 1 天：網站上的圖片很多，通常一張圖片上傳后，不會頻繁的修改，只會頻繁的訪問，所以將圖片放在 Nginx 緩存里，可以減少服務器訪問加載次數，提升訪問速度。

JS、CSS 文件本地緩存 7 天：這兩種網頁文件，平時都不會去修改它，將它緩存起來，可以減少加載次數，提升訪問速度。為什么這兩種文件不和圖片一起設置緩存有效期，是考慮了不同文件的修改頻率不一樣。

Nginx 日志每天切割一次：這個優化項能大大減小 Nginx 日志文件的大小，經過一周的查看，每天的日志文件是 50M 左右，如果不是每天切割，用月切割，那一個月的日志文件就是幾個 G，要 Web 服務器在內存里加載這么大的文件，系統本身內存不夠用，就自然會用到磁盤來緩存，這就影響性能。每天 50M 左右，在內存上完全可以順利加載，這樣 Nginx 在處理訪問時，可以快速的保存訪問日志。

經過上述幾個優化項目，Nginx 這邊一共需要占用 200M 左右內存資源。

對 PHP CGI 進程性能進行優化

Nginx 沒有 PHP 模塊，所以它對 PHP 的支持是通過 PHP-FPM 來實現的，PHP-FPM 是跑進程來處理并發請求，在這個案例中，我們配置了 20 個進程，每個進程差不多占用 20M 左右內存資源，一共是 400M 左右。

同時，PHP-FPM 與 Nginx 交互機制，選用 Linux Socket 模式而不是 TCP 協議端口，Socks 是系統級處理模式，socks 也就是一個文件連接，而 TCP 協議端口，需要經過網絡協議處理，性能不如前者，所以我們選擇了前者。

MySQL 數據庫性能優化

因為網站主程序是選用他人開發的開源程序，所以對數據庫查詢的程序優化我們無法處理，只能從 MySQL 本身尋找突破口。

我們可以想像一下，對于論壇網站，通常看貼、查貼的訪問量要遠大于創建貼子、回復貼子的訪問量，體現在 MySQL 數據庫上，就是讀表與查詢表數據的連接處理更多。

因此我們要選擇對讀表、查詢性能更好的存儲引擎，結合以前了解的知識，MySQL 缺省的 MyISAM 引擎就是被設計為適合處理讀頻率遠大于寫頻率的環境，查詢效率相當可觀，而且內存占用很少，這也與我們租用低內存配置的 VPS 相符。

具體到 MySQL 配置參數的優化上，受限于服務器上內存資源本身有限，就直接采用缺省的中型環境配置文件。

內容分發網絡應用

站點每天十多萬的訪問，上萬獨立 IP 訪問，查看先前的訪問統計，訪問來自國內各個地區，使用多種網絡連接訪問進來，為保證來自各網絡的用戶訪問速度，同時也減少對網站服務器的請求，我們采用了 CDN 來分發靜態內容，這樣各地的用戶可以就近訪問到已緩存在 CDN 上的文件，CDN 服務商會在靜態內容第一次訪問時緩存到他們全國各地的服務器上，當第二次訪問時，用戶實際是沒有連接到網站服務器上獲取文件的，而是直接從 CDN 服務器上獲取，可以明顯的提升網站性能。