python性能之服务优化的方法解析

初看这个标题,相信很多同学都笑了,python有性能可言么,呵呵哒...确实哦,python其实就是为了快速开发应用而出生的,虽然python的服务都以性能低而闻名全世界,但是总该有优化的地方吧,呵呵哒....

这不,这两天本作者就碰见了这样一个问题,首先自我介绍下,我是干嘛的,肯定是屌丝程序员了,这个猜都不用猜,要不然也不会蛋疼的写这篇文章了,我们组是基础开发组,就是专门开发一些剥离业务的组件让其他部门去用,比如业务监控,业务报警,服务数据采集等等一堆搬砖的活.好了,废话不多说了,估计看到这的也都看烦了...你们真的烦了么

这样滴,我们这有个收集业务数据的组件简称M好啦,首先他要在业务服务器上建个udpserver,然后就静静的等业务的客户端上报数据过来,数据格式是key-value形式的,然而就在最近几天,有人在给业务机器做压测的时候,发现一个问题,随着并发的增加,这个M组件的cpu使用率也在不断上升,擦,这下服务器不愿意了,开始疯狂报警,然后做压测的那个人就找我这来了,巴拉巴拉一堆,意思就是我给业务做压测,你收集数据的组件飚个毛啊......

然而我是那么容易被打倒的么,就解释说当然啊,你在给业务压测的时候,同时你的client也在请求我啊,相当于我的并发量也在上升啊,不飚才怪呢,好吧,说归说,抱着工匠精神,开始找问题吧...

这个M组件是用python写的多线程的udpserver,经本人测试,当并发达到2000的时候,cpu就100%左右了,其实udp相比tcp而言性能已经很高了,不过这个并发还是有点感人啊，改成多进程也试了下，cpu占用还是70%左右，毕竟多进程适用计算密集型的，于是就想到了协程，协程像是一种在程序级别来模拟系统级别 的进程，由于是单进程，并且少了上下文切换，于是相对来说系统消耗很少，而网上的各种测试也表明，协程确实拥有惊人的速度。并且在实现过程中，协程可以 用以前同步思路的写法，而运行起来确是异步的，挺有意思。

听说python有个模块叫做eventlet很强大，eventlet的核心是协程（也叫做green thread）。协程的好处是没有线程开销来的大（比如切换代价很小）。同时协程由于调度都由开发者自己决定，所以对lock的需求就很低了

上面是一个uds(unix domian socket)的例子,这里也是通过一个pool限制资源的使用。当每个请求来的时候通过spawn_n方法把对这个请求的handle方法放到独立的协程中去处理。而handle中的recv这些方法都是被绿化过的，所以如果读取不到数据这些方法就会把cpu时间交出来给别的协程使用,eventlet还有一个衍生品gevent，先看看例子：

上面是官方的例子，gevent是一个基于libev的python并发框架,以微线程greenlet为核心，使用了epoll事件监听机制以及诸多其他优化而变得高效.而且其中有个monkey类, 将现有基于Python线程直接转化为greenlet(类似于打patch)。

我自己测试了下，无论是eventlet写的uds还是gevent写的udpserver 并发达到2000时，cpu大概占用到30%左右，性能比之前降了2/3，效果还是很显著的，不过这个还是没有达到理想效果，后期准备尝试下日志的方式，应该会比现在更省资源，就怕磁盘受不了，更何况我们用的还是所谓的云主机~