瓶頸是什麼？
一條4車道的公路，執行非常順暢，突然出了點事故，事故車導致某個地方只剩下1車道，然後就開始堵車，因為四輛車同時塞向乙個車道裡。把這個事故清除了，故障車拖走了，道路會開始恢復了通暢。
這個道理誰都懂，但偏偏有些傻瓜交警去把4車道變成8車道，但卻不清理事故路段。
乙個web應用，不管是何種語言開發，粗略的結構無非是三層：
1. 頁面模板
可以是jsp、asp、php等頁面技術，根據資料生成最終的html頁面，
css樣式檔案，js指令碼語言，
效能關鍵指標只有乙個，頁面的渲染速度。綜合各種頁面技術而言，渲染速度相差不會太大，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**優化三部曲：應用程式優化、系統結構優化、網路優化。
Android應用效能優化
記憶體,ui,電量 1.記憶體 首先簡單介紹一下android系統記憶體管理機制.記憶體共享 預設情況 string vmheapsize systemproperties.get dalvik.vm.heapsize 16m 只有16m.可以通過在device.mk檔案中設定 product pr...
Android應用效能優化
1 anr 2 listview 卡頓，不流暢 3 activity啟動慢 4 動畫不流暢，啟動前卡頓 5 自定義view啟動慢 6 oom 7 資料庫大量操作 8 長時間執行後，程式變慢 1 語言層解決問題，語法上提高效能 2 合理的資料結構和演算法 3 布局優化，布局深度控制 4 工作執行緒與u...
Mysql單機應用效能優化
簡單概括。客戶端通過scoket連線與mysql建立連線。然後就可以執行select insert update delete來讀寫資料，由執行引擎來處理。執行引擎首先記錄日誌 undo,redo 寫到日誌記憶體緩衝區中，並在滿足一定條件時flush到磁碟上的日誌檔案中。然後讀 寫資料，也是首先在資...