只能说 H5 测试越来越火，之前问过我老板，他只说了一句话，“除非是真傻，否则没人愿意把自己的命运完全交给微信”

谢谢分享

分析的很详细，之前在做后台的性能测试时，也遇到了类似的问题，后来受时间限制和项目上线进度限制，临时想的解决方法是多机分布式并发执行，但是最终的数据收集又让人吐血，看了这个分析，受益匪浅，感谢分享！

写的非常不错！可以拓展一下现在的工作思路！

另外一开始我的场景设置，其实并发用户并不高，一开始场景中的 setUp 方法是 rampUsersPerSec(200) during(5 minutes)，之后发现大概跑到 2 分半的时候，就出现大量的连接超时，于是修改了方法变为 constantUsersPerSec(100) during(5 minutes)，再之后发现这个比 rampUsersPerSec() 还不堪，于是最终换成了 atOnceUsers()。

#13 楼 @joshua 感谢答复，事后我自己也查了一下资料并且分析了一下，我的结论也和你的结论差不多，目前就我的环境来看，出现 Connection timed out 就是由于测试本机的链接池耗尽了，因为此时在别的机器请求服务器，返回都很正常。由于 gatling 并不支持分布式，所以后续的性能测试我还是考虑换用 nGrinder 或者是 locust。但是某些特殊的测试要求下，我感觉 gatling 还是一个挺不错的性能测试工具 ：）谢谢！

另外非常想知道楼主是如何达到 20000 的高并发的？这个 20000 的数量是基于 atOnceUsers()，还是 constantUsersPerSec() 这样的方法？谢谢！

很赞，我想请教一下，为什么我跑 constantUsersPerSec(200) during(5 minutes),在测试刚开始的 1-2min 内返回都是正常的，大概到一半时，开始频繁报 j.n.ConnectException: Connection timed out: no further information 这种错误，网上查了一下，出现这种问题最大的可能是本机的 pool connection 耗尽了，这个时候本机单独发请求确实处于 pending 中，但是在别的机器向服务器发请求，链接非常迅速。感觉这里好像有哪个地方没有对。不知道楼主在实践测试过程中有没有遇到过类似问题？