爲何站點訪問慢？請收好這份 Web 服務器性能提高的總結

優化思路淺析

要優化 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 頁面訪問的影響因素會有這幾個：

1. Web 服務器從磁盤中讀取靜態頁面內容的速度，也即時間；
2. Web 服務器斷定請求內容是靜態仍是動態內容的時間；
3. Web 服務器轉發請求給應用服務器的時間；
4. 應用服務器處理（解釋）動態內容所需的時間；
5. Web 服務器返回 Web 內容給瀏覽器的響應時間；
6. Web 服務器接收來自瀏覽器請求的處理性能；
7. Web 訪問請求數據在網絡上傳輸的時間：包括從瀏覽器到服務器，和從服務器到瀏覽器兩部分；
8. 瀏覽器本地計算和渲染 Web 內容的時間，即接收內容後展示內容的時間。

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

• Web 服務器執行安全策略檢查的時間，或者說性能；
• Web 服務器讀取日誌文件、寫日誌內容、關閉對日誌文件訪問的時間，先讀後寫再關閉，這三步中的讀與寫又涉及到磁盤訪問性能因素；
• 同時與 Web 服務器鏈接會話的客戶端數量大小，即併發訪問量多大。

咱們能夠將上面一共 11 項影響因素抽像出來，那麼就是：

1. Web 服務器磁盤性能；
2. Web 服務器與應用服務器交互的性能；
3. 應用服務器處理動態內容的性能，或者說動態內容應用處理性能；
4. 客戶端與 Web 服務器的鏈接速度，即網絡傳輸性能；
5. Web 瀏覽器解釋和渲染 Web 內容的性能；
6. Web 訪問併發性能。

反映到咱們進行性能優化，能夠入手的角度就有：

1. 增長帶寬，包括服務器和客戶端兩邊的 Internet 鏈接帶寬；
2. 加快動態內容的處理性能；
3. 儘量多地使用靜態內容，這樣 Web 服務器就能夠無需請求應用服務器，直接將 Web 內容發給瀏覽器端，這裏能夠入手的方案又有：

• 動態內容緩存
• 動態內容靜態化

1. 多臺服務器負載均衡同時處理大量的併發訪問；
2. 提高服務器磁盤訪問性能，也即一般所說的 I/O 性能；
3. 減小網頁中的 HTTP 請求數；
4. 更換更好性能的 Web 服務器；
5. 合理部署服務器，在離客戶端更近的地方部署服務器，已經證實能夠明顯地提高訪問性能。

性能優化實踐

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

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

1. 站點簡介

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

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

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

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

另外，虛擬主機的服務器在美國，沒有在國內租用虛擬主機的緣由是國內網站在備案方面很是繁瑣，在網站一開始運營時數據量和訪問量都比較小，因此對性能要求不高，數據量小，因此服務器在查詢處理數據時速度比較快，也讓人感受訪問速度不慢，如今隨着數據量和訪問量的不斷上升，訪問速度已明顯降低，到了須要改善訪問性能的時候了。

基於目前該社區網站的狀況，提出的優化需求是，國內訪問速度須要提高一倍，目前首頁加載時間須要 40 秒左右，但願優化後能在 20 秒之內將首頁加載完成。

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

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

3. 性能優化方案

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

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

虛擬主機受限比較多，沒法本身自定義配置 Web 服務器，沒法配置 PHP 動態緩存，並且獨立服務器能夠獨享內存、處理器資源，再也不受虛擬主機商對每一個虛擬主機用戶的內存和處理器資源佔用限制。處理器資源和內存資源，對接受更多併發訪問有直接性能提高效果。

由 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 服務器上獲取，能夠明顯的提高網站性能。

參考資料

下面推薦介紹幾本有關 Web 性能優化的圖書，能夠找來閱讀，尤爲是《構建高性能WEB站點》這本書，很是值得服務器運維工程師閱讀，它是國內一本面向服務器工程師的性能優化書籍，比較系統地講解了優化思路，且有不少實際操做方面的舉例說明。

_做者：Coagent
連接： http://www.jianshu.com/p/QsGiYD_

最新整理的 2TB 技術乾貨：包括架構師實戰教程、大數據、Docker容器、系統運維、數據庫、redis、MogoDB、電子書、Java基礎課程、Java實戰項目、ELK Stack、機器學習、BAT面試精講視頻等。只需在「 民工哥技術之路」微信公衆號對話框回覆關鍵字：1024便可獲取所有資料。