目录:导读
- 前言
- 一、Python编程入门到精通
- 二、接口自动化项目实战
- 三、Web自动化项目实战
- 四、App自动化项目实战
- 五、一线大厂简历
- 六、测试开发DevOps体系
- 七、常用自动化测试工具
- 八、JMeter性能测试
- 九、总结(尾部小惊喜)
前言
1、性能测试-TPS上不去哪些原因导致的?
1)网络带宽
在压力测试中,有时候要模拟大量的用户请求,如果单位时间内传递的数据包过大,超过了带宽的传输能力,就会造成网络资源竞争,导致服务端接收到的请求数达不到服务端的处理能力上限。
2)连接池
可用连接数太少,造成请求等待。连接池一般分为服务器连接池(比如Tomcat)和数据库连接池(或者理解为最大允许连接数也行),没有保持长连接,TCP 连接频繁中断
3)GC
如果堆内存分配的不合理,就会导致频繁的gc,gc会导致线程暂停。尤其是fullgc,会造成线程长时间暂停,代码故障,list 使用 contain 方法进行遍历去重,线程阻塞或者死锁
jvm 内存分配故障,fullgc 频繁,内存溢出
4)数据库配置
高并发情况下,如果请求数据需要写入数据库且需要写入多个表的时候,数据库的最大连接数不够,或者写入数据的SQL没有索引,或没有主从分离、读写分离,就会导致数据库事务处理过慢,还有数据库没加索引,db 缓存空间不足,也会影响到TPS。
5)硬件资源
包括CPU(配置、使用率等)、内存(占用率等)、磁盘(I/O、页交换等)
6)压力机
单机负载能力有限,如果需要模拟的用户请求数超过其负载极限,会影响TPS(这个时候就需要进行分布式压测来解决问题)
7)其他中间件
Nginx 负载均衡策略不当,压力分配不均
Redis 瓶颈。hash 未合并,缓存被击穿,单条命令耗时过长
8)硬件资源中CPU和内存
服务器资源不足,上下文切换过快,中断过高,swap 交换频繁
压力大的时候tps频繁抖动,导致总tps上不去。查看是否有fullgc(tail -f gc_mSrv1.log | grep full)
pacing设置太小也会导致tps上不去,对抖动大的交易多增加点用户即可。
tps抖动,单压抖动大的交易,发现很平稳,这时怀疑是不是压力太大导致,所以发容量的时候把压力最大的那只交易分到其他压力机,然后发现tps不抖动了。
注意:多台压力机只影响tps抖动,不会影响服务器的cpu。看响应时间有没有超时,看用户数够不够。
2、性能测试-电商系统TPS计算方法
怎么计算得出tps指标?
1)第一个通过运维那边给的生产数据,看一下生产进件有多少,计算得来的,如果没有生产数据,或者不过就看如下的方法
2)第二个就是根据最近一个月的实际访问数据,比如每天调用了多少个接口,调用了哪些接口,把比例列出来
我举个例子,比如我们yshop系统,从2023-4-8到2023-5-8,最高的一天调用接口数量最高为100万次,那么tps的计算公式如下:
tps = 1000000/24*3600=11.57/sec ---->这是通用的tps
比如这100万次请求里面
登录请求比例:40% 那么登录接口的标准tps=11.57*40% = 4.63/sec
退出请求比例:20% 那么退出接口的标准tps=11.57*20% = 2.31/sec
添加商品比例:20% 那么添加商品接口的标准tps=11.57*20% = 2.31/sec
查询商品比例:10% 那么查询商品接口的标准tps=11.57*10% = 1.16/sec
修改商品比例:10% 那么修改商品接口的标准tps=11.57*10% = 1.16/sec
如上是通用的tps模型,除了上面的通用tps模型,还有添加商品和查询商品的业务模型,比如下午9点添加商品占比40%,下午16点查询商品占比20%,那么就需要重新计算了
添加商品业务模型:
首先拿到9点这一小时的数据为10万,那么tps = 100000/3600*40% = 11.1/sec
查询商品业务模型:
首先拿到16点这一小时的数据为8万,那么tps = 80000/3600*20% = 4.44/sec
性能问题1:如果500tps那并发线程数应该是多少?
首先搞清楚一个概念就是:服务器的tps是有一个阈值的 要达到500tps 用50个并发线程数和100并发线程数,或者200并发线程数 都可以达到500tps,还有一个概念并发线程数和并发用户数不是同一个概念,并发线程数是jmeter里面的线程数,而并发用户数是需要通过tps来进行承载的,这个里面的并发用户数就是500tps
再延伸一点:如果需要达到500tps并发用户数,如果并发度为1%,那么在线用户应该就是500tps/1% = 50000的在线用户,这个并发度又是怎么计算的呢?
并发度计算:50000的在线用户,在1秒内发出来了500个接口请求,那么并发度等于500/50000=1%,这个就是并发度的计算公式
注册用户计算:可以取在线用户的10-100倍,也就是50万*500万 = 50万-500万的注册用户
500tps = 50个并发线程数/0.1秒
500tps = 100个并发线程数/0.2秒
500tps = 200个并发线程数/0.4秒
…
500tps = 1000个并发线程数/2秒
总结:用更多的并发线程数来做压测或者负载,不会让服务器的tps继续往上增加,只会增加响应时间,因为每台服务器的tps是有一个上限阈值的,到了这个阈值就不会再增加了。
性能问题2:你们之前支持多少个并发?
所以经常有面试官问你,你们之前支持多少并发,其实这个并发是指的并发用户数,而不是并发线程数,并发用户数是通过tps来承载的,你上面说的500tps,你就可以理解为并发用户数就是500tps,最高支持500个并发, 而jmeter里面的那个线程数指的是并发线程数,加大并发线程数只会让响应时间变大,而不会增加tps,并且jmeter里面线程数加到超过500,jmeter自身就会很卡。
下面是我整理的2024年最全的软件测试工程师学习知识架构体系图 |
一、Python编程入门到精通
二、接口自动化项目实战
三、Web自动化项目实战
四、App自动化项目实战
五、一线大厂简历
六、测试开发DevOps体系
七、常用自动化测试工具
八、JMeter性能测试
九、总结(尾部小惊喜)
努力奋斗,不断超越自我,让梦想的火花照亮前行的路途,每一次的坚持都是向成功进发的关键一步,终将绽放出绚丽的人生篇章。
披荆斩棘,砥砺前行,坚韧不拔的奋斗之路上,每一次的努力都在铺就通往成功的阶梯,让心中的梦想驱使着你勇往直前,终将获得辉煌的成就。
在逆境中磨砺意志,在迷茫中寻找方向,坚持不懈地追逐梦想,勇敢面对挑战,奋斗的每一步都是通往成功的征程,绽放出生命的华丽光芒。