前言：
這兩天搜文章的時候，發現不少人對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來做靜態文件的分離引入。