java - 测试这样压测合适吗?(缓存是否有并发瓶颈?)
本文介绍了java - 测试这样压测合适吗?(缓存是否有并发瓶颈?)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!
问题描述
问 题
场景:
调用的接口逻辑:根据用户ID从缓存查询一批数据id(每次30),然后拼装数据返回这批数据。
接口压测目标:模拟200个用户并发去访问这个接口(虽然是并发,但每个用户取的都是从自己的缓存取数据)
由于测试某种原因,无法真实模拟 200个用户去访问,所以换了一种方式:
起200个线程,然后并发去访问同一个用户
的接口(也就是200个用户并发去取同一个用户的缓存)
结果:压测出来,接口qps比较低
问题:这种模拟合适吗,redis缓存有并发瓶颈吗?
(正常压测应该 起200个线程,然后去并发访问200个用户的缓存(同一个接口),相当于200个用户同时去访问自己的缓存)
解决方案
楼主的压测方案个人感觉没有什么问题,正常的压测应该是随机取不同用户的
Id
去访问正常情况下
redis
的QPS达到几万是没有什么问题的,如果是redis
集群的话,用同一个用户Id
测试就会落到同一台机器上,而redis
是单线程给的,所以在一定程度上会影响测试的性能-
按照道理来说,200并发如果返回的数据量小的话
QPS
不会很低,建议从以下方面排查是否使用的
redis
的线程池redis
里面存储的数据接口是是什么,考虑一下各种数据结构的查询复杂度统计各个步骤所需要的具体时间,比如说从本地到接口时间
T1
,接口逻辑处理T2
,接口请求redis
得到数据T3
,接口逻辑处理T4
,接口返回本地T5
,统计一下具体在哪一步耗时长可以减少并发线程数和增加线程数,观察一下
QPS
的情况观察服务器的线程情况(看看有没有锁竞争),GC情况,CPU,网卡流量等等性能,观察下硬件是否有瓶颈
这篇关于java - 测试这样压测合适吗?(缓存是否有并发瓶颈?)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!
查看全文