附注：
Asyn表示异步模式，syn表示同步。Asyn中还分成resume和complete两种方式，后续在介绍技术背景的时候详细描述。
对于服务端的load不是每一个测试都做了记录，选取了最全面的1500并发用户做了测试。
最大服务请求处理数是通过应用自身实现，具体代码可以参考后面的代码附件。
测试结果如下：
场景1：500 并发用户场景下，后端服务一次请求消耗3秒钟
这个场景测试的目的是比较在线程池资源足够的时候，异步和同步的差别。（也就是TOP服务器所有的资源处于正常服务，前台请求没有因为前段连接被消耗完，导致服务质量降低）
可以看到，在TPS和Response Time上两者基本上没有太大差别，TPS就等于500/3=167左右（3秒一个请求，因此用这种简单算式可以算出），响应时间也较为正常。当时我发现在每秒吞吐量上有些差别，后来单个测试case跑了一下，发现是返回的http header比较大，应该是在做异步化时重入等作的一些标识（后面其他容器的异步化也是一样）。
最大处理请求数都在服务端后台看到是500，等同于最大的并发用户数。
场景2：1000 并发用户场景下，后端服务一次请求消耗3秒钟
场景2就在资源不足的情况下，比较异步服务请求与同步请求处理能力。（例如由于后端某些服务比较慢，导致前段的服务器能够承载的请求数目超过了线程数）
这个场景的结果可以看到TPS在异步模式下与并发用户数呈现同步增长，就好比配置了1000个线程作为线程池一样，同样在后端打出的最大请求数上也证明了这一点，因此前段线程池的服务能力在异步的情况下充分复用（当然这里使用的异步服务处理使用的是NIO而不是BIO的Connector）。同样在吞吐量上依然是增加的，由于异步附加的内容。
场景3：1500 并发用户场景下，后端服务一次请求消耗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. 异步请求在提高处理能力的情况下，对于资源消耗也较大（线程切换较为频繁），不过还是在承受范围。
三个场景组合比较：
最后将三个场景合并起来做一个简单的比较，得到信息如下：
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. 代码迁移成本。
