優化Web網站性能

1、前端優化

網站性能優化是一個很綜合的話題，涉及到服務器的配置和網站先後端程序等各個方面，我只是從實際經歷出發，分享一下本身所嘗試過的網站性能優化方法。之因此在標題上掛一個web2.0，是由於本文更偏重於中小網站的性能優化，我所使用的系統也是典型web2.0的LAMP架構。

首先講講前端的優化，用戶訪問網頁的等待時間，有80%是發生在瀏覽器前端，特別是頁面和頁面中各類元素（圖片、CSS、Javascript、 flash…）的下載之上。所以在不少狀況下，相對於把大量的時間花在艱苦而繁雜的程序改進上，前端的優化每每能起到事半功倍的做用。雅虎最近將內部使用的性能測試工具yslow向第三方公開，併發布了著名的網站性能優化的十三條規則，建議你下載並安裝yslow，並做爲測評網站優化效果的工具。下面我挑其中特別有價值的具體說明一下優化的方法：

對於第一次訪問您網站，還沒有在瀏覽器cache中緩存您網站內容的用戶，咱們能夠作的事情包括：

1）減小一個頁面訪問所產生的http鏈接次數
對於第一次訪問你網站的用戶，頁面所產生的http鏈接次數是影響性能的一個關鍵瓶頸。

對策：
- 儘可能簡潔的頁面設計，最大程度減小圖片的使用，經過放棄一些沒必要要的頁面特效來減小javascript的使用。
- 使用一些優化技巧，好比利用圖片的背景位移減小圖片的個數；image map技術；使用Inline images將css圖片捆綁到網頁中。
- 儘可能合併js和css文件，減小獨立文件個數。

2) 使用gzip壓縮網頁內容
使用gzip來壓縮網頁中的靜態內容，可以顯著減小用戶訪問網頁時的等待時間（聽說可達到60%）。主流的web服務器都支持或提供gzip壓縮，若是使用apache服務器，只須要在配置文件中開啓 mod_gzip（apache1.x）或mod_deflate(apache2.x)便可。凡是靜態的頁面，使用gzip壓縮都可以顯著提升服務器效率並減小帶寬支出，注意圖片內容自己已是壓縮格式了，務必不要再進行壓縮。

3）將CSS放在頁面頂端，JS文件放在頁面底端
CSS的引用要放在html的頭部header中，JS文件引用盡可能放在頁面底端標籤的後面，主要的思路是讓核心的頁面內容儘早顯示出來。不過要注意，一些大量使用js的頁面，可能有一些js文件放在底端會引發一些難以預料的問題，根據實際狀況適當運用便可。

4）使JS文件內容最小化
具體來講就是使用一些javascript壓縮工具對js腳本進行壓縮，去除其中的空白字符、註釋，最小化變量名等。在使用gzip壓縮的基礎上，對js內容的壓縮可以將性能再提升5%。

5）儘可能減小外部腳本的使用，減小DNS查詢時間
不要在網頁中引用太多的外部腳本，首先，一次dns的解析過程會消耗20-120毫秒的時間；其次，若是在頁面中引用太多的外部文件（如各類廣告、聯盟等代碼），可能會由於外部文件的響應速度而將你的網站拖得很慢。若是不得不用，那麼就儘可能將這些腳本放在頁腳吧。不過有一點須要說起，就是瀏覽器通常只能並行處理同一域名下的兩個請求，而對於不一樣子的域名則不受此限制，所以適當將本站靜態內容（css,js）放在其餘的子域名下（如 static.xxx.com）會有利於提升瀏覽器並行下載網頁內容的能力。

對於您網站的常常性訪問用戶，主要的優化思路就是最大限度利用用戶瀏覽器的cache來減小服務器的開銷。

1）在header中添加過時時間(Expires Header)
在header中給靜態內容添加一個較長的過時時間，這樣可使用戶從此訪問只讀取緩存中的文件，而不會與服務器產生任何的交互。不過這樣作也存在一些問題，當圖片、CSS和js文件更新時，用戶若是不刷新瀏覽器，就沒法得到此更新。這樣，咱們在對圖片、css和js文件修改時，必需要進行重命名，才能保證用戶訪問到最新的內容。這可能會給開發形成不小的麻煩，由於這些文件可能被站點中的許多文件所引用。flickr提出的解決辦法是經過url rewrite使不一樣版本號的URL事實上指向同一個文件，這是一個聰明的辦法，由於url級別的操做效率是很高的，能夠給開發過程提供很多便利。

要理解爲何這樣作，必需要了解瀏覽器訪問url時的工做機制：
a. 第一次訪問url時，用戶從服務器段獲取頁面內容，並把相關的文件（images,css,js…）放在高速緩存中，也會把文件頭中的expired time,last modified, ETags等相關信息也一同保留下來。
b. 用戶重複訪問url時，瀏覽器首先看高速緩存中是否有本站同名的文件，若是有，則檢查文件的過時時間；若是還沒有過時，則直接從緩存中讀取文件，再也不訪問服務器。
c. 若是緩存中文件的過時時間不存在或已超出，則瀏覽器會訪問服務器獲取文件的頭信息，檢查last modifed和ETags等信息，若是發現本地緩存中的文件在上次訪問後沒被修改，則使用本地緩存中的文件；若是修改過，則從服務器上獲取最新版本。

個人經驗，若是可能，儘可能遵循此原則給靜態文件添加過時時間，這樣能夠大幅度減小用戶對服務器資源的重複訪問。

2）將css和js文件放在獨立外部文件中引用
將css和js文件放在獨立文件中，這樣它們會被單獨緩存起來，在訪問其餘頁面時能夠從瀏覽器的高速緩存中直接讀取。一些網站的首頁多是例外的，這些首頁的自身瀏覽可能並不大，但倒是用戶訪問網站的第一印象以及導向到其餘頁面的起點，也可能這些頁面自己使用了大量的ajax局部刷新及技術，這時能夠將 css和js文件直接寫在頁面中。

