在Centos下對高併發web框架Tornado的性能進行測試

原文轉載自「劉悅的技術博客」v3u.cn/a_id_89

在以前的一篇文章中，咱們在1g1核的慘淡硬件環境下，對 uwsgi + django 和 gunicorn+ django 的後端服務進行性能測試，得出結論單臺django在簡單讀庫操做下只能抗住大約200左右的併發:在Centos下使用Siege對Django服務進行壓力測試

這一次，咱們在相同的背景下，對三大框架中，以性能著稱於世的Tornado進行併發測試，看看它的性能到底有多高。

Tornado是一個用Python編寫的異步HTTP服務器，同時也是一個web開發框架。

Tornado 優秀的大併發處理能力得益於它的 web server 從底層開始就本身實現了一整套基於 epoll 的單線程異步架構。

那麼，到底啥是特麼的異步非阻塞呢？

同步、異步編程差別：

你打電話問書店老闆有沒有《python開發》這本書，若是是同步通訊機制，書店老闆會說，你稍等，」我查一下"，而後開始查啊查，等查好了（多是5秒，也多是一天）告訴你結果（返回結果）。

而異步通訊機制，書店老闆直接告訴你我查一下啊，查好了打電話給你，而後直接掛電話了（不返回結果）。而後查好了，他會主動打電話給你。在這裏老闆經過「回電」這種方式來回調。

阻塞與非阻塞的差別：

仍是你打電話問書店老闆有沒有《python開發》這本書，你若是是阻塞式調用，你會一直把本身「掛起」，直到獲得這本書有沒有的結果

若是是非阻塞式調用，你無論老闆有沒有告訴你，你本身先一邊去幹別的了， 固然你也要偶爾過幾分鐘check一下老闆有沒有返回結果。

大部分Web應用都是阻塞性質的，也就是說當一個請求被處理時，這個進程就會被掛起直至請求完成，好比Django,而Tornado的思想是當咱們在等待結果的時候不阻塞，轉而咱們給框架一個回調函數做爲參數，讓框架在收到結果的時候經過回調函數繼續操做。這樣，服務器就能夠被解放去接受其餘客戶端的請求了。

首先，安裝Tornado

pip3 install tornado
複製代碼

編寫main.py

import tornado.ioloop
import tornado.web
import pymysql

db =  pymysql.Connection(host='127.0.0.1', database='md', user='root', password='mysql',charset='utf8')

class MainHandler(tornado.web.RequestHandler):

    def initialize(self,db):
        self.db = db

    def get(self):

        cur = db.cursor()

        cur.execute("select id from news where id = 1 ")
        res = cur.fetchone()
        print(res)

        self.write("Hello, world")

def make_app():

    #路由
    return tornado.web.Application([
        (r"/", MainHandler,dict(db=db)),
    ])

if __name__ == "__main__":
    app = make_app()
    app.listen(8000)
    tornado.ioloop.IOLoop.current().start()
複製代碼

邏輯很簡單，從數據庫中讀取一條數據，經過接口返回，服務監聽8000端口

運行服務

python3 main.py
複製代碼

Tornado不一樣於Django，它自己是框架，同時也是一款服務器，因此不須要uwsgi這種網絡模型服務。

開啓壓測命令：每秒255個請求持續一分鐘

siege -c255 -t60S -v -b 127.0.0.1:8000
複製代碼

能夠看到，每秒處理近800個請求毫無壓力，和Django根本就不是一個量級的，對於高併發問題，咱們一般用C10K這一律念來描述。C10K—— Concurrently handling ten thousandconnections，即併發10000個鏈接。對於單臺服務器而言，根本沒法承擔，而採用多臺服務器分佈式又意味着高昂的成本，django併發數200左右，而Tornado能承擔近800左右，無疑，在成本上節約了不少。

原文轉載自「劉悅的技術博客」 v3u.cn/a_id_89