Author：放翁（文初）
Date: 2010/4/14
Email:[email protected]
围脖 : 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配置如下：
<IfModulempm_worker_module>
ServerLimit 80
ThreadLimit 128
StartServers 10
MaxClients 10240
MinSpareThreads 64
MaxSpareThreads 800
ThreadsPerChild 128
MaxRequestsPerChild10000
</IfModule>
Jboss的 web容器配置如下：
<Connector port="8009" address="${jboss.bind.address}" connectionTimeout="8000" protocol="AJP/1.3" maxThreads="500" minSpareThreads="40" maxSpareThreads="75" maxPostSize="512000" acceptCount="300" bufferSize="16384" emptySessionPath="false" enableLookups="false" redirectPort="8443" URIEncoding="utf-8"/>
Jboss的 web部分以 APR模式启动。
2. Tomcat6（ APR）
关键配置如下：
<Executor name="topThreadPool" namePrefix="top-exec-"
maxThreads="500" minSpareThreads="40"/>
<Connector port="7777" protocol="HTTP/1.1"
executor="topThreadPool" connectionTimeout="20000" acceptCount="1000"
redirectPort="8444" />
3. Tomcat7 RC 4（ APR）
关键配置如下：
<Executor name="topThreadPool" namePrefix="top-exec-"
maxThreads="500" minSpareThreads="4"/>
<Connector executor="topThreadPool" port="3333" protocol="HTTP/1.1"
connectionTimeout="20000" acceptCount="1000"
redirectPort="6443" />
4. Jetty7
关键配置如下：
<Set name="ThreadPool">
<!-- Default queued blocking threadpool -->
<New class="org.eclipse.jetty.util.thread.QueuedThreadPool">
<Set name="minThreads">10</Set>
<Set name="maxThreads">500</Set>
</Set>
<Call name="addConnector">
<Arg>
<New class="org.eclipse.jetty.server.nio.SelectChannelConnector">
<Set name="host"><SystemProperty name="jetty.host" /></Set>
<Set name="port"><SystemProperty name="jetty.port" default="6060"/></Set>
<Set name="maxIdleTime">300000</Set>
<Set name="Acceptors">2</Set>
<Set name="statsOn">false</Set>
<Set name="confidentialPort">8443</Set>
<Set name="lowResourcesConnections">20000</Set>
<Set name="lowResourcesMaxIdleTime">5000</Set>
</New>
</Arg>
</Call>
附注：
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就在资源不足的情况下，比较异步服务请求与同步请求处理能力。（例如由于后端某些服务比较慢，导致前段的服务器能够承载的请求数目超过了线程数）
这个场景的结果可以看到 TPS在异步模式下与并发用户数呈现同步增长，就好比配置了 1000个线程作为线程池一样，同样在后端打出的最大请求数上也证明了这一点，因此前段线程池的服务能力在异步的情况下充分复用（当然这里使用的异步服务处理使用的是 NIO而不是 BIO的 Connector）。同样在吞吐量上依然是增加的，由于异步附加的内容。
场景 3： 1500 并发用户场景下，后端服务一次请求消耗 3秒钟
| 容器 |
模式 |
TPS |
Average Response Time(s) |
Average Throughput(byte/s) |
Server Load |
Success rate |
| Jboss |
syn |
75.546 |
5.347 |
21002 |
0.115 |
68% |
| Jetty7 |
Syn |
163.156 |
8.788 |
19252 |
0.129 |
100% |
| Jetty7 |
Asyn(complete) |
432.153 |
3.312 |
76491 |
2.649 |
100% |
| Jetty7 |
Asyn(resume) |
423.638 |
3.375 |
99979 |
2.826 |
100% |
| Tomcat6 |
Syn |
163.836 |
8.75 |
18513 |
0.258 |
100% |
| Tomcat7 |
ASyn |
423.501 |
3.328 |
54632 |
1.064 |
99.3% |
场景三比对了现有 TOP的部署模式（ Apache + modjk + Jboss）和 Jetty7的同步模式，两种异步模式， Tomcat同步模式， Tomcat的 servlet3.0异步模式的处理情况。根据测试可以得到的信息如下：
1. 现有部署方式在后端服务处理耗时较大的情况下，处理能力不如 Jetty7和 Tomcat6，同时出错率很高。
2. Jetty7的同步处理测试结果和 Tomcat6的同步处理测试结果很类似，但是 load方面 jetty7更好。
3. 异步处理方面 Jetty7的两种方式基本上差别不大（后续还需要深入源码看看对于数据缓存资源复用的状况）， Tomcat7的异步处理成功率有些问题（错误多半是在获取 response回写的时候， response已经被提前释放，看来 Tomcat7还是需要一些时间来考验）， load上来说 tomcat结果比较好。
4. 异步请求在提高处理能力的情况下，对于资源消耗也较大（线程切换较为频繁），不过还是在承受范围。
三个场景组合比较：
| 容器 |
并发用户 |
模式 |
TPS |
Average Response Time(s) |
Average Throughput(byte/s) |
Success rate |
| Jetty7 |
500 |
asyn(resume) |
162.8 |
3.008 |
38430 |
100% |
| Jetty7 |
1000 |
asyn(resume) |
317.06 |
3.036 |
74826 |
100% |
| Jetty7 |
1500 |
asyn(resume) |
423.638 |
3.375 |
99979 |
100% |
| Tomcat6 |
500 |
syn |
163.3 |
3.005 |
18453 |
100% |
| Tomcat6 |
1000 |
syn |
163.323 |
5.904 |
18455 |
100% |
| Tomcat6 |
1500 |
Syn |
163.836 |
8.75 |
18513 |
100% |
最后将三个场景合并起来做一个简单的比较，得到信息如下：
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. 代码迁移成本。
后续篇涉及：服务异步化的概念，服务异步化的几种标准实现，服务异步化容器的特点和实现，现有容器可优化的点。