3）去掉重複的腳本
在IE中，包含重複的js腳本會致使瀏覽器的緩存不被使用，仔細檢查一下你的程序，去掉重複引用的腳本應該不是一件很難的事情。

4）避免重定向的發生
除了在header中人爲的重定向以外，網頁重定向常在不經意間發生，被重定向的內容將不會使用瀏覽器的緩存。好比用戶在訪問www.xxx.com，服務器會經過301轉向到www.xxx.com/，在後面加了一個「/」。若是服務器的配置很差，這也會給服務器帶來額外的負擔。經過配置apache的 alias或使用mod_rewrite模塊等方法，能夠避免沒必要要的重定向。

還有一些，好比使用CDN分發機制、避免CSS表達式等、避免使用ETags等，由於不太經常使用，這裏就再也不贅述了。

作完了上述的優化，能夠試着用yslow測試一下網頁的性能評分，通常均可以達到70分以上了。

固然，除了瀏覽器前端和靜態內容的優化以外，還有針對程序腳本、服務器、數據庫、負載的優化，這些更深層次的優化方法對技術有更高的要求。本文的後半部分將重點探討後端的優化。

2、後端優化

上次寫完web2.0網站前端優化篇以後，一直想寫寫後端優化的方法，今天終於有時間將思路整理了出來。

前端優化能夠避免咱們形成無謂的服務器和帶寬資源浪費，但隨着網站訪問量的增長，僅靠前端優化已經不能解決全部問題了，後端軟件處理並行請求的能力、程序運 行的效率、硬件性能以及系統的可擴展性，將成爲影響網站性能和穩定的關鍵瓶頸所在。優化系統和程序的性能能夠從如下的方面來入手：

1）apache、mysql等軟件的配置的優化
儘管apache和mysql等軟件在安裝後使用的默認設置足以使你的網站運行起來，可是經過調整mysql和apache的一些系統參數，仍是能夠追求更高的效率和穩定性。這個領域中有不少專業的文章和論壇（好比： http://www.mysqlperformanceblog.com/），要想掌握也須要進行深刻的研究和實踐，這裏就不重點討論了。

2）應用程序環境加速
這裏僅以我最常應用的php開發環境爲例，有一些工具軟件能夠經過優化PHP運行環境來達到提速的目的，其基本原理大體是將PHP代碼預編譯並緩存起來，而不須要改變任何代碼，因此比較簡單，能夠將php的運行效率提高50%以上。比較經常使用的免費php加速工具備：APC( http: //pecl.php.net/package-info.php?package=APC)、Turck MMCache（ http://turck-mmcache.sourceforge.net）、php accelebrator(www.php-accelerator.co.uk)，還有收費的Zend Performance Suite

3）將靜態內容和動態內容分開處理
apache是一個功能完善但比較龐大的web server，它的資源佔用基本上和同時運行的進程數呈正比，對服務器內存的消耗比較大，處理並行任務的效率也通常。在一些狀況下，咱們能夠用比較輕量級的web server來host靜態的圖片、樣式表和javascript文件，這樣能夠大大提高靜態文件的處理速度，還能夠減小對內存佔用。我使用的web server是來自俄羅斯的nginx，其餘選擇方案還包括lighttpd和thttpd等。

4）基於反向代理的前端訪問負載均衡
當一臺前端服務器不足以應付用戶訪問時，經過前端機實現web訪問的負載均衡是最快速可行的方案。經過apache的mod_proxy能夠實現基於反向代理的負載均衡，這裏推薦使用nginx作代理服務器，處理速度較apache更快一些。

5）應用緩存技術提升數據庫效能，文件緩存和分佈式緩存
數據庫訪問處理併發訪問的能力是不少網站應用的關鍵瓶頸，在想到使用主從結構和多farm的方式構建服務器集羣以前，首先應該確保充分使用了數據庫查詢的緩存。一些數據庫類型（如mysql的innoDB）自身內置對緩存的支持，此外，還能夠利用程序方法將經常使用的查詢經過文件或內存緩存起來。好比經過 php中的ob_start和文件讀寫函數能夠很方便的實現文件形式的緩存，而若是你擁有多臺服務器，能夠經過memcache技術經過分佈式共享內存來對數據庫查詢進行緩存，不只效率高並且擴展性好，memcache技術在livejournal和Craigslist.org等知名網站應用中都獲得了檢驗。

6）服務器運行狀態的檢測，找到影響性能的瓶頸所在
系統優化沒有一勞永逸的方法，須要經過檢測服務器的運行狀態來及時發現影響性能的瓶頸，以及可能存在的潛在問題，由於網站的性能，永遠取決於木桶中的短板。能夠編寫一些腳原本檢測web服務的運行，也有一些開源的軟件也提供了很好的功能

7）良好的擴展架構是穩定和性能的基礎
一些技巧和竅門能夠幫你度過眼前的難關，但要想使網站具有應付大規模訪問的能力，則須要從系統架構上進行完全的規劃，好在不少前人無私的把他們架構
網站的經驗分享給咱們，使咱們能夠少走甚多彎路。我最近讀到的兩篇有啓發的文章：
- 從LiveJournal後臺發展看大規模網站性能優化方法 
- Myspace的六次重構

最後不得不提到程序編碼和數據庫結構對性能的影響，一系列糟糕的循環語句，一個不合理的查詢語句、一張設計不佳的數據表或索引表，都足以會使應用程序運行的速度成倍的下降。培養全局思考的能力，養成良好的編程習慣，並對數據庫運行機制有所瞭解，是提升編程質量的基礎。