1、概念及公式
QTS:每秒查询率,衡量单个接口
TPS:每秒事务数,衡量多个接口,决定系统性能,与并发数无关
RPS:每秒请求数,
RT:响应时间
- 系统响应时间:
系统一次调用的响应时间跟项目计划一样,也有一条关键路径,这个关键路径就是系统响应时间,关键路径是由CPU运算、IO、外部系统响应等组成。
响应时间= 网络传输时间 + 应用服务器处理时间 + 数据库服务器处理时间
- 并发用户数(Vu)获取
新系统:没有历史数据作参考,只能通过业务部门进行评估。
旧系统:对于已经上线的系统,可以选取高峰时刻,在一定时间内使用系统的人数,这些人数认为属于在线用户数,并发用户数取10%就可以了,例如在半个小时内,使用系统的用户数为10000,那么取10%作为并发用户数基本就够了
- TPS获取
新系统:没有历史数据作参考,只能通过业务部门进行评估。
旧系统:对于已经上线的系统,可以选取高峰时刻,在5分钟或10分钟内,获取系统每笔交易的业务量和总业务量,按照单位时间内完成的笔数计算出TPS,即业务笔数/单位时间(5*60或10*60)
并发用户数:辅助衡量系统性能,一般不用来衡量系统性能
QPS = 并发量 / 平均响应时间,
TPS波动率T = (TPS标准差/TPS平均值)*100%
2、压测前的准备:https://blog.csdn.net/weixin_33805743/article/details/88700742
(1)压力测试策略:负载测试策略,按照梯度施压的方式去加用户数,当达到瓶颈的时候就可进行参数调整和优化
(2)建立压测分支:
(3)搭建压测环境:
(4)准备测试脚本:
(5)初步压测及分析:
(6)深入压测及分析
3、TPS上不去
1、网络带宽
2、连接池:服务器连接池(比如Tomcat)和数据库连接池(或者理解为最大允许连接数也行)。
3、垃圾回收机制
4、数据库配置:写入数据库且需要写入多个表的时候,如果数据库的最大连接数不够,或者写入数据的SQL没有索引没有绑定变量,抑或没有主从分离、读写分离等,就会导致数据库事务处理过慢,影响到TPS。
5、通信连接机制:串行、并行、长连接、管道连接等,不同的连接情况,也间接的会对TPS造成影响。
6、硬件资源:包括CPU(配置、使用率等)、内存(占用率等)、磁盘(I/O、页交换等)。
7、压力机:比如jmeter,单机负载能力有限,如果需要模拟的用户请求数超过其负载极限,也会间接影响TPS(这个时候就需要进行分布式压测来解决其单机负载的问题)。
8、压测脚本:进行阶梯式加压测试,最大的模拟请求数超过了设置的线程数,导致线程不足。
9、业务逻辑:业务解耦度较低,较为复杂,整个事务处理线被拉长导致的问题。
10、系统架构:比如是否有缓存服务,缓存服务器配置,缓存命中率、缓存穿透以及缓存过期等,都会影响到测试结果。
转:https://blog.csdn.net/u011197146/article/details/83273879
https://blog.csdn.net/taric_ma/article/details/77285522
连接池与线程:https://www.cnblogs.com/imyalost/p/7189455.html
常见术语:https://www.cnblogs.com/imyalost/p/7117320.html
连接管理:https://www.cnblogs.com/imyalost/p/7887667.html
APP接口测试:https://blog.csdn.net/whorus1/article/details/50681678