为了账号安全,请及时绑定邮箱和手机立即绑定

测试这样压测合适吗?(缓存是否有并发瓶颈?)

测试这样压测合适吗?(缓存是否有并发瓶颈?)

芜湖不芜 2018-09-13 18:10:14
场景:调用的接口逻辑:根据用户ID从缓存查询一批数据id(每次30),然后拼装数据返回这批数据。接口压测目标:模拟200个用户并发去访问这个接口(虽然是并发,但每个用户取的都是从自己的缓存取数据)由于测试某种原因,无法真实模拟 200个用户去访问,所以换了一种方式:起200个线程,然后并发去访问同一个用户的接口(也就是200个用户并发去取同一个用户的缓存)结果:压测出来,接口qps比较低问题:这种模拟合适吗,redis缓存有并发瓶颈吗?(正常压测应该 起200个线程,然后去并发访问200个用户的缓存(同一个接口),相当于200个用户同时去访问自己的缓存)
查看完整描述

2 回答

?
慕哥9229398

TA贡献1877条经验 获得超6个赞

这个……我不是测试,所以也不知道怎样分析。
但感觉200并发量并不大啊,只要机器性能不是太差(CPU、内存、磁盘IO),而且又是缓存(根据你的场景,单次传输的数据量也不大),几乎没什么压力可言。

查看完整回答
反对 回复 2018-09-28
?
慕无忌1623718

TA贡献1744条经验 获得超4个赞

  1. 楼主的压测方案个人感觉没有什么问题,正常的压测应该是随机取不同用户的Id去访问

  2. 正常情况下redis的QPS达到几万是没有什么问题的,如果是redis集群的话,用同一个用户Id测试就会落到同一台机器上,而redis是单线程给的,所以在一定程度上会影响测试的性能

  3. 按照道理来说,200并发如果返回的数据量小的话QPS不会很低,建议从以下方面排查

    1. 是否使用的redis的线程池

    2. redis里面存储的数据接口是是什么,考虑一下各种数据结构的查询复杂度

    3. 统计各个步骤所需要的具体时间,比如说从本地到接口时间T1,接口逻辑处理T2,接口请求redis得到数据T3,接口逻辑处理T4,接口返回本地T5,统计一下具体在哪一步耗时长

    4. 可以减少并发线程数和增加线程数,观察一下QPS的情况

    5. 观察服务器的线程情况(看看有没有锁竞争),GC情况,CPU,网卡流量等等性能,观察下硬件是否有瓶颈


查看完整回答
反对 回复 2018-09-28
  • 2 回答
  • 0 关注
  • 2234 浏览
慕课专栏
更多

添加回答

举报

0/150
提交
取消
意见反馈 帮助中心 APP下载
官方微信