ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

性能测试连载 (4)-标准性能测试场景设计

2021-05-11 13:32:32  阅读:244  来源: 互联网

标签:负载 连载 处理 性能 拐点 业务 TPS 测试


前言

如何设计测试场景是性能测试中比较关键的内容。在性能测试领域有几个教科书一样的场景设计方法,放之四海而皆准

单业务基准测试

目的

单业务基准测试是在服务器没有压力的情况下,获取单笔业务的处理时间,为后续调优提供数据依托。

策略

jmeter 中设置为单个线程迭代 n 次(如 100),取平均响应时间。一般情况下我们不需要监控硬件资源和数据库。但是,如果系统出现了 TPS=1 与 TPS=100 消耗的 CPU 资源差不多的情况,那可能就是性能出了问题。

 

 

 

 

 

 

单业务负载测试

目的

获取系统单笔业务的最大处理能力,以及性能指标之间的关联关系和变化趋势,例如:响应时间随 TPS 的变化趋势,TPS 和响应时间随并发用户数变化的趋势、CPU 利用率随 TPS 的变化趋势。注:关注的是最大业务处理能力,而不是系统并发数

执行策略

单业务负载测试一般以逐渐加压的方式执行 30 分钟(无步调、无 ThinkTime),观察性能拐点。同时需要监控服务器资源、数据库处理能力。jmeter 中可以用 rps 定时器或阶梯加压线程组去实现。

rps 设置

 


tps 监听

 

 

 


RT监听

 

 

拐点判断方式:

通过 Tps/Hps 走势图观察拐点。吞吐量会随压力的增大呈抛物线状,抛物线的最高点处,即为当前测试环境下该交易的单支最大处理能力。吞吐量的拐点往往也就是响应时间的拐点。

 

 

通过资源消耗判断拐点。比如测试中 Tps 仍呈上升趋势,但 CPU 资源使用率已高达 90%,就以此时 Tps 值为当前测试环境下该业务的单笔最大处理能力。
单业务负载测试可考察系统结构是否存在性能隐患。

混合业务负载测试

目的:考察各业务按比例分配逐渐加压的情况下,系统随着负载变化处理能力趋势,如响应时间、Tps、资源消耗。
执行策略:按比例分配,通过逐渐加压的方式执行 1~2 小时,需监控服务器资源消耗、数据库处理能力等。混合业务负载测试也需要判断拐点,判断方式与单业务负载测试相同

稳定性测试

目的

系统长时间处于极限负载下的处理能力,是否随着测试时间的增长,有响应时间变长、内存泄露、磁盘空间不足、等隐藏问题。

 
 

 

执行策略

通过阶梯加压的方式执行 8 小时(也可以是 4、6、12、24、24*7 等,根据实际情况),监控服务器资源消耗(特别是核心进程的内存消耗)、数据库处理能力等。稳定性测试负载压力可以采用系统最大处理能力的 70% 或 80%,或混合场景中某个压力值。

 

标签:负载,连载,处理,性能,拐点,业务,TPS,测试
来源: https://www.cnblogs.com/minfanblog/p/14754872.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有