Django 项目是一个定制框架，它源自一个在线新闻 Web 站点，于 2005 年以开源的形式被释放出来。Django 框架的核心组件有：
用于创建模型的对象关系映射
为最终用户设计的完美管理界面
一流的 URL 设计
设计者友好的模板语言
缓存系统
http://docs.djangoproject.com/en/dev/
最近做的一个网站项目，开发语言使用的是python，框架是django，django的开发效率毋庸置疑，在效率上可谓非常之快，然而框架的易用性也增加了框架内部实现的复杂性，必然导致性能的下降。
来源：http://calmness.javaeye.com/blog/378082
最近很多朋友都在讨论系统性能相关的问题，大部分问题都是围绕着应用层面的缓存，而本文则希望从另一个角度探讨提升系统性能的问题，希望能够起到抛砖引玉的作用。
最近做的一个网站项目，开发语言使用的是python，框架是django，django的开发效率毋庸置疑，在效率上可谓非常之快，然而框架的易用性也增加了框架内部实现的复杂性，必然导致性能的下降。一开始我们对框架的ORM部分进行了重写，在一定程度上减少了ORM的复杂度，提升了部分性能。然而这还远远不够，由于网站的需求变更，需要为几个其他公司的产品提供数据服务，而在未来可能会有更多的厂商接入网站，旧有的使用django模板生成html的方式并不能够很好的满足此需求，因此我们决定使用XSLT+XML将展现与数据分离，如此一来，我们即可满足对外提供数据的需求。
由于应用本身逻辑的关系，我们的数据以及展现样式都不会经常变更，实时性不强，因此静态化则是我们最佳的选择，由于目前主流的浏览器都支持XSLT，为了尽量减少服务端的压力，我们同时也决定将页面的渲染交由客户端来实现，而服务端仅仅生成XML和XSLT的静态文件，而不做XSLT渲染。
以上则是整个应用在表现层做的主要的修改，Django模板渲染的性能到底有多差呢？在实现了XSLT方式后，我做了一个简单的测试，其实我们在第一次生成XSL文件的时候，是通过使用django自身提供的模板进行生成的，只是我们在前端nginx服务器做了一个拦截，当发现xsl存在时，则直接获取，否则就跑fastcgi通过django模板生成xsl，这个测试很简单，测试django模板渲染的时候，我就把生成静态缓存的代码注释掉，保证每次访问时nginx都无法获得静态资源即可每次请求都会跑到django进行渲染。考虑到本次测试只是为了测试django渲染模板的性能，因此另一个测试也必须每个请求都要通过django，只是不进行模板的渲染，因此两个测试的流程如下：
1、模板渲染测试
每次请求xsl文件，都通过django，并进行模板渲染
2、不使用模板渲染
每次请求xsl文件，都通过django，但不进行渲染，渲染结果直接从缓存获得
注：以上两个测试都是跑动态请求，不是静态页面请求。
经过测试后，发现性能的差别远远大于我的预计，渲染的性能，在同等条件下，每秒为110TPS（对于TPS的解释，请看我的另一篇文章《性能测试中带宽的影响》），而通过缓存获取xsl的性能则是190TPS左右，性能的差距非常大，相差了差不多一倍，如此巨大的差距倒是出乎我意料之外，不过本次测试只是针对于django自带的模板引擎进行的测试，并不代表其他模板引擎的性能也是如此，等有时间的时候，我再对其他的模板引擎进行相同的测试，相信应该不会差别如此大，毕竟django模板性能差是众所周知的。
可惜的是，本次测试只是对django的模板渲染进行了测试，并没有对xslt渲染进行测试，时间关系，再加上自己比较懒，还是等下次再对xslt渲染进行一次测试，不过有一点是可以肯定，客户端渲染xslt绝对会降低服务端的压力，毋庸置疑，有兴趣的朋友可以自己测试一下，再把结果告诉我，这样我也不用自己去测试了，呵呵。
用于创建模型的对象关系映射
为最终用户设计的完美管理界面
一流的 URL 设计
设计者友好的模板语言
缓存系统
http://docs.djangoproject.com/en/dev/
最近做的一个网站项目，开发语言使用的是python，框架是django，django的开发效率毋庸置疑，在效率上可谓非常之快，然而框架的易用性也增加了框架内部实现的复杂性，必然导致性能的下降。
来源：http://calmness.javaeye.com/blog/378082
最近很多朋友都在讨论系统性能相关的问题，大部分问题都是围绕着应用层面的缓存，而本文则希望从另一个角度探讨提升系统性能的问题，希望能够起到抛砖引玉的作用。
最近做的一个网站项目，开发语言使用的是python，框架是django，django的开发效率毋庸置疑，在效率上可谓非常之快，然而框架的易用性也增加了框架内部实现的复杂性，必然导致性能的下降。一开始我们对框架的ORM部分进行了重写，在一定程度上减少了ORM的复杂度，提升了部分性能。然而这还远远不够，由于网站的需求变更，需要为几个其他公司的产品提供数据服务，而在未来可能会有更多的厂商接入网站，旧有的使用django模板生成html的方式并不能够很好的满足此需求，因此我们决定使用XSLT+XML将展现与数据分离，如此一来，我们即可满足对外提供数据的需求。
由于应用本身逻辑的关系，我们的数据以及展现样式都不会经常变更，实时性不强，因此静态化则是我们最佳的选择，由于目前主流的浏览器都支持XSLT，为了尽量减少服务端的压力，我们同时也决定将页面的渲染交由客户端来实现，而服务端仅仅生成XML和XSLT的静态文件，而不做XSLT渲染。
以上则是整个应用在表现层做的主要的修改，Django模板渲染的性能到底有多差呢？在实现了XSLT方式后，我做了一个简单的测试，其实我们在第一次生成XSL文件的时候，是通过使用django自身提供的模板进行生成的，只是我们在前端nginx服务器做了一个拦截，当发现xsl存在时，则直接获取，否则就跑fastcgi通过django模板生成xsl，这个测试很简单，测试django模板渲染的时候，我就把生成静态缓存的代码注释掉，保证每次访问时nginx都无法获得静态资源即可每次请求都会跑到django进行渲染。考虑到本次测试只是为了测试django渲染模板的性能，因此另一个测试也必须每个请求都要通过django，只是不进行模板的渲染，因此两个测试的流程如下：
1、模板渲染测试
每次请求xsl文件，都通过django，并进行模板渲染
2、不使用模板渲染
每次请求xsl文件，都通过django，但不进行渲染，渲染结果直接从缓存获得
注：以上两个测试都是跑动态请求，不是静态页面请求。
经过测试后，发现性能的差别远远大于我的预计，渲染的性能，在同等条件下，每秒为110TPS（对于TPS的解释，请看我的另一篇文章《性能测试中带宽的影响》），而通过缓存获取xsl的性能则是190TPS左右，性能的差距非常大，相差了差不多一倍，如此巨大的差距倒是出乎我意料之外，不过本次测试只是针对于django自带的模板引擎进行的测试，并不代表其他模板引擎的性能也是如此，等有时间的时候，我再对其他的模板引擎进行相同的测试，相信应该不会差别如此大，毕竟django模板性能差是众所周知的。
可惜的是，本次测试只是对django的模板渲染进行了测试，并没有对xslt渲染进行测试，时间关系，再加上自己比较懒，还是等下次再对xslt渲染进行一次测试，不过有一点是可以肯定，客户端渲染xslt绝对会降低服务端的压力，毋庸置疑，有兴趣的朋友可以自己测试一下，再把结果告诉我，这样我也不用自己去测试了，呵呵。
作者：jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
地址：https://jackxiang.com/post/3967/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明！
最后编辑： jackxiang 编辑于2011-1-18 23:45
通过C语言连接mysql的源码，书（买了）上抄并测试通过，不要转载
crontab详解,At命令在指定的时间运行作业评论列表
