• 可以试试 PMM,拉个docker镜像就能跑,也不用配一堆东西,常见的数据库和服务器监控的功能大致都有,监控服务器集群挺方便

    https://www.percona.com/software/database-tools/percona-monitoring-and-management

  • 后续楼主有没有得出结论?既然是测试接口应该很好搞。

    一些排查原则

    1. 不管什么问题,首先怀疑是客户端的问题
    2. 排查顺序通常是:自己的脚本、设置、机器资源、网络带宽和设置、工具/框架选型本身
    3. 工具是 Locust 的跳过前2点,直接怀疑是它本身有问题,马上用另一款更高效的工具,类似的设置做对比。

    这里不提服务端,因为我猜到这步就能结束了。

    一个小实验

    楼主如果有空可以写这么个简单的接口对比下各种测试工具:

    • 从收到第1个请求开始,前100秒正常响应,比如什么也不做,sleep 10*毫秒*返回
    • 第100秒~第200秒,sleep 50**返回,没看错是50秒
    • 之后又是100秒的正常响应,再接100秒50秒响应,如此反复

    这就是识别 coordinated omission(CO)问题的典型方法,然后你看看各种工具的各个百分位数的统计结果,有多少能让你简单地发现这么明显的问题的,结果很可能会吓一跳。

    除非你一下子就找到了某2款,通常不管开源还是商业还是自研都全军覆没。

    (如果用这个作为首要选型标准,你就会像我一样把 JMeter、nGrinder、Locust、ab、siege 等等统统淘汰了 😆

  • mysql 亿级数据优化 at 2018年08月29日

    这不是反讽吧?😁 都是常见的开发规范,能不能落实得好是另一回事……

  • http_load 06年的过时东西了就别提了吧……

    ab不推荐,content-length长度变了也当成错误,而且单线程是个瓶颈,用nginx-status页面做测试,客户端找台8核以上的服务器,跑一下就知道和wrk差距有多大了。

    小工具推荐 wrk2,https://github.com/giltene/wrk2,是 wrk 的分支。推荐看看作者 Gil Tene 在 readme 里写的关于如何正确测量响应时间,推荐搜一下作者讲 coordinated omission(CO) 的 2 个youtube视频。

    wrk 也可用,性能也更好些。建议跟 wrk2 对照,毕竟CO是个大坑,全世界绝大部分压测工具都掉坑里。

    locust 不推荐,一是作者看上去不知道自己在做什么,二是框架性能和报告功能都极差,有这功夫填坑不如找个更正经的框架二次开发。

    ngrinder 不推荐,往往是只做过demo的人才吹它的开箱即用。github上2年多没更新了,跟死了差不多。

    taurus + jmeter组合现在很流行,算是可用,但小心CO问题。它的命令行报告生成的网页里,首页的响应时间百分位数统计不一定可靠,注意点开看菜单里的各种overtime图表。坑踩得少的人很容易用它骗自己接口的响应时间没问题。现在项目里已经基本抛弃它了。

    愿意封装和写代码的话推荐 Gatling。动手封装前最好搜一下一篇貌似叫 close workload model vs open workload model 之类的论文,06年的。Gatling 要用 open workload model,也就是指定 RPS 然后它每秒新建这么多连接,才能避免 CO 问题。

  • 我不懂网络也不懂内核,以上都是我编的,我实在编不下去了……😆

  • 我不懂网络也不懂内核,以上都是我编的,我实在编不下去了……

    PS: 这个好久之前发的了,鄙视一下转载不写出处的行为:http://blog.51cto.com/wujingfeng/2096885,页面也找不到举报按钮……

    旧文章会过时,也可能作者写的时候理解是错的,对某一块不熟悉的人看了转载的日期比较新,也许就信了,然后掉坑里。

    中文网络上充斥着这种转来转去的文章,有些十几二十年前出现、从一开始就错误的东西到现在还阴魂不散,我也经常被坑。

    这大环境对新人极度不友好,不习惯用 Google 的掉进去就爬不出来了,然后恶性循环。

  • 兄弟你的脚本还不如现成的工具呢,一来 requests 库是同步的,二来 cpython 有 GIL,多线程有点鸡肋,虽然对这种主要耗时在I/O的场景影响不大,但以python的性能,最终还是达不到 jmeter、gatling、ab、wrk 的效果。

    至于jmeter是BIO的,这个我一直以为是搞性能的人的常识呢……

    如果有资源,更高压力可以通过多开实例或增加客户端机器达到,但未必会得到你想要的结果。在服务器或后台服务被压死之前,考虑一下请求根本到不了服务的情况:负载均衡/反代/网关/waf掐掉连接,netfilter哈希表用光弃掉IP包,请求在tcp监听队列、接收队列排队直到超时,连接数限制,文件描述符限制,然后spring cloud或tomcat各种配置限制……

    响应时间增加就是在排队,继续增加压力基本上只能看到计算出的响应时间越来越长,因为队列越来越长,后到的请求排了很久的队,最终看到的错误多半是连接超时或响应超时。

    其实不需要真的搞挂什么,只要业务给出这场景能接受的最大响应时间(或99%,99.9%之类)是多少,达到这个数的时候就是极限了。之后还有余量那是用来扛突发情况的,对用户来说不管挂不挂都是不可用了,在某些行业慢几毫秒可能已经出事了。

  • 请问招专职性能测试不?

    学历除了本科有没有硬性要求专业和学校?😂

  • nGrinder - Groovy 脚本指南 at 2018年03月05日

    选型参考:

    优点:

    • 无需安装、跨平台:总共就 controller、agent、monitor 3个 jar 包。
    • 开箱即用,web UI 比较友好,测最简单的 GET 请求上手门槛低。
    • 有简单的可视化报告。
    • 有简单的资源监控。
    • 有简单的脚本管理功能,整合了 SVN。
    • 容易扩容:只需要把 agent 放到压测机器,monitor 放到被测服务器。

    缺点:

    • 发送请求
      • 首页只支持 GET,POST 需要新建脚本然后创建测试。
    • 脚本管理
      • 脚本文件、目录没法重命名,没法移动,只能删掉重新建一份,或通过 SVN 操作。
      • 如果多个脚本使用同样的库和资源文件,UI 里不好搞(除非全塞同一个目录下),需要建完整的 Maven 工程。
    • 报告
      • 1个测试脚本里调多个接口时,报告里看不出这些接口分别是什么、响应时间和 TPS 分别多少。
      • 1个测试脚本里调多个接口时,只要某个测试方法成功,即使其他方法抛异常也不会反映在报告的错误数里,要看 log 才能发现。
      • 脚本里可以定义多个事务,但详细报告里只有总体情况,想看各个事务的数据只能下载 CSV 自己写程序解析。
      • 响应时间没有按百分位数的统计,需要二次开发。
      • 服务器资源监控收集的数据较少,需要二次开发。
      • 想改默认脚本模板很麻烦,需要改源码然后重新打包。

    总结:

    如果非专职做性能测试的人,如开发/运维/业务测试希望有一个简单的工具来定位问题,而且项目用 HTTP 协议、没有很麻烦的鉴权、签名、加密等限制、GET 请求又足够多,nGrinder 可以用。易用性至少跟 PTS、WeTest 一个水平,nGrinder 要写代码的场景这2个平台或者其他工具多半同样要写。

    专职的话它肯定不是首选,开发起来不够快,定位问题也不够方便,有其他更合适的选择。


    我不懂 Groovy,以上全是我编的,我实在编不下去了……😆

  • 传好了,在这里下:

    https://github.com/keithmork/oh-my-ngrinder


    我不懂 Java,以上全是我编的,我实在编不下去了……😆

守正出奇,一身邪气