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了。 

猜你喜欢

转载自www.cnblogs.com/leijiangtao/p/11946127.html