socket服务端开发之测试使用threading和gevent框架

socket服务端开发之测试使用threading和gevent框架

话题是测试下多线程和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了。 

 

posted @ 2019-11-27 22:42  南哥的天下  阅读(541)  评论(0编辑  收藏  举报