jmeter用户数线程数_jmeter根据负载量计算并发用户数实例

业务需求

假设公司领导现在给你分配了一个性能测试需求如下&＃xff1a;

1&＃xff1a;公司有1000人在上班时间段会登录平台进行打卡操作&＃xff0c;可能会登录打卡多次

2&＃xff1a;业务高峰时间段在8:00-8:30&＃xff0c;半小时

3&＃xff1a;需要保证90%用户的响应时间在1s以内

4&＃xff1a;保证在半小时内支撑5000笔打卡业务完成&＃xff0c;同时90%业务时间不超过1s&＃xff0c;半小时内最大系统并发数能达到多少&＃xff1f;每秒最大用户并发能达到多少&＃xff1f;

分析需求

a.1000人在30分钟内完成登录&＃xff0c;那么每分钟有1000/30&＃61;33的人登录&＃xff0c;每秒有0.56人登录&＃xff0c;也就是2s中有1个人登录&＃xff1b;

b.5000笔打卡业务在30分钟内完成&＃xff0c;那么每秒中需要完成5000/(30*60)&＃61;2.78个打卡事务&＃xff1b;

综合就是半小时内&＃xff0c;每2s有一人登录&＃xff0c;每秒需有3个打卡事务&＃xff1b;也就是线程持续时间30分钟&＃xff0c;打卡tps&＃61;3&＃xff1b;

循环一次&＃xff0c;登录317ms&＃43;打卡976ms&＃61;1293ms&＃xff0c;1s中可迭代0.77次&＃xff1b;30分钟可迭代1392次&＃xff1b;登录请求1个线程即可满足要求&＃xff1b;

30分钟想完成5000笔打卡&＃xff0c;需并发线程5000/1392&＃61;3.6 即4个线程&＃xff1b;

实际请求中&＃xff0c;还需要考虑登录时输入账户密码的时间&＃xff0c;可加定时器&＃xff1b;

测试模型构建 & 用例设计

这种需求是典型的根据负载量计算并发数的场景。首先我们需要设计一下业务场景&＃xff1b;

一、场景构建&＃xff1a;登录业务操作流程、考勤打卡操作流程&＃xff1b;

二、场景用例设计

1.测试场景类型&＃xff1a;

单业务基准测试、单业务压力测试、单业务负载测试&＃xff1b;

综合业务基准测试、综合业务压力测试、综合业务负载测试&＃xff1b;

2.业务量线程数的确定&＃xff1a;

登录业务-线程数确定、考勤打卡-线程数确定&＃xff1b;

3.测试场景用例设计&＃xff1a;

登录并发-场景用例、登录业务量-场景用例、并发考勤-场景用例、考勤打卡业务量-场景用例&＃xff1b;

三、测试脚本用例设计&＃xff1a;

登录-脚本用例、考勤打卡-脚本用例&＃xff1b;

模型构建

登录业务-操作流程

a)访问登录页面&＃xff1b;

b)输入账号、密码&＃xff0c;点击【登录】&＃xff0c;跳转到主页&＃xff1b;

c)点击【退出】&＃xff0c;跳转到登录页面&＃xff1b;

登录打卡-操作流程&＃xff1a;

a)访问登录页面&＃xff1b;&＃xff1b;

b)输入账号、密码&＃xff0c;点击【登录】&＃xff0c;跳转到主页&＃xff1b;

c)点击【考勤管理】&＃xff0c;进入考勤主页&＃xff1b;

d)点击【打卡】&＃xff1b;

e)进入考勤打卡页面&＃xff0c;查看打卡记录&＃xff1b;

e )点击【退出】&＃xff0c;跳转到登录页&＃xff1b;

场景设计

性能测试过程中&＃xff0c;首先应该设计测试场景&＃xff0c;然后针对场景设计脚本。为了真实反映被测对象的性能问题&＃xff0c;需要尽可能模拟出被测对象可能发生瓶颈的业务场景。然后设计针对业务的测试场景&＃xff1b;

常用测试场景的类型&＃xff1b;

