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

请问招专职性能测试不？

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