django flask应用uwsgi和tornado异步回调在项目中的体验

前言:

   这两天搜文章的时候,发现不少人对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个,就可以挑错。不信的朋友可以自己做做测试。

Hello mm, 原文的地址是  ,   blog.xiaoruicc

       而tornado就非常适合做这些个高并发,尤其是io堵塞,comet的东西了

新版支持future做并发库,这里完全就可以写同步的代码了。50个线程数,不够那就加到200,200不够加到500、1000。  我加到1000,每个连接耗时间30秒,照样很稳,不会报错。

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一引入,就可以多进程了。

他的配置如此的简单。。。


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


大家觉得文章对你有些作用! 如果想赏钱,可以用微信扫描下面的二维码,感谢!
另外再次标注博客原地址  xiaorui.cc

6 Responses

  1. orangleliu 2015年10月20日 / 下午12:46

    uwsgi 加个 listen 吧,队列很容易满,默认100太小呀。

  2. no13bus 2015年4月29日 / 下午6:47

    恩,也就是说css js都交给nginx来处理就好了。 框架自己的模板写法 {{ STATIC_FOLED}}/js/aa.js 是不推荐的。

    • 峰云就她了 2015年4月29日 / 下午7:41

      对的,尽量用绝对地址,这样以后也好切分流量到cdn上

  3. no13bus 2015年4月26日 / 下午9:16

    最后一段话没看明白,意思是说 nginx做静态文件的支撑,也就是nginx一般都会配置的 location /static { 静态文件夹的路径 }然后静态文件引入的时候 都是 而不是 . 是这个意思吗?

    • 峰云就她了 2015年4月27日 / 上午10:36

      需要把静态的你在location处理,不然的话,你的动态和静态的访问都会利用代理的方式推送给uwsgi

发表评论

邮箱地址不会被公开。 必填项已用*标注