從開發人員到系統工程師、運維工程師以及架構師,經常會收到使用者或需求方的反映,說我們**開啟地很慢,甚至出現了502等。這個問題原因較多,處理方式也較多。我要分享的是乙個弱請求處理的優化方式。
弱請求在這裡是指那些響應較慢、耗時較長的http請求,是筆者臨時命名的。有經驗的工程師都知道,我們要分析系統效能問題時,只需分析這個系統的請求處理容量和單個請求的平均響應時間。有前輩分享的2/8原則,提到我們的系統有20%左右響應較慢的請求占用了超過20%以上的資源。這裡要說的就是對這些請求響應時間的處理方式。
如何獲取系統的單個請求響應時間?
客戶端層面情況較複雜,存在很大的地域差別,可以用httpwatch或者壓力測試軟體進行區別,也可以依靠部署在全國各地的效能監控平台獲取資訊。
伺服器端的方式有:1.配置nginx,apache日誌格式 2.在工程**裡加filter,進行記錄。建議使用第一種方式。
修改nginx配置檔案開啟的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優化(一)
資料在網路上傳輸的時間分成兩部分,一部分是使用者請求的資料報到達伺服器的時間,另一部分是伺服器的回應資料經由網路傳送給客戶端的時間,這兩部分的時間稱為響應時間。響應時間的大小取決於頻寬和資料量的大小。響應時間的其中大部分時間消耗在伺服器端,我們用吞吐率來衡量這部分時間,即每秒處理請求數。吞吐率影響因...