Web服務請求異步化測試

　
　　這部分是結果，大家可以當看倒序的電影，后續會有前篇給出。
　　Web服務異步化：
　　包括兩部分，數據傳輸層異步化(大家已經熟知的NIO)，Http業務請求異步化(continuations，servlet3.0)。服務異步處理我將會有一個詳細的說明文檔(服務異步化的概念，服務異步化的幾種標準實現，服務異步化容器的特點)，后續給出。
　　Web服務異步化測試原因：
　　TOP應用特殊性：
　　1.自身服務能力由后端的服務能力決定。(對同步Web請求的轉發)
　　2.后端服務部署等同性，但要求服務互不影響。
　　第一點導致TOP無法預估自身服務能力(不同后端服務處理速度下的TOP有不一樣的支持能力)，同時也無法應對在后端服務異常的情況下，整體的服務質量。
　　第二點導致TOP只有在物理上分隔不同服務提供者所對應的TOP集群(資源浪費，同時無法動態調整資源來滿足服務變化情況)。
　　因此需要對TOP實施web服務異步處理的測試。這里簡單的說一下服務異步化的使用場景需要滿足的幾個特點：
　　1. 處理耗時大多消耗在于對后端或者外部服務資源的請求上。
　　2. 后端或者外部資源在更多的流量下不會成為瓶頸。
　　拿TOP來解釋一下：TOP自身處理主要包括路由，安全，流控等，但是最耗時的是在請求后端各個淘寶團隊的服務。其次當前后端服務能力尚未達到真實的處理高峰，因此很多請求被堵在TOP平臺，特別是當某些服務異常的時候，另一些服務就會被拖累無法得到充分利用。(當然我們有流控，發現后端服務能力已經成為瓶頸的時候可以對單獨服務作限制)。
　　長話短說，上測試結果……
　　環境說明：
　　Linux 2.6.9-55.ELsmp
　　4 Core
　　4 G Memory
　　JDK 1.6.0_07
　　測試工具：loadRunner 9.5
　　測試涉及到了四種容器部署：后面都會用縮寫在測試結果上注明
　　1. Apache + modjk + Jboss(后面縮寫為Jboss)：
　　此模式Apache配置如下：
　　
　　ServerLimit 80
　　ThreadLimit 128
　　StartServers 10
　　MaxClients 10240
　　MinSpareThreads 64
　　MaxSpareThreads 800
　　ThreadsPerChild 128
　　MaxRequestsPerChild 10000
　　
　　Jboss的web容器配置如下：
　　
　　Jboss的web部分以APR模式啟動。
　　2. Tomcat6(APR)
　　關鍵配置如下：
　　
　　maxThreads="500" minSpareThreads="40"/>
　　
　　executor="topThreadPool" connectionTimeout="20000" acceptCount="1000"
　　redirectPort="8444" />
　　3. Tomcat7 RC 4(APR)
　　關鍵配置如下：
　　
　　maxThreads="500" minSpareThreads="4"/>
　　
　　connectionTimeout="20000" acceptCount="1000"
　　redirectPort="6443" />
　　4. Jetty7
　　關鍵配置如下：
　　
　　
　　
　　10
　　500
　　
　　
　　
　　
　　
　　
　　300000
　　2
　　false
　　8443
　　20000
　　5000
　　
　　
　　
　　附注：
　　Asyn表示異步模式，syn表示同步。Asyn中還分成resume和complete兩種方式，后續在介紹技術背景的時候詳細描述。
　　對于服務端的load不是每一個測試都做了記錄，選取了最全面的1500并發用戶做了測試。
　　最大服務請求處理數是通過應用自身實現，具體代碼可以參考后面的代碼附件。
　　測試結果如下：
　　場景1：500 并發用戶場景下，后端服務一次請求消耗3秒鐘

容器	模式	TPS	Average Response Time(s)	Average Throughput(byte/s)	最大請求處理數	Success rate
Jetty7	asyn(resume)	162.8	3.008	38430	500	100%
Tomcat6	syn	163.3	3.005	18453	500	100%

　　這個場景測試的目的是比較在線程池資源足夠的時候，異步和同步的差別。(也就是TOP服務器所有的資源處于正常服務，前臺請求沒有因為前段連接被消耗完，導致服務質量降低)
　　可以看到，在TPS和Response Time上兩者基本上沒有太大差別，TPS就等于500/3=167左右(3秒一個請求，因此用這種簡單算式可以算出)，響應時間也較為正常。當時我發現在每秒吞吐量上有些差別，后來單個測試case跑了一下，發現是返回的http header比較大，應該是在做異步化時重入等作的一些標識(后面其他容器的異步化也是一樣)。
　　最大處理請求數都在服務端后臺看到是500，等同于最大的并發用戶數。
　　場景2：1000 并發用戶場景下，后端服務一次請求消耗3秒鐘

容器	模式	TPS	Average Response Time(s)	Average Throughput(byte/s)	最大請求處理數	Success rate
Jetty7	asyn(resume)	317.06	3.036	74826	1000	100%
Tomcat6	syn	163.323	5.904	18455	500	100%

　　場景2就在資源不足的情況下，比較異步服務請求與同步請求處理能力。(例如由于后端某些服務比較慢，導致前段的服務器能夠承載的請求數目超過了線程數)

原文轉自：http://www.kjueaiud.com