web效能優化(一)弱請求處理

2022-08-02 10:24:11 字數 1783 閱讀 2546

從開發人員到系統工程師、運維工程師以及架構師,經常會收到使用者或需求方的反映,說我們**開啟地很慢,甚至出現了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)

開啟的nginx時志檔案  

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優化(一)

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