这篇文章是去年写的,今个拿出来分享下。

话题是测试下多线程和gevent在socket服务端的小包表现能力,测试的方法不太严谨,也没有用event loop + pool池的概念。不管是gevent和threading有pool的情况下,确实很省资源,但是固定的pool线程池容易在突发事件中被堵塞住。 另外提一句,劲量少用multiprocessing,因为他的进程开销有些大,当然如果单纯用multiprocessing做进程池里面worker进程,那还是个好选择,毕竟他是可以跑多核心的。 

Hello , 另外请大家多关注下,我的个人博客 blog.xiaorui.cc

不管怎么说,还是有点属于自娱自乐的形态,有问题之处,请大家喷之 !


话说,我们当时在搞一个回溯任务中心,说白了就是开发任务接口,通过mapreduce计算平均值,关于业务的逻辑我就不多写了,写出来,也只是浪费大家的思考。干脆点,每个连接都特意堵塞了0.5秒钟。


在大量的tcp短连接测试下,threading的开销越来越大,所以造成了在并发数加大的情况下,出现threading崩溃的情况 !  gevent是 libevent和协程的融合,一个线程里面都可以跑超多的协程! 利用libevent做io堵塞的调度 ,gevent体系下,同一时间只有一个任务在运行 !    

先来测试下多线程:   我们就不加线程池了

用threading跑socket,每个连接堵塞的时间是0.5秒

加到800的时候~ 直接跳出connection reset by peer,这个就是tcp不能正常的建立通信了。 


那我们在开始用gevent来跑socket server服务:

首先下面是并发数值是500的时候!

并发是1000的时候:

当并发到1500的时候:

出现了少量的报错:


gevent 可以加个队列,来限制协程的数目,但是数目限制了,虽然稳定了,但是并发数上不去。

这里测试有点简单,其实我在线上用的方案是prefork+gevent pool,后来因为自己fork出去的进行,不太好互相的通信,pipe实在太难用,所以后来又改用multiprocessing了。 另外监听的机制也把select改成epoll了。 





对Python及运维开发感兴趣的朋友可以加QQ群 : 478476595 !!!
{ 2000人qq大群内有各厂大牛,常组织线上分享及沙龙,对高性能及分布式场景感兴趣同学欢迎加入该QQ群 }

另外如果大家觉得文章对你有些作用!   帮忙点击广告. 一来能刺激我写博客的欲望,二来好维护云主机的费用.
如果想赏钱,可以用微信扫描下面的二维码. 另外再次标注博客原地址  xiaorui.cc  ……   感谢!
暂无相关产品