Django
優點：
- 大和全（重量級框架）
- 自帶orm，template，view
- 需要的功能也可以去找第三方的app
- 注重高效開發
- 全自動化的管理后台（只需要使用起ORM，做簡單的定義，就能自動生成數據庫結構，全功能的管理后台）
- session功能
缺點：
- template不怎么好用（來自自身的缺點）
- 數據庫用nosql不方便（來自自身的缺點）
- 如果功能不多，容易臃腫
Tornado
優點：
- 少而精（輕量級框架）
- 注重性能優越，速度快
- 解決高並發（請求處理是基於回調的非阻塞調用）
- 異步非阻塞
- websockets 長連接
- 內嵌了HTTP服務器
- 單線程的異步網絡程序，默認啟動時根據CPU數量運行多個實例；利用CPU多核的優勢
- 自定義模塊
缺點：
- 模板和數據庫部分有很多第三方的模塊可供選擇，這樣不利於封裝為一個功能模塊
總結：
要性能， Tornado 首選；要開發速度，Django 和 Flask 都行，區別是 Flask 把許多功能交給第三方庫去完成了，因此 Flask 更為靈活。
綜上所述：
Django適合初學者或者小團隊的快速開發，適合做管理類、博客類網站、或者功能十分復雜需求十分多的網站
Tornado適合高度定制，適合訪問量大，異步情況多的網站
Django 概述
Django 應該是最出名的python框架，Google App Engine甚至Erlang都有框架受它影響。
Django是走大而全的方向，它最出名的是其全自動化的管理后台：只需要使用起ORM，做簡單的對象定義，它就能自動生成數據庫結構、以及全功能的管理后台。
Django提供的方便，也意味着Django內置的ORM跟框架內的其他模塊耦合程度高。
應用程序必須使用Django內置的ORM，否則就不能享受到框架內提供的種種基於其ORM的便利；理論上可以切換掉其ORM模塊，但這就相當於要把裝修完畢的房子拆除重新裝修，倒不如一開始就去毛胚房做全新的裝修。
Django的賣點是超高的開發效率，其性能擴展有限；采用Django的項目，在流量達到一定規模后，都需要對其進行重構，才能滿足性能的要求。
Ruby的Rails也有類似的問題；以Twitter為例，推特到了今日的規模，不要說Rails，甚至是連Ruby都需要拋棄重來。
就我的感覺Django適用的是中小型的網站，或者是作為大型網站快速實現產品雛形的工具。
Tornado 概述
Tornado是Facebook開源出來的框架，其哲學跟Django近乎兩個極端。Tornado是異步框架Tornado基本上只算有MVC中C這一層
Tornado走的是少而精的方向，它也有提供模板功能；雖然不鼓勵，但作者是可以允許在模板進行少量編碼的。
如果跟asp.net相比，Tornado有點類似僅實現了AsyncHttpHandler；除此之外，全部需要自己去實現。
好吧，其實它有模板，有國際化支持，甚至還有內置的OAuth/OpenID模塊，方便做第三方登錄，它其實也直接實現了Http服務器。
但它沒有ORM（僅有一個mysql的超簡單封裝），甚至沒有Session支持，更不要說Django那樣自動化的后台。
假設是一個大型網站，在高性能的要求下，框架的各個部分往往都需要定制，可以復用的模塊非常少；一個以Django開發的網站，各部分經過不斷的定制，Django框架剩下的，很有可能也就是tornado一開始所能提供的這部分。
殊途同歸。
===== HTTP服務器 =====
Tornado為了高效實現Comet/后端異步調用HTTP接口，是直接內嵌了HTTP服務器。
前端無需加apache / lighttpd / nginx等也可以供瀏覽器訪問；但它並沒有完整實現HTTP 1.1的協議，所以官方文檔是推薦用戶在生產環境下在前端使用nginx，后端反向代理到多個Tornado實例。
Tornado本身是單線程的異步網絡程序，它默認啟動時，會根據CPU數量運行多個實例；充分利用CPU多核的優勢。
===== 單線程異步 =====
網站基本都會有數據庫操作，而Tornado是單線程的，這意味着如果數據庫查詢返回過慢，整個服務器響應會被堵塞。
數據庫查詢，實質上也是遠程的網絡調用；理想情況下，是將這些操作也封裝成為異步的；但Tornado對此並“沒有”提供任何支持。
這是Tornado的“設計”，而不是缺陷。
一個系統，要滿足高流量；是必須解決數據庫查詢速度問題的！
數據庫若存在查詢性能問題，整個系統無論如何優化，數據庫都會是瓶頸，拖慢整個系統！
異步並**不能**從本質上提到系統的性能；它僅僅是避免多余的網絡響應等待，以及切換線程的CPU耗費。
如果數據庫查詢響應太慢，需要解決的是數據庫的性能問題；而不是調用數據庫的前端Web應用。
對於實時返回的數據查詢，理想情況下需要確保所有數據都在內存中，數據庫硬盤IO應該為0；這樣的查詢才能足夠快；而如果數據庫查詢足夠快，那么前端web應用也就無將數據查詢封裝為異步的必要。
就算是使用協程，異步程序對於同步程序始終還是會提高復雜性；需要衡量的是處理這些額外復雜性是否值得。
如果后端有查詢實在是太慢，無法繞過，Tornaod的建議是將這些查詢在后端封裝獨立封裝成為HTTP接口，然后使用Tornado內置的異步HTTP客戶端進行調用。