【实测】如何用python3来做压力测试引擎？

实测系列都是作者亲自实验测试调试出来的精品代码，收藏价值很高哦~

一提起压测，就免不了涉及底层并发线程。而一旦有人问底层的引擎用什么语言来写的时候，就会有回答说用java的，有用c的，还有用go的，甚至还有用js的.... 虽然众说纷纭，但是也有一个共识，那就是没人用python来做，原因也只有一个，python的并发能力并不好。

上面这个答案，无论是会python的，还是不会python的，无论是写过python并发的大佬还是没写过的小白，都会认同。以至于一直主修python的同学都会有意的避开压测平台的开发，还没尝试，便已认输。

但是有没有可能，这种现象是一种盲从和跟风呢？没真正自己写过压测引擎的同学也为了凸显自己很懂，就会附和着说python并发不行，不适合做压测呢？

作者之前也不确定，毕竟没有亲手做过。但是有一点可以肯定，就是如果用python的话，可以做到非常非常灵活，可以灵活的精确的控制每一个压测阶段的并发，可以实现各种和线上真实用户行为的压力，说通俗点，就是做全链路压测会很简单。

那么现在的唯一问题就是，python的底层并发效果，到底能支持多少呢？能不能覆盖中小公司的软件的压测任务呢？可能公司的接口大多并发一百就完了，好点的并发五百，需求也只是三百而已，而python再差，也远远高于这个数据，就是可以轻松覆盖一般的压测需求呢？实在不行，还可以多压力机配合使用来保证呢？

为了给广大同学做实验，来真正看一看python到底能不能做压测引擎，本期就来开发一个吧。

首先新建一个项目和py文件：yingqing.py

我们即将在这个文件里写上咱们的第一个简单引擎【常量压测】

常量压测：即每秒发送的请求是恒等的

round变量： 轮数，每秒发一轮，Jmeter默认也是1秒均匀发出所有线程数

num变量：每轮的并发数

script方法：模拟被执行的请求，只输出被执行的瞬间时间

one_round方法：每轮的引擎

play方法：主引擎，入口函数。

脚本如下：

我们一共压3轮，每秒发出一轮，每轮压10个并发。来看看输出结果。

从上图中，可以发现，三轮的表现都很完美。92秒的时候10次，93秒的时候10次，94秒的时候10次。和预期是一样的。

让我们把数据拉大... round依然是3，num变成100。

输出结果：

中间省略...

中间省略...

中间省略...

从上面结果可以看出，100并发的时候，依然是成功的.... 没有任何延迟，三轮都很完美。

我们继续把数据拉大，round=5轮，num=500并发

结果如下：第一轮的起：第58秒

第二轮起：第59秒

第三轮起：第60秒

第四轮起：第61秒

第五轮起：第62秒

结束最后：第62秒

从结果看出，5轮500并发，依然结果完美。均在一瞬间推出请求。几乎没有延迟。

后面的测试我就不给一一贴图了。直接说结论：

大概单轮超过28000(2.8万)并发的时候，才超过了一秒的时间。这个数据恐怕早就远远覆盖超过了99.99%的压测需求了吧？而这，还仅仅是一个进程下的多线程。如果启用电脑的全部核心的全部进程。那这个并发量会非常可怕的大。而且还可以多台压力服务器一起来配合执行某个压测需求。那样甚至可以覆盖到一些秒杀活动的压测需求哦~

所以实际上，用python来做底层压测引擎不是不可以，主修python的同学可以放心的进入压测领域了哦~

尾语：就像小马过河的故事，不要人云亦云，凡事有条件就亲自尝试一下，结果可能好，也可能坏。但是尝试的过程你会学到很多，成长很多。