厉害，第 2 题你的做法开发效率要高太多了

求分享经验：）

可以试试 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 等等统统淘汰了

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

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% 之类）是多少，达到这个数的时候就是极限了。之后还有余量那是用来扛突发情况的，对用户来说不管挂不挂都是不可用了，在某些行业慢几毫秒可能已经出事了。

请问招专职性能测试不？

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

选型参考：

优点：

• 无需安装、跨平台：总共就 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，以上全是我编的，我实在编不下去了……

感觉最大的变化就是现在打开界面飞快

请问这些修改有提 pull request 吗？每个人一处处改还是挺麻烦的，版本更新了又得改一次

你找个接口试试？debug sampler 的逻辑也许不一样

JSON assertion 终于标准化了，可以少装一个插件

influxdb 那个 web 控制台很早就没有了，直接上服务器查

md5 函数在插件里，搜 jmeter-plugins 网站，有个插件叫 custom jmeter functions

因为有很多人的熟悉就是熟悉长矛大刀弓箭嘛，别人都开高达了

我也是在项目里踩过 locust 的坑，确实是皇帝的新装。

真正的问题还不是上面那些，而是这种单线程使用 event loop 的架构不太适合做压测，除非资源消耗非常低。

当单个核跑到 90%+ 或 100%，event loop 会受影响，这程序记录的响应时间就完全不可信。

我是写完脚本压完才发现响应时间一看就完全不可信，用静态页对比一下，其他工具得出的响应时间<10ms，locust 居然得出 300+ms……

而且它占用资源非常多，这边的服务器是 4 核虚拟机，用 20 以上的 vuser 跑，cpu 单核就到 90%+ 了，结果完全不能看。

而且 locust 的作者在性能方面也不专业，不只一个人提过 issue 说 locust 的性能问题了，他们都认为没问题。我把测试结果提 issue，人家直接关了。

后来用回 jmeter 重做了一遍，白白浪费几天时间，坑死了。

不好意思很少上论坛，现在才看到，估计早就解决了吧：P

如果没错误，Error info 是没有数据的。面板上如果显示不正常可以去 influxdb 里查一下数据。查一下有没有 statut 为 ko 的记录。

pct 95 那图表没数据的话看看 db 里有没有叫做 pct95.0 的列。在 JMeter 的 Backend Listener 里有个 percentiles 字段，我是设成 50;90;95;99 ，截图里有。这里写了多少，db 里就会有名为 pctXX.X 的列。如果你删了 95 就不会有那列。

抱歉现在才看到，导入应该能看到 3 个选项，数据源选你自己的 db，然后指定表名和发送间隔（在 JMeter 里默认是 jmeter 和 5 秒，都按默认就不用改这 2 个）。

如果发现 bug 或有改进的建议欢迎随时告诉我。：）

以上全是我编的，我实在编不下去了……

你们是用现成的工具／框架还是自己造轮子？

换工具这种事超级烦，之前的脚本不通用: (
项目里已经用过 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 做了两个项目都没有这么离谱，返回的数字都是比较合理的，今天不清楚什么情况……