在使用Locust过程时，有时我们会发现当进行高并发压测时，得到的RPS往往会比Jmeter等工具得到的结果更低。
那究竟是什么原因呢？
本文将会针对该问题进行分析并给出解决方式。
问题描述
最近在压测过程中，为了验证Locust本身压测结果准确，我们将其与传统压测工具Jmeter进行比较。
然而，在压测结果比较过程中，我们发现当Jmeter在100并发时可以达到500qps，而利用Locust进行压测时，同样是在100并发时，发现得到的结果只能达到300qps左右。
那么问题出现在哪儿呢？
原因分析
通过查阅大量的资料发现，Locust的client本身是基于python的第三方库requests，然而，requests本身为了简化requests包的使用的便捷，造成了requests的包相对的资源消耗更高。
因此，由于requests本身资源较高，导致发压工具本身的性能消耗过高，从而导致最终的数据并不准备。
解决方式
那么，具体应该如何解决呢？
我们可以通过如下两个方面来进行优化：
- 使用分布式Locust工具进行施压（提高机器的配置）
- 使用Locust的geventhttpclient版本。
首先，我们来讨论方式1：使用分布式Locust工具进行施压并提高机器配置。
显而易见，当我们机器资源提升并使用多机进行分压时，可以保证我们每个机器的资源没有打满，此时，requests包的资源消耗则不会产生较大的影响。
其次，Locust的geventhttpclient版本是专门针对大并发的情况下，requests包性能的优化。在该分支中，Locust的client包没有直接使用requests这个高资源消耗的库，相反，而是直接基于原生的urllib2库进行开发，大幅度降低了资源的消耗。
结论
事实证明，在使用Locust的geventhttpclient版本后，在2核4G的Linux机器中，单机并发在500rps时，性能和Jmeter基本一致。
在超过500rps时，则建议进行多机分布式施压，平均每个实例分压在500rps即可。
Ps：需要注意的是，在进行多机分布式施压时，Master节点仅用于控制，而没有用于发压。
