百度吧，不用想。
你这个级别的开发去了也是增删改查，没区别，创业公司有都是业务代码让你写，写到麻木。

我以为没人看呢……

1.主要是 python 语言和 Java 语言（解释型和编译型）自身的性能差距吧。还有一些其它的优化原因，主要有 JVM 的垃圾回收算法比 python 的先进，JVM 的 JIT 即时编译。
2.还有关于你的测试数据，10 个线程这种体量的并发，太弱了，你可以试试单线程搞 10000 次，可能都比 10 个线程的好。我们讲压力测试都是几百几千甚至集群的上万的线程这种压力。
3.还有真正的压测，脚本逻辑都是比较复杂的，比如创造数据，数据关联等等，逻辑和处理都会比较复杂，这时候 python 语言和 Java 语言的自身性能差异就会更明显了。换句话说，你的测试数据，对于真正的压测场景，代表性还有待商榷。
4.关于协程和线程这个还不好说的，协程相当于把用户端来处理多线程（一个线程达到多线程切换的效果），多线程是操作系统来处理多线程（用户端程序不管这个事情直接调用操作系统的接口来实现多线程）。Java 没有协程是有原因的，因为用户端来处理多任务的切换逻辑，毕竟是在操作系统上层搞的事情，一是需要对操作系统 CPU 命令等非常了解，二是要适配多种环境多种操作系统多种 CPU，成本是很高的。Java 是讲究跨平台和高性能（接近于 C 的性能）的，协程 Java 觉得不行。总之，就是不要太迷恋协程的性能，python 不存在多线程的，它是只能用协程。建议还是具体问题具体环境具体分析。python 语言的优势在书写和语法糖，不在性能。
5.说了这么多，其实压力端对性能的要求很高的，一般语言不能胜任。如果你有兴趣，可以搞搞 GO 语言的压力端，GO 语言是支持协程的。locust 的作者自己都说高压力的压测要求 locust 不支持，咱们就别纠结这个了。

很赞！

查了一下 Jmeter4 的源码，其中的停止也是 TimeUnit.MILLISECONDS.sleep(pause); 本质也是 Thread.sleep()。

简单看了描述，我这里总结及猜测一下，应该 8 9 不离十。
楼主觉得奇怪的地方：
为什么相同的接口实现，仅仅是加了 200ms 的延时，为什么总 TPS 就涨不上去了？
为此，你先搞压力端，排除了压力端的原因。
你接着分析服务器端，发现 CPU，内存，网络啥问题也没有，“基本排除” 了服务器端的问题。
表示奇怪。
你还在搞 Jmeter，打算换一种工具。可惜结果不会有变化。

其实不奇怪。
你 200ms 的延迟是加在了 Java 实现里，使用的是 new Thread().sleep(200)， 此方法及其耗费 Java 线程资源。因为你是 spring boot 的自带启动，本身的线程总数就不多，还用了这么消耗线程资源的方式来实现延时，服务器性能会大大降低。
如果你能监控到 JVM 进程中的线程状态，会发现都是 block 或者 wait。
说白了，服务器性能不行，不是因为硬件资源不行，而是被你的代码强制的暂停住了。

解决方式：

1. 200ms 的延迟放到压力端去实现，不要放在服务器端。
2. 如果还是要压力端实现，把 spring boot 给换了，换成 tomcat 等其他，但记得调优 tomcat 等其他。

多谢肯定。
实时监控的开源产品太多了，最近我还发现了一个 ：

https://github.com/AsuraTeam/monitor

这方面要考虑的太多，自己实现很难专业。
另外提到的 报表分析 ，如果做出来确实很牛，就像 听云 ，但是到这步就很难开源了， 是可以赚钱的了。

还有，你这么牛，你去文章中找其他问题去，别这里有个人回复了，你就来喷来找茬，你搞点儿新鲜的。
我的回复不是给你划重点让你深刻思考的。
你这样的还没有实锤的，纯蹭热度。

