JMETER 性能测试压测指标如何计算基于业务指标
1、日活 访问量 活跃度
2.1 PV(Page View)
访问量, 即页面累计浏览量或点击量,衡量网站用户访问的网页数量;在一定统计周期内用户每打开或刷新一个页面就记录1次,多次打开或刷新同一页面则浏览量累计。
2.2 UV(Unique Visitor)
访问用户数(去重),统计1天内访问某站点的用户数(以cookie为依据);访问网站的一台电脑客户端为一个访客。可以理解成访问某网站的电脑的数量。网站判断来访电脑的身份是通过来访电脑的cookies实现的。如果更换了IP后但不清除cookies,再访问相同网站,该网站的统计中UV数是不变的。如果用户不保存cookies访问、清除了cookies或者更换设备访问,计数会加1。00:00-24:00内相同的客户端多次访问只计为1个访客。
1、UV(Unique Visitor)):没有时间范围限制,就是访问用户数(去重),所以一般会加上每日UV,现在一般都指PC站的访问用户数;
2、DAU(Daily Active User):加了时间限制,就是指每日访问用户数(去重),日活跃用户数量。常用于反映网站、互联网应用运营情况
3、MAU(monthly active users):月活跃用户人数。
3、DAU相关指标DAU-DNU
活跃度:DNU/DAU叫这个指标为活跃度指数,也叫做新增用户占比。
Session:一次会话是使用同一浏览器发送的多次请求。一旦浏览器关闭,则结束会话
(1)Session用于记录用户的状态。Session指的是一段时间内,单个客户端与Web服务器的一连串相关的交互过程。
(2)在一个Session中,客户可能会多次请求访问同一个资源,也有可能请求访问各种不同的服务器资源。
(3)Session是由服务器端创建的,通过request对象获取:
The formula is: Throughput = (number of requests) / (total time)
吞吐量按请求数/单位时间计算。时间是从第一个样本开始到最后一个样本结束计算的。这包括样本之间的任何间隔,因为它应该代表服务器上的负载。
公式为:吞吐量 =(请求数)/(总时间)
吞吐量
系统的吞吐量是用来反映系统能够承载多少的用户请求压力。与用户请求、CPU处理能力、IO操作等等都有关系。
简单的举个例子,在春运期间,一个车站的吞吐量就是指这个车站能够收发多少人员。如果我们将一个旅客看做一个用户请求的话,能够体现其吞吐量的因素应该有如下的几个。
第一、能够处理请求的效率,也就是上面提到的QPS。
第二、同时能够处理多少的请求,也就是上面提到的并发数。
第三、就是系统的处理时间,也就是上面提到的响应时间。
Summary Report:
摘要报告会为测试中每个不同名称的请求创建一个表行。它与汇总报告类似,但占用的内存较少。
吞吐量是从采样器目标的角度计算的(例如,对于 HTTP 样本,则是远程服务器)。JMeter 会考虑生成请求的总时间。如果其他采样器和计时器位于同一线程中,则会增加总时间,从而降低吞吐量值。因此,两个名称不同的相同采样器的吞吐量将是两个名称相同的采样器的一半。正确选择采样器标签对于从报告中获得最佳结果非常重要
聚合报告Aggregate Report
汇总报告会为测试中每个不同名称的请求创建一个表行。对于每个请求,它会汇总响应信息并提供请求数、最小值、最大值、平均值、错误率、近似吞吐量(请求/秒)和每秒千字节吞吐量。测试完成后,吞吐量是整个测试期间的实际吞吐量。
4、从业务角度推算
5、根据session公式计算业务并发:
1、平均并发用户数C
C = nL/T
2、并发用户数峰值C':
C'≈C+3*根号C
适用范围:Web类访问
平均并发用户数:C = n * L / T
C是平均的并发用户数;
n是login session的数量;
L是login session的平均长度(一天内用户从登录到退出的平均时间);
T指考察的时间段长度。
计算并发用户数峰值: C’≈ C+3根号C
C’指并发用户数的峰值,C就是公式(1)中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。
泊松分布:
模拟15万用户session中的80%用户在线停留时长20min,用户一天中,有8小时的时间会使用我们的网站,其中假设20%的用户同时在线,我们可推算出并发用户数:
C(平均并发用户数)= 150000*0.8*20/(1440*0.33*0.2)/60=420
C' (并发用户数峰值)= 420 + 3*sqrt(420)=480
并发用户数与TPS(每秒事务数)的关系:
并发用户数和TPS是系统性能评估的两个重要指标,它们之间存在一定的关系。
-
并发用户数(Vu):指的是现实系统中操作业务的用户,也称为虚拟用户数(Virutal User)。并发用户数会对服务器产生压力。
-
TPS(每秒事务数):是衡量系统性能的一个非常重要的指标,它表示系统在单位时间内能够处理的事务数量。
- 每个事务的平均响应时间(T):事务从开始到结束的平均时间,通常以秒为单位。
- 假设所有事务都是连续进行的,没有任何延迟,那么每秒处理的事务数(TPS)可以用以下公式计算:TPS=Vu/T
并发用户数和TPS之间的关系可以通过以下方式理解:
-
单接口场景:一个虚拟用户在1秒内完成1笔事务,则TPS为1。如果业务响应时间为1S,则480个用户在1秒内能完成480笔事务,TPS就是480。因此,并发用户数和TPS之间的关系取决于业务的响应时间,如果响应时间为0.5S,则480个用户在1秒内能完成960笔事务,TPS就是960。
-
混合场景:在多个脚本、每个脚本包含多个事务的复杂场景中,TPS的计算需要考虑每个脚本使用的并发用户数、每个事务花费的时间等因素。具体公式为:第j个事务的TPS = Vui/Rti(其中Vui表示第i个脚本使用的并发用户数,Rti表示第i个脚本一次完成所有操作的时间)。总的TPS则为所有事务TPS的和。
总结来说,并发用户数的推算可以通过经典公式或通用公式进行,而并发用户数与TPS之间的关系则取决于业务的响应时间以及系统的复杂程度。在进行性能评估时,需要综合考虑这两个指标以及其他相关因素。
写在最后:
实际我们电商压测过程中以自己公司线上监控到流量情况为准,比如遇到大型节假日或者大促历史数据峰值比如历史活动前10s或者60s内流量峰值最具参考意义,比如遇到黑五 一下子投放流量十几万当天运营人员,我们监测到前10s的请求量request总请求数据18K=18000,那么可以推算平均1800/s的QPS这里我直接按2000,基于这个数据我们就可以指定脚本实施压测:
具体案例参考这篇:https://www.cnblogs.com/SunshineKimi/p/18530213
平均并发数(每秒平均请求数)= 80% * 日请求量 / 1天 * 30%
进而计算出最高峰值与平均并发数的倍数 = 2.25
故,高峰并发数(每秒高峰请求数)= 2.25 * 平均并发数 =
2.25 * 80% * 日请求量 / 1天 * 30% = 6 * 日请求量 / 1天
因UV与请求量曲线分布呈线性关系,日请求量 = 9.25 * 日UV
故,高峰并发数 = 6 * 9.25 * 日UV / 1天 = 55.5 * 日UV / 1天
· 分享一个免费、快速、无限量使用的满血 DeepSeek R1 模型,支持深度思考和联网搜索!
· 使用C#创建一个MCP客户端
· ollama系列1:轻松3步本地部署deepseek,普通电脑可用
· 基于 Docker 搭建 FRP 内网穿透开源项目(很简单哒)
· 按钮权限的设计及实现
2021-06-14 APschedule 三大trigger