瓶頸是什么？

一條4車道的公路，運行非常順暢，突然出了點事故，事故車導致某個地方只剩下1車道，然后就開始堵車，因為四輛車同時塞向一個車道里。把這個事故清除了，故障車拖走了，道路會開始恢復了通暢。

這個道理誰都懂，但偏偏有些傻瓜交警去把4車道變成8車道，但卻不清理事故路段。

一個Web應用，不管是何種語言開發，粗略的結構無非是三層：

1. 頁面模板

可以是jsp、asp、php等頁面技術，根據數據生成最終的HTML頁面，性能關鍵指標只有一個，頁面的渲染速度。綜合各種頁面技術而言，渲染速度相差不會太大，10倍以內。

2. 業務邏輯

用于根據業務需要將數據庫中的數據讀取到內存中，以便通過頁面模板渲染成HTML頁面。這里面可能還包括緩存、連接池等技術。

3. 數據庫

就是數據庫，負責執行SQL查詢并返回查詢結果。

我們假設用戶訪問一個頁面，也就是請求一個URL地址，然后得到內容，所需要的時間是3秒鐘。其中大部分時間可能用在網絡傳輸上，而真正頁面執行并生成HTML內容所需的時間是很小的，這里假設需要100毫秒。

相當于用戶花了兩秒多鐘在傳輸數據上，這部分時間如果能縮減，可以大大提升訪問的速度，但是這部分一般也難以提升了，因為取決于用戶本身的網絡情況，服務器的網絡情況以及中間整個路由的情況。對于一個網站來說，能做的就是盡可能的提升服務器的帶寬，或者使用CDN來減少中間路由環節，很不幸的是，這個成本很高。

好吧，前面提到的更多是非技術因素，假設你已經耗費巨資解決了這個問題，然后突然發現網絡太快了，可是服務器頂不住了，生成一個頁面居然要100毫秒，才幾十個并發用戶就差點要把服務器搞崩潰了。

于是來到了本文的重點部分——找出應用的性能瓶頸。

前面我們提到的結構中的三層：頁面模板，業務邏輯和數據庫，根據經驗值，在這100毫秒中，三個部分占用的時間差不多為：頁面模板(5%)、業務邏輯+數據庫(95%)。

幾個準則：

1. 沒必要去優化頁面模板，這都是一些很成熟的技術，就算你好不容易提升了10%的性能，這10%在整個頁面的執行過程中只占了0.5%的比例，微乎其微，等于是前面例子中的4車道變8車道的傻瓜，我們不要去充當傻瓜。

2. 一般瓶頸所在以及相應處理辦法

簡簡單單的三條，里面卻包含了很深的功夫，特別是在數據庫查詢優化上。

你必須在充分解決了這些應用程序所屬的性能瓶頸之后，再去考慮系統級別的優化。

一些常用系統級別優化包括：

1. 靜態文件和動態頁面分開處理2. 應用服務器的集群3. 數據庫的集群

不要本末倒置，一個性能很差的應用程序，你就算集群了100個節點，也不會有什么效果。

所以Web網站優化三部曲：應用程序優化、