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. 代码迁移成本。　　Author：放翁(文初)
　　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.ltesting.net