性能测试不为人知的秘密

常用性能测试指标

响应时间

响应时间，Response Time: RT，从用户的角度来讲，就是用起来快不快。
一个请求的响应时间由以下几部分时间构成，响应时间=网络传输的总时间+各组件业务处理时间

定义

响应时间指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间。在性能检测中一般以压力发起端至被压测服务器返回处理结果的时间为计量，单位一般为秒或毫秒。平均响应时间指系统稳定运行时间段内，同一交易的平均响应时间。一般而言，交易响应时间均指平均响应时间
平均响应时间=所有请求的平均耗时=ART（Average Response Time）

参考标准

不同行业不同业务可接受的响应时间是不同的，一般情况，对于在线实时交易：

• 互联网企业：500毫秒以下，例如淘宝业务10毫秒左右。

• 金融企业：1秒以下为佳，部分复杂业务3秒以下。

• 保险企业：3秒以下为佳。

• 制造业：5秒以下为佳。
  对于批量交易：

• 时间窗口：即整个压测过程的时间，不同数据量则时间不一样，例如双11和99大促，数据量级不一样则时间窗口不同。大数据量的情况下，2小时内可完成压测。

使用jmeter查看

1. 添加-监听器-jp@gc - Response Times Over Time
   

2. 压测后，先看聚合报告的平均值
   

3. 再看实时监控的平均响应时间
   

并发数/虚拟用户数

Virtual User：VU
即并发处理能力，压测工具中设置的并发线程/进程数量，海量用户使用系统，在系统不崩溃情况下，能够支撑多少人同时使用。可以理解为每秒/毫秒可以处理多少并发。

定义

并发用户数指在同一时刻内，登录系统并进行业务操作的用户数量。 并发用户数对于长连接系统来说最大并发用户数即是系统的并发接入能力。对于大部分短连接类型的系统，吞吐量模式（RPS模式，Request Per Second）比较适合，也是阿里的最佳实践，PTS支持RPS模式的压测，吞吐量的压测构建和衡量一步到位。 在测试中，采用虚拟用户来模拟现实中用户进行业务操作。

参考标准

一般情况下，性能测试是将系统处理能力容量测出来，而不是测试并发用户数，除了服务器长连接可能影响并发用户数外，系统处理能力不受并发用户数影响，可以用最小的用户数将系统处理能力容量测试出来，也可以用更多的用户将系统处理能力容量测试出来。

jmeter 模拟

相对并发：指在一个时间段内发生的事情
绝对并发：指在同一时刻发生的事情

相对并发

在jmeter的测试计划中添加线程组，设置线程属性，新建一个线程组，设置线程数10，启动时间2，循环次数3.那么相对并发为5,（线程数/启动时间），则sampler总共会运行30次（线程数*循环次数）

用表格结果数查看，每个线程会被运行三次

绝对并发

jmeter实现绝对并发，使用同步定时器（Synchronizing Timer），当同一个时刻达到了某一集合点才发出请求。

1. 模拟用户组数量（Number of Simultaneous Users to Group by）:集合到对应的用户量才发送请求，要求设置的值不能大于线程数。简单点理解就是，如果您想让多个人同时执行一个请求，在这个请求前面加上一个Synchronizing Timer，它会等待您指定的人都到齐了一起出发。

2. 超时时间（Timeout in milliseconds）：400 一般超时时间> 请求集合数量 * 1000 / (线程数 / 启动时间) 2*1000/(10/2)=400ms
   
   即可实现同一时刻发出多个请求
   

TPS

衡量一个系统性能的好坏，主要看的是单位时间内，系统可以处理多少业务量。
系统的性能由TPS决定，跟并发用户数没有多大关系。
系统的最大TPS是一定的（在一个范围内），但并发用户数不一定，可以调整。

定义

TPS：Transaction Per Second，每秒事务数，是衡量系统性能的一个非常重要的指标。

参考标准

无论TPS、QPS、HPS，此指标是衡量系统处理能力非常重要的指标，越大越好，根据经验，一般情况下：

金融行业：1000 TPS~50000 TPS，不包括互联网化的活动。
保险行业：100 TPS~100000 TPS，不包括互联网化的活动。
制造行业：10 TPS~5000 TPS。
互联网电子商务：10000 TPS~1000000 TPS。
互联网中型网站：1000 TPS~50000 TPS。
互联网小型网站：500 TPS~10000 TPS。
TPS获取方式：
已有系统：可选取高峰时刻，在一定时间内（如3分钟-10分钟），获取系统总业务量，计算单位时间（秒）内完成的笔数，乘以2-5倍作为峰值的TPS，例如峰值3分钟内处理订单18万笔，平均TPS是1000，峰值TPS可以是2000-5000。

新系统：没有历史数据作参考，建议通过业务部门进行评估。
响应时间单位为秒的情况下，TPS = 1/响应时间*并发数。

一般情况下采用二八原则去计算，80%的交易发生在20%的时间去处理。如：一天10000笔，TPS = （10000* 80%=8000笔）/（24606020%）。
10000笔交易，上午2小时，下午2个小时，TPS = 10000/460*60。

使用jmeter查看

1. 进入https://jmeter-plugins.org/install/Install/ 下载plugins-manager.jar

