PAAS平臺的web應用性能測試與分析

引言

爲何我會寫這一篇博客，由於最近不少京東雲擎jae的用戶反應一個問題就是他們部署在jae上面的應用訪問很慢，有極少數應用甚至常常出現504超時現象，固然你們首先想到的是jae性能太差，這也是人之常情，每每出現什麼錯誤的時候首先想到是別人的很差，工做中不少同事也是這樣，若是軟件系統出現一個bug首先懷疑的確定不是本身寫的代碼。今天花時間寫這一篇博客主要就是告訴你們怎樣肯定咱們部署在PAAS平臺（不只僅是JAE哦）web應用爲何慢？慢在哪兒了？有什麼方法能夠解決？

 

緣由分析
出現訪問本身web應用慢從宏觀上能夠總結爲下面三點：
（1）網絡慢：具體來講就是訪問者同部署web應用的PAAS平臺之間的網絡慢;
（2）PAAS平臺性能出現問題：具體來講就是因爲各類緣由致使PAAS平臺不能很好服務部署在它上面的應用;
（3）web應用自己慢：因爲各類緣由（頻繁讀寫磁盤，大量耗時的計算，資源競爭等）致使web應用不能很快的響應訪問者的請求。

上面三點主要總結於web應用的訪問路徑，由於訪問PAAS平臺的web應用首先須要通過網絡，而後通過PAAS平臺的過濾和轉發等處理，最後纔到達web應用自己處理。這三個環節任何一個出現問題都會致使web應用訪問變慢。知道緣由了，咱們還須要判斷究竟是哪個環節出現了問題，下面就說說怎樣定位具體的環節。

 

定位具體緣由
上面分析的三個緣由除了第二個緣由之外，你們均可以本身定位和排除，首先檢查網絡，爲了更加準確咱們能夠從一下方面進行排除：
（1）首先檢查訪問其餘網站是否出現很慢的現象，若是很快，那麼說明你的網絡確定大致上是正常的;
（2）訪問對應PAAS平臺提供的相關網站和PAAS平臺所屬公司的網站，例如JAE，你能夠訪問京東商城主站和京東雲平臺首頁等，BAE能夠訪問百度相關網站，SAE能夠訪問新浪相關網站，由於這些關聯網站通常部署在同一個機房或者同一個城市，若是這些網站也很慢，那多半說明這些網站相關機房網絡出現問題或者訪問量很大，致使這些網站對外出口流量和訪問速度變慢，也就是對外提供服務的能力扛不住了，若是沒有問題，那麼能夠排除大的網絡環境是沒有問題的;

排除了網絡因素，咱們就能夠排除後面兩個緣由了，因爲PAAS平臺的性能對用戶基本上是透明的，就是用戶基本上無從得知，因此能夠直接跳過這個緣由的排除，固然實際上是有手段的，只是稍微複雜，因此不方便全部用戶，若是是這種緣由最好仍是交給PAAS平臺的開發人員去處理。

最後一個緣由固然就是web應用自身的實現了，我發現不少用戶反饋的網站訪問慢的緣由都是因爲本身代碼實現的問題。
首先出現問題的網站大多數是有必定訪問量的，特別是某一個時間段出現訪問量巨大，並且頻繁讀寫磁盤。爲了定位這種緣由但願你們把應用部署在本身本地使用web性能測試工具作驗證便可，例如比較經常使用的web性能測試工具ab，這個事apache自帶的測試工具，ubuntu下安裝和使用都很是方便，例如咱們直接在控制檯中輸入ab，若是沒有安裝，ubuntu系統會以下提示：
The program 'ab' is currently not installed.  You can install it by typing:
sudo apt-get install apache2-utils
而後安裝提示安裝便可，安裝成功之後咱們就可使用ab軟件對咱們部署在本地的web應用進行性能測試評估了，命令以下：
ab -n1000 -c10 http://localhost/
上面命令的意思是總共發送1000次請求，每次10各併發請求，訪問的路徑就是本地web服務器的根路徑，結果以下：
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        Apache/2.4.6
Server Hostname:        localhost
Server Port:            80

Document Path:          /
Document Length:        177 bytes

