最近被内部问了太多关于jetty测试的问题了，所以这里先写一点开头，后续再全面的做一下测试，想说的就是测试需要你去关注场景，需要去区分什么是表象和本质。
你的系统是什么系统：（一步一步的做判断）
流入系统 or 流出系统？
流入系统（系统完成请求无外部系统依赖，缓存可以考虑成为非外部依赖）
瓶颈在CPU，带宽，内存（容器连接数，线程数）？
流出系统（系统完成请求有外部系统依赖）
瓶颈在CPU，带宽，内存（容器连接数，线程数） or 第三方系统？
第三方系统：
1． 强依赖，无法降级和后备切换
2． 弱依赖，可降级跳过或后备可切换。（多个服务提供者提供同样的服务）
模型建立：
1． 同样资源情况下处理能力的比较。（不要仅仅去比较线程数，因为你的资源是cpu,memory等等，线程是表象）因此不要简单的认为容器间的平等就是设置线程数的平等，不同容器采用的处理模式是不同的，就好比不要用NIO和BIO去比较他们的线程数一样。这类测试需要关注同等资源这个标准如何建立（load，memory等），同样的资源下再比较两者的TPS。适用于流入系统来做压力测试。（本身的系统消耗决定了处理能力）
2． 模拟不同RT范围的场景，不同容器对于资源的消耗程度。（比如模拟后端系统响应时间的范围，来观察不同容器并发处理能力及稳定性）。适用于流出系统的强依赖模式。
3． 通过采用类似于Jetty Continuation或者servlet3的模式来将业务和系统线程池切分开来，加上带有业务性隔离的服务线程池实现服务切换和降级，比较带来的损耗是否可以接受，判断是否换容器。适用于流出系统的弱依赖模式。
总体来说：
1． 建立统一的资源消耗模型（用实际的消耗来判断服务器的能力瓶颈）
2． 根据依赖系统的响应时间来实际模拟场景判断带来的影响。（连接消耗在某些场景下已经是九牛一毛的case了，优化本身就没有太大实际意义）
3． 对于系统本身是否有除了性能以外的更多需求，比如系统稳定性要求的服务降级和切换。
4． 容器本身的模式可改进点及可维护性（模块化等）。
5． 最后对于慢请求的支持（内部网络请求往往无法模拟慢请求对java容器的“伤害”，这也就是为什么要加一层http代理的目的）
近期做一下测试比较，给出一些结论性的东西，不过希望大家做测试一定要考虑场景和真实的需求，切勿仅仅为了容器测试而作容器测试。（同时把封装的jetty层异步调用+业务性隔离的线程池代码包共享出来）