web效能優化（一）弱請求處理

從開發人員到系統工程師、運維工程師以及架構師,經常會收到使用者或需求方的反映,說我們**開啟地很慢，甚至出現了502等。這個問題原因較多，處理方式也較多。我要分享的是乙個弱請求處理的優化方式。

弱請求在這裡是指那些響應較慢、耗時較長的http請求,是筆者臨時命名的。有經驗的工程師都知道，我們要分析系統效能問題時，只需分析這個系統的請求處理容量和單個請求的平均響應時間。有前輩分享的2/8原則，提到我們的系統有20%左右響應較慢的請求占用了超過20%以上的資源。這裡要說的就是對這些請求響應時間的處理方式。

如何獲取系統的單個請求響應時間？

客戶端層面情況較複雜，存在很大的地域差別，可以用httpwatch或者壓力測試軟體進行區別，也可以依靠部署在全國各地的效能監控平台獲取資訊。

伺服器端的方式有：1.配置nginx,apache日誌格式  2.在工程**裡加filter，進行記錄。建議使用第一種方式。

修改nginx配置檔案   

vi /usr/local/nginx/conf/nginx.conf 
找到log_format，在最後新增request_time項，如下 
儲存退出.   
kill -hup pid(nginx的pid) 

tail -fn100 /usr/local/nginx/logs/access.log

紅圈表示請求/msg/replylist/msg/1/1.html的響應時間為0.053秒

太好了，伺服器請求時間記錄下來了。

apache也可以作類似設定，有興趣的朋友可以在google裡搜尋一下就知道了。

然後，讓我們的系統跑動若干時間段。

我們再取出日誌，執行：

cat access.log |awk  '($7~/\.html/)'|sort -nr|head -100 

#意思是列出到客戶端最耗時的前100個請求的html頁面, （可修改，為jsp,php）分別顯示響應時間  ip**  請求發生的時間   請求頁 

說明請求/msg/msgup.html較慢，超過了6秒，太消耗資源了。

經常分析日誌，我們會得到一系列這樣的請求頁面。

找到了妨礙我們系統效能開啟較慢的問題頁面，根據前輩提到的2/8原則，我們可以對這些請求進行處理：

方法一：

分析這個請求對應的程式是不是有很多for迴圈，是不是直接讀庫，快取策略是否還可以優化等等修改程式就ok。

方法二：

利用nginx的正則匹配**，我們把這些弱請求統計轉到其它伺服器處理，起到分流的作用。

實施上述策略之後，我們發現系統負載減輕了，502更少了，頁面開啟的速度更快了。

web效能優化（一）弱請求處理

從開發人員到系統工程師 運維工程師以及架構師,經常會收到使用者或需求方的反映,說我們 開啟地很慢，甚至出現了502等。這個問題原因較多，處理方式也較多。我要分享的是乙個弱請求處理的優化方式。弱請求在這裡是指那些響應較慢 耗時較長的http請求,是筆者臨時命名的。有經驗的工程師都知道，我們要分析系統效...

web效能優化一

web效能優化對於任何大型專案都是必不可少的一環，那麼如何做好web端的效能優化，從哪些方面入手？這些問題猛地提出來會讓很多人有無從下手的感覺，那麼接下來，我結合一些前輩發表的文章並總結下個人的效能優化經驗，系統性的總結從哪些方面入手。首先提出乙個問題 瀏覽器的乙個請求從傳送到返回都經歷了什麼？乙個...

高效能web優化（一）

資料在網路上傳輸的時間分成兩部分，一部分是使用者請求的資料報到達伺服器的時間，另一部分是伺服器的回應資料經由網路傳送給客戶端的時間，這兩部分的時間稱為響應時間。響應時間的大小取決於頻寬和資料量的大小。響應時間的其中大部分時間消耗在伺服器端，我們用吞吐率來衡量這部分時間，即每秒處理請求數。吞吐率影響因...