• 你们是用现成的工具/框架还是自己造轮子?

    换工具这种事超级烦,之前的脚本不通用: (
    项目里已经用过jmeter、gatling、locust,没一个满意,浪费不少时间,被老大骂很多次了……应付临时任务还是jmeter最适合,无论效率还是性能

    有空准备看看taurus,如果它的yaml用例格式比较合理就模仿一下,以后让新工具支持解析这种文件就不用那么烦了……

  • 大概知道上面是怎么回事了,似乎跟自己发请求自己监控有关,虽然电脑明明还有不少资源

    用了master/slave就正常多了,对很快的请求这是不能接受的,10倍时间……好在那种接口通常ab或wrk就够用

    有空再翻翻源码看看怎么回事,另外那个hatch rate和number of user的设置跟实际的上限和增长率的关系也是个迷……

  • 今天遇到了,看见locust里每个接口的平均响应时间都很整齐的1秒多,拿nginx_status页面试了一下,其他工具报告平均4ms,locust竟然报300ms,结果完全没法信了

    总之先提个issue……,也给准备入坑的人看看这夸张的数字……
    https://github.com/locustio/locust/issues/663


    再来个真正的接口的例子,jmeter 200线程 vs locust 200协程

    之前用locust做了两个项目都没有这么离谱,返回的数字都是比较合理的,今天不清楚什么情况……


  • 我的耳机进化史 🎧 at 2017年10月04日

    +1……

  • 已交智商税

  • 吃蝗虫挺好的嘛 不留着兼容?(手动滑稽

  • 这边实测的结果也是现在被人看好的gatling和locust真的没法跟被鄙视的jmeter比极限性能

    jmeter从2.x开始每个小版本都在优化性能和采用更合理的默认配置,现在3.2版简单调下JVM参数,测部署在配置一般的服务器上的hello world或nginx_stub,不比ab/wrk差多少

    我测的结果是ab/wrk 34k左右,jmeter 26k-29k,号称高性能的gatling 14-22k,locust + zeromq + 8个slave才2-3k……

    但!是!jmeter太旧了,诞生的时候NIO还没出来,收发请求是同步的,被测程序响应慢就会导致一堆线程堵塞,没有足够的压力到服务器,工具本身再快也没用。我们很少会去测静态页或从redis读数据直接返回的接口,多数时候它的表现都不能让人满意


    gatling最近在用,本来想全面转向它的,越用越不对劲,before()after()里不支持gatling的DSL,要用原生scala,这会导致同一个接口在准备数据和跑测试时要以不同的方式写2次,复用起来也很麻烦

    被requests惯坏了的人看到scala里的各种http库的api就倒胃口,碰都不想碰,估计只有java程序员忍得了(逃

    它的分布式也相当简单粗暴:在不同机器开几个,跑完把log文件拼起来

    另外今天才发现它没法做到真的并行测多个接口,比如已知4个RPS差不多,互相无依赖的接口放进去,结果 A >> B >> C >> D,后面每个都只有前一个的一半左右,issue在这:https://github.com/gatling/gatling/issues/2336

    最后就是我也不懂scala,暂时弃坑╮(╯▽╰)╭


    locust,很恶心也很舒服……官方文档没多详细,例子极少,必须要看源码和踩过坑的人写的教程才能入门……

    它只有一个骨架,几乎什么都不提供要自己实现,好听点自由,不好听寒碜……

    但是python + requests顺手啊!╮(╯▽╰)╭

    开发效率实在高太多了,尤其像我这样主要测单个接口、单个模块/微服务而不是一长串乱七八糟的业务的,可以一堆不相关接口放一块运行,RPS跟gatling测单个接口没什么区别,节省大量时间

    谁叫绝大多数程序的效率比测试工具低得多呢╮(╯▽╰)╭

    对于目标是在开发过程中尽早暴露问题而不是验收的人来说,locust的缺点可以接受,之后基本就用它了

    期待有一天ApiTestEngine的热度超过locust本身 XD

  • 感谢各位前辈,刚好在坑中就看到了爬出坑的路
    希望以后有更多实用的分享,好人一生平安😆

  • 已报名😀

  • 是很丑,在代码里的注解更丑,之前我们用apidocjs,但不方便返回实体类内容,转战swagger了

    还有什么好介绍没?

守正出奇,一身邪气