引言
為什么我會寫這一篇博客，因為最近很多京東云擎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性能優化的方法和技術，并且結合實際場景進行分析和演練。