這也是FriendFeed開發(fā)Tornado的原因-----因為FriendFeed需要實時更新Timeline，而Comet又是目前最好，最流行的方法。由于知乎也有大量長輪詢連接需要維護，所以選擇Tornado也就在情理之中了。
但是我們也要看到，Tornado不是萬金油，由于Tornado的WEB服務(wù)器為單線程，一個Request如果阻塞了I/O，那么這個進程將一直掛起，既無法接受新的Request，也無法Finish正在阻塞的其它Request。雖然可以Spawn多個Tornado進程，但是進程這種重量級的東西，Spawn太多會消耗大量的內(nèi)存資源。這種感覺很像PHP的FastCGI進程那種味道。所以如果是會阻塞I/O的Request一般都是利用Tornado內(nèi)置的異步HTTP Client交給其它動態(tài)后端來做。
所以Tornado在生產(chǎn)中一般前面都要包一層nginx做反向代理，用nginx來做靜態(tài)文件等大數(shù)據(jù)量的I/O操作。Tornado的I/O時間實在是太金貴了，在這上面耗不起。
至于你提到的Tornado文檔少的問題，我覺得你可以抽空閱讀一下Tornado的代碼，畢竟是個輕量級框架，代碼不多，但是注釋卻很詳細(xì)，很容易看懂。請記住，代碼永遠是最好的文檔！