2. 将 plugins-manager.jar 放到%JMeter%/lib/ext _目录下，重启 ApacheJMeter

3. 菜单栏上会多出一个“Plugins Manager”的按钮，点击并添加插件： Basic Graph（windows下可用的实时tps和响应时间的插件）

4. 为线程组添加 监听器>jp@gc - Transactions per Second

5. 运行压测程序并查看TPS
   
   在系统达到瓶颈之前，TPS和并发数成正比关系。

QPS

如果是对一个查询接口（单场景）压测，且这个接口内部不会再去请求其它接口，那么tps=qps，否则，tps≠qps

如果是容量场景，假设n个接口都是查询接口，且这个接口内部不会再去请求其它接口，qps=n*tps

定义

QPS = 并发数/响应时间
QPS：Queries Per Second，意思是每秒查询率，是一台服务器每秒能够响应的查询次数（数据库中的每秒执行查询sql的次数），显然，这个不够全面，不能描述增删改，所以，不建议用qps来作为系统性能指标。

JMeter之QPS检测过程

需求案例： 测试20个用户访问Baidu首页（https://www.baidu.com），当负载达到30QPS时的平均响应时间。

1. 添加线程组

2. 添加HTTP请求

3. 设置QPS限制

JMeter提供了一个非常有用的定时器，常数吞吐量定时器（Constant Throughput Timer），可控制给定的取样器发送请求的吞吐量



4. 添加监视器
5. 运行脚本
6. 聚合报告分析

吞吐量

单位时间内，系统能够处理多少请求，吞吐量代表网络的流量，TPS越高，吞吐量越大，还包含了数据的吞吐量。一般单位为秒，每秒处理的请求量。

性能测试的时候关注吞吐量和测试环境网络带宽之间的关系，如果吞吐量接近或者等于测试环境带宽极限，那么很可能存在网络瓶颈。

Jmeter查看吞吐量

在性能测试中，往往涉及到计算吞吐量，Jmeter提供了图形直接看吞吐量

1. jmeter中添加监听器图形结果
   

2. 在图形结果中选择要显示的图形，然后运行脚本，就可以看到图形结果中显示的吞吐量情况了

• 样本数目：总共发送到服务器的请求数。

• 最新样本：代表时间的数字，是服务器响应最后一个请求的时间。

• 吞吐量：服务器每分钟处理的请求数。

• 平均值：总运行时间除以发送到服务器的请求数。

• 中间值：有一半的服务器响应时间低于改值而另一半高于该值。

• 偏离：表示服务器响应时间变化、离散程度测量值的大小。

前端指标

前端指标主要包括页面展示和网络所花的时间，具体如下：

影响产品性能的原因

网络带宽

网络对性能的影响不言而喻。

如果带宽不足，单位时间内的请求过多，就会导致数据包的传输延迟较大。

如果网络不稳定，也会导致RT的曲线抖动较为剧烈，产生毛刺甚至丢包，这个时候P90/P99的数值也可能变大。因此稳定和足够的网络带宽，对系统的性能来说是很重要的。

负载均衡

现在的SLB层已经优化的足够好，但如果负载均衡出现问题，可能会导致流量分发不均匀，导致部分应用节点流量异常，健康检查不通过从而被踢下线。甚至服务注册重试失败或者弹性扩容不够及时，还会导致可用的节点承受了较多的请求最终导致雪崩效应。

安全策略

现在的软件系统，常见的安全防护策略有ddos高防以及WAF，一般都是部署在SLB和流量网关之间或者更上层。

安全防护策略常见的场景有异常检测、输入验证、安全补丁、状态管理以及基于规则和异常的保护功能。

这些安全策略能够有效的保护系统不受到一些恶意的攻击和侵入，但这些策略生效也是需要耗费时间的。

流量网关

上面提到的几个部分都可以看做是互联网时代的基础通用层，而网关是伴随着微服务和容器化出现的，作为用户流量的系统入口，网关也承担了较多的功能，比如：

日志

身份鉴权

灰度发布

限流熔断

可观测性metrics

应用限流apm tracing

上述的功能，无论是身份鉴权还是可观测性的metrics的实现，都需要耗费一定时间。

特别是对于请求的RT比较敏感的业务，对流量网关功能的耗时要求更为严格。

应用层

应用层（即我们常说的后端服务）则更多的负责逻辑计算。逻辑计算是很吃资源的，当然和它的一些参数配置以及技术架构也有较大关联。常见的影响后端服务性能的因素如下：

硬件资源：如CPU/Memory；

参数配置：如Activethreads/TimeOut；

缓存配置：缓存中的大Key及缓存命中率；

并行计算：请求下游依赖是串行还是并行？

代码逻辑：最经典的例子——for循环无线套娃；

日志处理：特别是异常日志的处理以及生产日志级别；

处理机制：同步还是异步？如果是异步，MQ容量及消费能力如何？

数据存储层

数据存储层即数据库，数据库层面影响性能的因素应该是最常见也是最多的。比如：

锁：不合理的锁使用导致的请求等待；

索引：未加索引或索引未生效导致慢SQL；

数据量：表数据量过大导致的读写变慢等问题；

针对业务扩张及数据量变大问题，常见的优化策略有分库分表、垂直拆分、读写分离。

参考资料

阿里云性能测试指标