Web服務請求異步化測試(3)

　　1. 隨著并發用戶的增加，本身異步處理也會有衰減，同時對于性能消耗(線程切換)也會不斷增長。
　　2. 異步化在消息頭上會增加一些數據，會增加回寫的帶寬消耗(不過量不大)，一個請求增加了100byte左右的消息數據。
　　測試總結：
　　1. Web請求異步化在TOP很合適。
　　重復兩個條件：
　　a. 處理耗時大多消耗在于對后端或者外部服務資源的請求上。
　　b. 后端或者外部資源在更多的流量下不會成為瓶頸。
　　2. Web請求異步化在Jetty6到7上已經經歷了2年多的成長(Google App Engine , Yahoo Hadoop)，穩定性和效率較好。(同時很多優化可以通過擴展自行定制，jetty的可擴展性很好)Tomcat7在servlet3上處于剛發布階段，還有待繼續完善。(Servlet3的另一種模式尚未執行成功，直接導致jvm退出)
　　后續需要繼續跟進的：
　　1. 對于大數據量請求的容器間性能對比。(圖片上傳或者大數據量的Post請求)
　　2. 容器安全性。(是否容易被攻擊)
　　3. 代碼遷移成本?！　uthor：放翁(文初)
　　Date: 2010/4/14
　　Email:fangweng@taobao.com
　　圍脖: http://t.sina.com.cn/fangweng
　　這部分是結果，大家可以當看倒序的電影，后續會有前篇給出。
　　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服務器所有的資源處于正常服務，前臺請求沒有因為前段連接被消耗完，導致服務質量降低)

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