• locust 使用的疑问 at July 02, 2020

    问题应该是出现在施压侧,建议多检查下网络IO、磁盘IO等,还有是否系统的文件句柄设置的过小

  • locust 使用的疑问 at June 30, 2020

    场景2和3是在同一个VPS吗,我之前也遇到过加压后,服务端RT不变的情况下,TPS上不去,后来发现是施压侧带宽被占满导致实际压力根本没发出去,增加带宽后问题解决

  • 那就没必要压了。
    或者像楼下说的这样,这种情况主要是针对单用户的。比如我们也是限制单用户三秒内不能重复下单。
    这种情况只能用海量用户去压,而不能单用户重复去压

  • mark 下。。。
    最近在用 boomer 的时候,也遇到这个问题,比如开 5 个 slave,100个用户的数据获取写在了 slave 侧,本意是想每个 slave 取其中的 20 个用户来发请求,但按照我目前这种写法,大概率是部分用户被多个 slave 重复使用了,部分用户没被用到。还没去想怎么处理,没看源码,还不知道多 slave 的时候,参数分配是怎么样的,目前想的是,能否放在 master 侧,由它来分配?如果这样的话,master 也不知道会有多少个 slave 过来,没法分配。。。

  • 不知道你们后端是怎么响应的,不过我司是正常响应http状态码200,responseBody里面还有个errorCode,比如这种情况为2020,那么你做性能的时候,肯定需要判断当前请求是否成功,可以在判断http状态码为200的前提下再判断errorCode。我这边有好几种这样的场景,我是定义一个比如code_list,把这种业务限制的code丢进去,校验时判断如果当前的errorCode存在code_list中时,不向统计中心上报此条数据(可以根据这个业务场景的代码覆盖链条深不深来决定是否上报这条数据,比如如果在最外面的api网关层没做过多的业务判断就直接返回,这种请求可以直接丢弃,如果是走到了业务链最后端之后才返回,那么此条数据可以视为有效压力,就可以保留上报)

  • 反复读了几遍这句话,还是没明白想要表达什么意思

  • 关注下RT,如果RT和最初相比没降,那应该找你施压侧的问题,可能是压力下降了,如果RT大幅增长,服务却没有报错,抓下链路数据,看看时间是消耗在哪里了。从描述来看,20分钟就大幅下降,可以考虑关注下DB那块是不是出问题了

  • 最初用的是websocket做的,每次调试的时候后端主动push过程消息至前端,后来觉得整个执行过程就几秒的时间,没必要做这么重,就直接将整个过程信息在结束的时候直接在responseBody中返回给前端了

  • 😂 这里也能遇见!第一次发帖,可惜项目太烂了,没人看得上

  • 哎 最近也是打算用locust做压测的 实验了两天后发现达不到使用标准 作为施压侧 能力太弱了 经过实验最终得出的结论是 单核只能承载500左右的RPS

    我12核的CPU开了12个slave 实际施压RPS不到六千 准备去试下golang下的boomer看看是否能达到作者说的十倍的提升