初看這個標(biāo)題,相信很多同學(xué)都笑了,python有性能可言么,呵呵噠...確實(shí)哦,python其實(shí)就是為了快速開發(fā)應(yīng)用而出生的,雖然python的服務(wù)都以性能低而聞名全世界,但是總該有優(yōu)化的地方吧,呵呵噠....

這不,這兩天本作者就碰見了這樣一個問題,首先自我介紹下,我是干嘛的,肯定是屌絲程序員了,這個猜都不用猜,要不然也不會蛋疼的寫這篇文章了,我們組是基礎(chǔ)開發(fā)組,就是專門開發(fā)一些剝離業(yè)務(wù)的組件讓其他部門去用,比如業(yè)務(wù)監(jiān)控,業(yè)務(wù)報警,服務(wù)數(shù)據(jù)采集等等一堆搬磚的活.好了,廢話不多說了,估計看到這的也都看煩了...你們真的煩了么

這樣滴,我們這有個收集業(yè)務(wù)數(shù)據(jù)的組件簡稱M好啦,首先他要在業(yè)務(wù)服務(wù)器上建個udpserver,然后就靜靜的等業(yè)務(wù)的客戶端上報數(shù)據(jù)過來,數(shù)據(jù)格式是key-value形式的,然而就在最近幾天,有人在給業(yè)務(wù)機(jī)器做壓測的時候,發(fā)現(xiàn)一個問題,隨著并發(fā)的增加,這個M組件的cpu使用率也在不斷上升,擦,這下服務(wù)器不愿意了,開始瘋狂報警,然后做壓測的那個人就找我這來了,巴拉巴拉一堆,意思就是我給業(yè)務(wù)做壓測,你收集數(shù)據(jù)的組件飚個毛啊......

然而我是那么容易被打倒的么,就解釋說當(dāng)然啊,你在給業(yè)務(wù)壓測的時候,同時你的client也在請求我啊,相當(dāng)于我的并發(fā)量也在上升啊,不飚才怪呢,好吧,說歸說,抱著工匠精神,開始找問題吧...

這個M組件是用python寫的多線程的udpserver,經(jīng)本人測試,當(dāng)并發(fā)達(dá)到2000的時候,cpu就100%左右了,其實(shí)udp相比tcp而言性能已經(jīng)很高了,不過這個并發(fā)還是有點(diǎn)感人啊，改成多進(jìn)程也試了下，cpu占用還是70%左右，畢竟多進(jìn)程適用計算密集型的，于是就想到了協(xié)程，協(xié)程像是一種在程序級別來模擬系統(tǒng)級別 的進(jìn)程，由于是單進(jìn)程，并且少了上下文切換，于是相對來說系統(tǒng)消耗很少，而網(wǎng)上的各種測試也表明，協(xié)程確實(shí)擁有驚人的速度。并且在實(shí)現(xiàn)過程中，協(xié)程可以 用以前同步思路的寫法，而運(yùn)行起來確是異步的，挺有意思。

聽說python有個模塊叫做eventlet很強(qiáng)大，eventlet的核心是協(xié)程（也叫做green thread）。協(xié)程的好處是沒有線程開銷來的大（比如切換代價很小）。同時協(xié)程由于調(diào)度都由開發(fā)者自己決定，所以對lock的需求就很低了

上面是一個uds(unix domian socket)的例子,這里也是通過一個pool限制資源的使用。當(dāng)每個請求來的時候通過spawn_n方法把對這個請求的handle方法放到獨(dú)立的協(xié)程中去處理。而handle中的recv這些方法都是被綠化過的，所以如果讀取不到數(shù)據(jù)這些方法就會把cpu時間交出來給別的協(xié)程使用,eventlet還有一個衍生品gevent，先看看例子：

上面是官方的例子，gevent是一個基于libev的python并發(fā)框架,以微線程greenlet為核心，使用了epoll事件監(jiān)聽機(jī)制以及諸多其他優(yōu)化而變得高效.而且其中有個monkey類, 將現(xiàn)有基于Python線程直接轉(zhuǎn)化為greenlet(類似于打patch)。

我自己測試了下，無論是eventlet寫的uds還是gevent寫的udpserver 并發(fā)達(dá)到2000時，cpu大概占用到30%左右，性能比之前降了2/3，效果還是很顯著的，不過這個還是沒有達(dá)到理想效果，后期準(zhǔn)備嘗試下日志的方式，應(yīng)該會比現(xiàn)在更省資源，就怕磁盤受不了，更何況我們用的還是所謂的云主機(jī)~