Concurrency Level:      10
Time taken for tests:   0.075 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      446000 bytes
HTML transferred:       177000 bytes
Requests per second:    13283.74 [#/sec] (mean)
Time per request:       0.753 [ms] (mean)
Time per request:       0.075 [ms] (mean, across all concurrent requests)
Transfer rate:          5785.69 [Kbytes/sec] received

Connection Times (ms)
             min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       1
Processing:     0    1   0.2      0       2
Waiting:        0    0   0.2      0       2
Total:          0    1   0.1      1       2
ERROR: The median and mean for the processing time are more than twice the standard
      deviation apart. These results are NOT reliable.

Percentage of the requests served within a certain time (ms)
 50%      1
 66%      1
 75%      1
 80%      1
 90%      1
 95%      1
 98%      1
 99%      1
100%      2 (longest request)
上面具體每一項代碼什麼意義能夠網上查找，這裏咱們主要關心一下以下這個選項：
Requests per second，從結果看這個值是13283.74 [#/sec] (mean)，表示每一秒鐘能夠處理13283.74各請求，由於我這個很簡單的一個靜態頁面（就是apache服務器安裝後默認的首頁），因此看起很不錯，並且是經過本地localhost，沒有通過網絡。咱們能夠改變訪問的條件持續作不少組測試，例如我把併發請求數改成100,即-c100,獲得參數值爲：
Requests per second:    11843.29 [#/sec] (mean)
明顯比上面減小了一些，繼續改總請求數爲10000,併發數1000,即-n10000 -c1000獲得以下值：
Requests per second:    747.98 [#/sec] (mean)
這個時候減小的至關的可怕了，因此經過這個ab測試工具就可以知道咱們的web應用可以承擔多少的併發訪問，固然咱們能夠經過不斷的挑戰參數進行測試，而後繪製成一個曲線圖觀察就很方便看出咱們web應用的最佳性能點，超過那麼最佳性能點可能就致使性能降低，那麼訪問速度也就跟着降低了。
固然只看上面一個參數看不出具體一個用戶訪問所須要等待的時間，另外一個參數能夠看出，我對應三次的測試這個參數值分別以下：
Time per request:       0.753 [ms] (mean)
Time per request:       8.444 [ms] (mean)
Time per request:       1336.942 [ms] (mean)

從三次測試能夠看出，隨着併發數的增加，一個用戶平均等待的時間也在變長，這個最終就反應到用戶web訪問的結果（速度的快慢），這裏測試的只是一個簡單的靜態網頁，若是是複雜的動態網頁（例如訪問數據庫，讀寫磁盤和大量的計算等）那麼就更加複雜了，一個請求的快慢因爲web應用須要處理的業務邏輯有很大的關係，固然怎樣讓這些業務邏輯執行更快而且並行執行，這個就須要程序實現者考慮了。

 

總結
這裏只是簡單介紹了部署在PAAS平臺web應用訪問很慢的可能緣由和簡單定位方法，起始我以爲你們應該中的關注在第三點上，自身應用的優化，由於前面兩點都是咱們不可控的，網絡這個PAAS平臺自身也解決不了，最多能夠部署多個機房多個寬帶運營商和cdn處理等，可是用戶自身的網絡問題PAAS平臺也是解決不了的。至於PAAS平臺自身的緣由，你們就更不用擔憂了，他們比大家更關係自身PAAS平臺的性能，由於上面託管着成千上萬的web應用，他們時時刻刻都在關係着自身平臺的性能拼勁，想着各類方法優化。若是PAAS平臺的緣由致使用戶部署的web應用訪問很慢甚至不可用那麼這個PAAS平臺自身也作不下去的。
最後還想強調一點就是web應用自身的性能優化問題，如今各類語言都提供了很好的開發框架，理論上都是穩定的而且性能是不錯的，固然特殊場景須要特殊考慮。可是咱們自身在設計web應用的時候可能須要考慮的更多，不要妄想一個簡單的開發框架就能解決全部的問題，尤爲是性能問題。設計到web應用優化的知識和技術很是的多也很是的複雜，還有不少場景，因此這是各長久的過程。後面有機會也會給你們介紹一些web性能優化的方法和技術，而且結合實際場景進行分析和演練。