優化Web中的效能

web的優化就是一場阻止http請求最終訪問到資料庫的戰爭。

優化的方式就是加快取，在各個節點加快取。

熟悉流程及節點，才能定位效能的問題。而且優化的順序一般也是按請求的流程逐一優化。這裡的流程只是做個概要，並不代表全面。

整個流程是以最快的方式讓使用者看到結果

思路是：把看不見的http，具體化、視覺化。

定位是優化的前提。沒有準確的定位就無法有效的解決問題。

看整個請求的時間

看整個頁面載入的時間

看頁面載入的資料大小

看頁面請求數

例如：

定位結果

是後台請求慢

是前端載入慢（document,js,image,request數等）

看整個請求的時間

看sql的時間（這個在資料庫通過慢日誌也可以）

例如：

定位結果

哪些url是慢的

哪些url是最常用的

哪些sql是慢的

通過system.out.print或者打斷點來定位

給每個方式新增乙個aop，監控期執行時間

例如：定位結果

哪乙個方法或者哪一段**效能慢

慢日誌定位結果

哪些sql是慢的。

思路：針對於http請求的節點按順序解決。暫時不考慮從分布式和群集的解決方案入手優化。

加gzip(減少http的請求資料量)

加靜態資源的快取

nginx快取整合url級別的快取

動靜分離

優化迸發協議

新增快取

減少io(減少迴圈的io，通過批量獲取，然後在**級別去處理,優化演算法，把樹狀的複雜度變為平級複雜度)

新增索引

加冗餘資料

修改表結構設計（這個很重要，有的時候是因為表設計不合理導致的，可以通過調整設計來解決）

新增快取

優化的方面不僅限於上面的方法。有些也沒有一一贅述。比如說：加記憶體也是優化的不錯解決方案。還有作業系統級別,io讀寫，網路請求等問題。

優化Web中的效能

web的優化就是一場阻止http請求最終訪問到資料庫的戰爭。優化的方式就是加快取，在各個節點加快取。熟悉流程及節點，才能定位效能的問題。而且優化的順序一般也是按請求的流程逐一優化。這裡的流程只是做個概要，並不代表全面。整個流程是以最快的方式讓使用者看到結果 思路是 把看不見的http，具體化 視覺化...

Web效能優化

我們先來看乙個瀑布圖來確定乙個頁面效能問題是由哪些項造成的。chorome 自帶開發人員工具 圖中每一行表示乙個 請求，每乙個請求都有一條時間線，用於標識這個請求所花費的時間。如果將滑鼠放到某一條時間線上，可以看到以下資訊 1 首先看一下哪個請求花費的時間比較長，看看這個請求的時間線資訊，確定是伺服...

web效能優化

可以用gulp的gulp uglify gulp minify css模組完成 還可以用webpack的uglifyjsplugin壓縮外掛程式完成。通過css sprites將多個整合到乙個中，在用css來定位。伺服器在處理大流量的資料是十分困難的，這最終導致頁面載入速度變慢。cdn是位於全球不同...