前言：
这两天搜文章的时候，发现不少人对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来做静态文件的分离引入。
