Web容器测试模型选择
作者:网络转载 发布时间:[ 2012/11/6 10:57:45 ] 推荐标签:
近被内部问了太多关于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层异步调用+业务性隔离的线程池代码包共享出来)
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11