在各种各样语言表达服务平台中，python不断涌现的web框架也许是最大的；猜测缘故应该是在py中结构架构十分简易，促使车轮子持续被创造发明。
这儿记叙一下我掌握过的2个py web框架，供各位参照，期待能开它山之石的功效。
Django
Django 应该是最闻名的py架构，Google App Engine乃至Erlang都是有架构受它危害。
Django是走专而精的方位，它最知名的是其全智能化的后台管理系统：只要应用起ORM，做简易的目标界定，它就能自动生成数据库查询构造、及其多功能的后台管理系统。
Django给予的便捷，也代表着Django内嵌的ORM跟架构内的别的控制模块藕合水平高。
应用软件务必应用Django内嵌的ORM，不然就无法享有到架构内给予的诸多根据其ORM的便捷；理论上可以转换掉其ORM控制模块，但这就等同于要把室内装修结束的房屋拆卸再次室内装修，还不如一开始便去毛胚房做全新升级的室内装修。
Django的产品卖点是极高的研发高效率，其特性拓展比较有限；选用Django的新项目，在总流量做到一定经营规模后，都必须对它进行重新构建，才可以达到特性的规定。
这方面的工作经验可以参照：http://www.slideshare.net/zeeg/djangocon-2010-scaling-disqus
Ruby的Rails也是有相似的问题；以Twitter为例子，twiter到了今日的经营规模，不要说Rails，乃至是连Ruby都必须抛下重新来过。
就我的觉得Django适用的是大中小型的网址，或是是做为商业网站迅速完成商品发展历程的专用工具。
迅速发布商品是关键：
Believe it or not, the bigger problem isn't scaling, it's getting to the point where you have to scale. Without the first problem you won't have the second. - http://gettingreal.37signals.com/ch04_Scale_Later.php
===== Django 模版 =====
Django的模板系统开发十分有趣，也应当其架构内危害较大、异议最高的一部分。
Django模版的设计理念是完全的将编码、款式分离出来；asp.net倡导将编码/模版分离出来，但技术性上也是可以混和；而Django则是从源头上避免在模版中开展编号、解决数据信息的很有可能。
比如说，asp.net模版中可以写：
<%
int i;
for(i==0;i<10;i ){
....
}
%>
Django是完全不兼容置入相近上边的编码，仅能应用其模版内嵌的函数公式；这事实上，是为其模版结构了一种“新语言表达”；因为此“新语言表达”十分简易，因此也可以将其模版移殖到不一样服务平台。
大部分情形下，Django的模版作用是充分的，但针对独特（有时候“独特”也不是十分特殊）的状况，或是必须在模版中置入编码，那麼就要按照其模版系统软件的标准做模版拓展。有时，模版中立即写一行编码可以处理的问题，用模版拓展完成后，会变为十几行编码。
是不是忍受在模版中程序编写，恰好是Django模版异议较大之处。
Tornado
Tornado( http://www.tornadoweb.org )是Facebook开源系统出去的架构，其哲学思想跟Django几近两个极端。
Tornado走的是专而精的方位，它也是有给予模版作用；尽管不激励，但作者是可以可以在模版开展小量编号（立即置入单行py编码）的。
假如跟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手机客户端开展读取。
