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

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

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

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

客戶端層面的較複雜，不同的地區有差別，可以用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也可以作類似設定，有興趣的同學可以在baidu裡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優化（一）

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