实测系列都是作者亲自实验测试调试出来的精品代码，收藏价值很高哦~
一提起压测，就免不了涉及底层并发线程。而一旦有人问底层的引擎用什么语言来写的时候，就会有回答说用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的同学可以放心的进入压测领域了哦~
尾语：就像小马过河的故事，不要人云亦云，凡事有条件就亲自尝试一下，结果可能好，也可能坏。但是尝试的过程你会学到很多，成长很多。
广告：这个压测引擎 只是一个常量压测。
其实还可以进阶改造成持续增压，瞬时增压，阶梯增压，无限增压，高低转换等模式。
还可以升级成多阶段，多轮，多语言脚本多函数多接口请求的 超灵活引擎。说到底，一个人足以开发出来了。也可以完全覆盖各种中小型企业的压测需求了。
当然这些功能，在作者的私人培训班中早已实现并教学，其中用到的很多三方组件为限定原创，仅学员和粉丝可用。如果感兴趣的，可以加v : qingwanjianhua 来咨询培训哦~
进粉丝群加v: qingwanjianhua
