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来作静态文件的分离引入。