django在nginx uwsgi和tornado異步方案在項目中的體驗

原創做品，容許轉載，轉載時請務必以超連接形式標明文章  原始出處 、做者信息和本聲明。不然將追究法律責任。 http://rfyiamcool.blog.51cto.com/1030776/1397495

前言：

   這兩天搜文章的時候，發現很多人對tornado有些誤解的。只是想說說本身對於這些框架的理解，和實際項目中的對比。

 

   部分有文章說tornado性能很通常，我當時一瞅，非常鬱悶，這些人是怎麼測試的呢，就直接跑hello world。很直接就用tornado最最基本的功能，那他的性能也就和django flask同樣了。這樣沒太多的意義，我的以爲，應該儘可能施展他們的長處，固然也要把他的短處給扔出來。

 

       我想說的是，在必定程度上，你沒有用好。tornado最大的優勢是大併發下的異步io，他有coroutine，這是個比thread線程切換開銷更小的東西，可讓tornado那些回調的代碼顯得更同步順眼。還有一個異步回調的東東，這些組成了tornado在高併發下也能夠避免網絡io堵塞。

在用django、flask的時候，我也喜歡用gevent、Gunicorn、uwsgi。 如今更多的人喜歡用uwsgi，由於簡單易用，藉助於nginx能夠作更多的東西。好比加上lua，就能夠作數據接口，用location就能夠作讀寫分離等。可是你們有沒有發現，uwsgi在超過必定的鏈接數後，尤爲是那種長鏈接，他就瘋狂的報錯，要不是socket pipe出錯，要不就索性的502。

   

       線程開啓64個，我這裏是特地開了64了，官方的推薦是你cpu核數的2-4倍，那是我以爲這個值不靠譜，仍是往大了加。ab一個time.sleep(10)的接口，超過150個，就能夠挑錯。不信的朋友能夠本身作作測試。

原文：http://rfyiamcool.blog.51cto.com/1030776/1397495

       而tornado就很是適合作這些個高併發，尤爲是io堵塞，comet的東西了

新版支持future作併發庫，這裏徹底就能夠寫同步的代碼了。50個線程數，不夠那就加到200,200不夠加到500、1000。  我加到1000，每一個鏈接耗時間30秒，照樣很穩，不會報錯。

 

1 2 3 4 5 6 7 8 9 10 11 12 13

class  IndexHandler(tornado.web.RequestHandler):      executor = ThreadPoolExecutor( 50 )                                     @tornado.gen.coroutine      def  get (self):          print  "begin"          #time.sleep( 10 )          yield self.pin()          self.write( 'ok' )          self.finish()      @run_on_executor      def pin(self): #        os.system( "ping -c 10 www.baidu.com" )          time.sleep( 2 )

 

固然他的缺點也很明顯，就是須要你打造輪子。他的文檔也特別的少，你會發現跑到官網作demo，他們連個cookie說的都不清不白的，結果還要到github去找幾個例子，才搞懂。

 

django是個好東西呀，你能想到的功能，均可以在django插件index看到你須要的。  各類各樣的都有， 作大項目仍是須要用django這樣較完成的框架。  你要是有知乎那幫團隊的實力，你也能夠用tornado來支撐你的大項目。  我不喜歡django的緣由，只是由於他複雜，不簡單而已。 

 

推薦用tornado作接口，而django flask作先後端的開發。 tornado性能雖然高，可是部署有點繁瑣( ningx + tornado * 4 的方式)，寫程序有點蛋疼，須要寫異步回調。不像flask那樣，你所有同步的寫法，最後用nginx uwsgi一引入，就能夠多進程了。

他的配置如此的簡單。。。

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

http: //xiaorui.cc [uwsgi] socket =  127.0 . 0.1 : 9090 master =  true          //主進程 vhost =  true           //多站模式 no-stie =  true         //多站模式時不設置入口模塊和文件 workers =  64            //子進程數 reload-mercy =  10   vacuum =  true          //退出、重啓時清理文件 max-requests =  30000 limit- as  =  2048 buffer-sizi =  30000 pidfile = / var /run/uwsgi9000.pid daemonize = /website/uwsgi9000.log 避免文件最大打開數限制 ulimit -SHn  30000

 

不論是tornaod、django、web.py、flask，他們靜態處理能力都通常。最簡單的方法測試，你用ab壓一個靜態文件，流量壓根上不去，其次是出broken pipe的標準socket的error。 你正好開了10個uwsgi的worker後。你的頁面有好幾個css，js，那！ 若是有10我的來訪問，那就佔用了uwsgi的10個線程。若是這個時候有不少用戶來訪問，你確定會io堵塞的，你能夠試試 ！    

    在一些平臺中，要避免靜態文件的損耗，這些靜態的文件最好是用url的方式引入，這樣後期能夠作cdn啥的，把這些靜態的東西儘可能扔給gninx lighttpd處理，若是程序已經成型了，那就用nginx的localtion來作靜態文件的分離引入。