性能测试通常有几种常用测试场景&＃xff1a;单业务基准测试、单业务压力测试、单业务负载测试、综合业务基准测试、综合业务压力测试、综合业务负载测试&＃xff1b;

1)基准测试

测试某个具体业务是否满足系统设计 或 用户期望的性能指标&＃xff1b;基准测试可以为并发基准、业务量基准&＃xff1b;

如&＃xff0c;期望登录接口支持500个用户并发登录&＃xff0c;同时响应时间不超过需求值。满足则认为基准测试完成&＃xff0c;否则失败&＃xff1b;

2)压力测试

测试某个具体业务在最大负载下&＃xff0c;持续服务的时长&＃xff0c;以此验证被测业务的稳定性&＃xff1b;

压力测试过程中所设计的负载&＃xff0c;是以系统基准测试为标准&＃xff0c;如登录接口最大并发为500个并发&＃xff0c;则压力测试的负载设计为500个&＃xff1b;通过运行时长的变化&＃xff0c;验证服务器在系统最大负载下持续服务的能力&＃xff1b;

3)负载测试

测试某个具体业务能够承受的最大负载&＃xff0c;验证被测业务能够承受的最大负载数&＃xff1b;

如系统基准测试最大并发为500个&＃xff0c;则通过多次测试&＃xff0c;逐步加大负载&＃xff0c;最终获得被测业务的最佳负载。在最佳负载下&＃xff0c;系统需要满足各项性能指标&＃xff1b;

登录打卡345ms*5&＃61;1725ms

加了事务控制器后&＃xff0c;登录打卡1397ms

实际情况&＃xff0c;还需要考虑以下情形的思考时间&＃xff0c;如&＃xff1a;

用户输入用户名、密码&＃xff1a;5s&＃xff1b;

打开考勤后等待时间&＃xff1a;2s&＃xff1b;

用定时器模拟思考时间&＃xff1b;

那么一次登录打卡需要时间(t)为1.397&＃43;5&＃43;2&＃61;8.397s&＃xff1b;

那么30分钟(T)可以迭代登录打卡的次数&＃61;30*60/8.397&＃61;214.36&＃xff1b;实际需要5000笔业务数&＃xff1b;

需要设置的线程数&＃61;5000/214.36&＃61;23.32&＃xff0c;为了保证>&＃61;5000笔业务数&＃xff0c;所以线程取24&＃xff1b;线程数&＃61;5000/(60*T/t)&＃61;5000*[t/(60*T)]

由此可以得出&＃xff1a;Thread &＃61; BC*[t/(60*T)]&＃xff0c;

BC&＃xff1a;业务数/业务量&＃xff0c;本例中 BC&＃61;5000 &＃xff1b;

t&＃xff1a;单用户单次业务消耗时间&＃xff0c;尽可能模拟真实用户的真实行为&＃xff0c;本例中 t&＃61;8.397s&＃xff1b;

T&＃xff1a;考察时长&＃xff0c;本例中 T&＃61;30分钟&＃xff1b;

关于Thread&＃xff0c;这里计算的是需要的线程数&＃xff0c;事实上这个公式计算的是单位时间平均并发数。就是单位时间内有多少用户或者线程并发向服务端发起请求&＃xff1b;

假如登录打卡业务场景&＃xff0c;计算的是24.

在jmeter中表示需要系统平均需要24个线程同时发起请求才能在对应的时间段内支撑对应的业务量&＃xff1b;

在真实的用户场景中&＃xff0c;则表示平均每秒最大支撑24个用户同时发起请求才能在对应的时间段内支撑对应的业务量&＃xff1b;

这个计算的是评价并发

对应的峰值并发&＃xff1a;Thread_Max &＃61; Thread &＃43; 3*根号Thread

如果平均并发是24的花&＃xff0c;那么Thread_Max &＃61; 24 &＃43; 3*根号24 &＃61; 38.7&＃xff0c;每秒的并发用户峰值大约是39&＃xff1b;

尴尬了&＃xff0c;跑了2次&＃xff0c;均未到达5000业务数&＃xff0c;无解ing