Web應用的效能優化思路 找到瓶頸

2021-09-02 03:23:55 字數 1369 閱讀 5482

瓶頸是什麼?

一條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,具體化 視覺化...