瓶頸是什麼？
一條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應用的效能優化思路 找到瓶頸
瓶頸是什麼？一條4車道的公路，執行非常順暢，突然出了點事故，事故車導致某個地方只剩下1車道，然後就開始堵車，因為四輛車同時塞向乙個車道裡。把這個事故清除了，故障車拖走了，道路會開始恢復了通暢。這個道理誰都懂，但偏偏有些傻瓜交警去把4車道變成8車道，但卻不清理事故路段。乙個web應用，不管是何種語言開...
Web應用效能優化思路
瓶頸是什麼？一條4車道的公路，執行非常順暢，突然出了點事故，事故車導致某個地方只剩下1車道，然後就開始堵車，因為四輛車同時塞向乙個車道裡。把這個事故清除了，故障車拖走了，道路會開始恢復了通暢。這個道理誰都懂，但偏偏有些傻瓜交警去把4車道變成8車道，但卻不清理事故路段。乙個web應用，不管是何種語言開...
優化Web中的效能
web的優化就是一場阻止http請求最終訪問到資料庫的戰爭。優化的方式就是加快取，在各個節點加快取。熟悉流程及節點，才能定位效能的問題。而且優化的順序一般也是按請求的流程逐一優化。這裡的流程只是做個概要，並不代表全面。整個流程是以最快的方式讓使用者看到結果 思路是 把看不見的http，具體化 視覺化...