1.真不知道你在这强调什么，还是就没看懂问题。
https://www.zhihu.com/question/36996520
https://tech.meituan.com/mysql_index.html

“顺序是有影响的”，把实锤放出来。最左前缀匹配原则是有 mysql 的内部实现算法支撑的，你的 “顺序是有影响的”，依据是什么？

1. “并且应尽可能的让字段顺序与索引顺序相一致。”，这个是不必要的，mysql 会自动排序。
2. 存储过程，游标，触发器，都是不推荐的，可以忽略。
3. in 是走索引的。
4. “一切的 > < != 等等之类的写法都会导致全表扫描” 大于号小于号应该是可以走索引的。

建议先查一下 explain。
另外，去搜索一下 otter，类似的技术你这里没提。
你引用的技术帖子已经很老了，觉得能落后 5 年，建议多看看。

外国人的轮子啊……不知道也是基于 Jmeter 的吗？
我文中写了不少为什么我要再开发一套的原因，要不你参考一下，然后告诉我 Taurus (Blazemeter reporting services ) 是不是都满足了。

额，这种提到 issue 里吧……然后堆栈完整一点儿。
看错误是比较简单的，数据库字段不能为 null。我本地是可以的，当然完整堆栈能看出是什么问题。

好的，

了解了，压测任务确实各有不同，不过只要是使用 Jmeter 的脚本，都可以上传到这个平台上进行压测。
至少可以做到：

1. 脚本的统一保存。
2. 生成 Jmeter 自带的测试报告，并在线查看。
3. 通过复制镜像，生成完备的压力节点机，然后配置到平台上，一键启停。

如果你们的测试报告都是自己整理的，那么你们可能需要完备的监控截图，而我的平台监控截图比 grafana 的清晰了不少，你们可以作为参考。

也有道理！
不过平台的初衷之一是让开发等不专业的也可以执行性能测试，我们仅是管理测试脚本，管理权限就好。

你好，是接口请求的内容保存在数据库里，所以才需要读数据库。
并不是接口返回的预期值保存在数据库中。

提几个建议吧，你的代码实现：

1. 写好注释，让代码可读性更强。
2. 代码良好的设计，比如要穿插 Post 等，Http 请求头不同，Https 协议等等，代码如何更优雅。
3. 接口返回值比对是在接口成功返回之后做的事，而接口的成功返回需要各种各样的断言，要加上。

有你分享的时间，我 Jmeter 都干完活了……行了大兄弟，别在我这掰扯这些了。
我文中写的那么多 Jmeter 的优点看来在你眼里都是 P 啊……“Jmeter，功能太丰富了，比如正则表达式，自定义变量，参数化，性能测试，定时执行等等。 这基本满足所有复杂的接口测试要求，自开发这些工具真的比不了。”
我期待你在 github 上的开源。

写的不错，大势所趋。

这个回答做到了：
talk is cheap show me the code.
这套代码工具，可以解决读接口的比对问题，也是我文中所面对的问题。
当然我的 Jmeter+Ant 还是有其优势的：

1. 接口测试请求链接数据不是数据库/文本等等已经保存好的，需要新创建测试数据。
2. 请求和请求之间存在数据关联。即和上面第一种情况结合起来。

至少这两种情况，Jmeter 还是比较方便的。
我不展开了，我相信 python/node.js 能做到。

好的。我文中就是这么做的。

谢谢版主肯定。

你的一个连数据库的函数 + 一个循环 再加上 @hu_qingen 的接口测试 [JsonSchema] 关于接口测试 Json 格式比对核心算法实现 (Java 版) 这应该就是你写的 “一个断言” 的完整实现。

至于重构怎么改变大小写了，你很感兴趣……可能测试的工作就是这样吧，面对的是各种各样的问题。
没别的意思，我觉得我的这篇至少引发了你对解决问题的思考，并且你也感兴趣了，我觉得就很好。

不错，学习了。