WRK 的结果怎么看？

如图：

• Latency：表示的是响应时间（需要在命令中添加 --latency），顺序分别是： 平均值，标准偏差，最大值，正负标准差；

其中，平均值，最大值，有一定参考意义，如果标准偏差越小，一定层面能反应待测的接口是比较稳定的

• Req/Sec：表示的是每个线程每秒的完成的请求数，顺序分别是： 平均值，标准差，最大值，正负标准差；

参考价值与响应时间类似

链接数和线程数应该设多少？

先上结论：
-t（线程数）：
一般是 CPU 核数，最大不要超过 CPUx2 核数，否则会带来额外的上下文切换，将线程数设置为 CPU 核数主要是为了 WRK 能最大化利用 CPU，使结果更准确
-c（连接数）：
连接数（connection）可以理解为并发数，一般在测试过程中，这个值需要使用者不断向上调试，直至 QPS 达到一个临界点，便可认为此时的并发数为系统所能承受的最大并发量。
实际上，wrk 会为每个线程分配（c/t）个 socket 连接，每个连接会先执行请求动作，然后等待直到收到响应后才会再发送请求，这个日后会有关于 wrk 的源码解析方便理解，所以每个时间点的并发数大致等于连接数（connection）

连接数（c）与 QPS（q），请求响应时间毫秒（t）的关系大概可理解为：q = 1000/t * c
RTT 为 1ms，如果 c（连接数）为 1，则理论上 QPS 接近 1000，如果 c（连接数）为 100，则 QPS 接近 10w
RTT 为 10ms，如果 c（连接数）为 1，则理论上 QPS 接近 100，如果 c（连接数）为 100，则 QPS 接近 1w

但是服务有自己的负载极限，并发数不能无限放大，这就能解释有的时候连接数越大，反而 QPS 越低，是因为并发数已经设的过高，导致待测系统已经超出自身能承受的负载

WRK 对比 JMETER 和 AB，各个的极限究竟怎么样？

结论：
WRK 与 AB 性能最好，300 并发下，QPS 最高都可达到 19w，但 WRK 资源消耗适中（cpu 涨幅最高 9%），而 AB 资源消耗较高（cpu 涨幅最高 42%）
JMETER 相同并发下，QPS 最高可达到 8.6w，资源消耗较高（cpu 涨幅最高 42%）

施压机：CPU（24 核，E5-2620 2.40HZ）
压测对象：nginx 自定义的接口

WRK：线程数 = 24，并发数 = 300，QPS = 193000，响应 99Line 为 2.74ms，CPU 波动峰值 9%

AB：并发数 = 300，QPS = 197000，响应平均 2ms，CPU 波动峰值 42%

JMETER：并发数 = 300，QPS = 86000，响应平均 3ms，CPU 波动峰值 42%

WRK，JMETER，GATLING 该怎么选择？

场景不复杂，需要快速进行压测验证，HTTP/HTTPS 协议：
推荐使用 WRK，性能佳，且通过 lua 脚本能制定简单的测试脚本（比如参数化，自定义上报结果等），但是只能针对 HTTP、HTTPS 协议接口，具有功能的局限性
场景复杂，需要测其他协议：
使用 Jmeter，性能不足，机器来凑
而 GATING 虽然性能也不错，但劣势主要在于 scala 具有一定学习成本，且其非商业版不支持分布式的执行

总结

WRK 个人认为非常适合作为一款压测工具，其代码量并不太多，且不复杂，可适当对其进行魔改以适应各自的特殊需求
源码阅读可跳转：wrk 源码阅读