我与django不得不说的故事(十六，完)--性能优化

唯有变化，才是永恒

    架构设计追求的是一种行云流水，水到渠成的感觉。没有一种架构适合于所有的场合，也没有一种应用会只用一种构架。在外部环境不断变化的过程中，我们的架构设计也会不断的进行变化。本章想讲讲django相关的性能和扩展的话题。

    先有一个感性的认识。我用ab在我的x200上进行测试django运行的普通动态页面，大约每秒可以运行200次请求左右，而如果用c++来开发的后台程序，差不多可以跑1500-2000次。但这并不是说django就很差，其它动态语言跑和c++也是有差距的。这个结果告诉我们，如果你的django程序的访问量在每秒200以下，那么你基本可以不作任何事。当你的django程序访问量在200-1000之间时，我们可以通过一些django的手段来进行优化，这个时候单机来跑依然是可行的。当访问量大于1000的时候，你又没有什么其它方面的改进，那么可能需要进行架构的改进以及进行多机部署。

    先来说说单机优化的事，说到优化，我们首先要知道我们的瓶颈在哪里。倒底是语言的瓶颈，是架构的瓶颈，还是算法瓶颈。一般来说，算法的改进可以让效率提升的最为明显，然后是架构的改进，最后才是语言的改进。

    算法的改进这里就不讲了，这个比较和业务相关。

    架构的改进，这个可以讲讲。一般认为，django系统的运行瓶颈在于模型和模板的低效率，当然可能也没那么低效。模型就是数据，也就是数据库。改进这个可能的方法就是利用django的cache系统来提供高速的数据访问，减少orm的使用。django内部提供一个cache机制，可以通过文件，数据库或者memcache用来缓存各种数据，通过中间件来接管后台的数据库管理。或者缓存某个页面，这个和php的动态页面静态化处理不知道是不是一个意思。同时models和templates也都有自己的模型类和模板的小缓存，用来自己数据的cache,这个好象是写死的。值得说一下的是，现在还有redis可以用了，django-redis-cache,木有用过呢。有了这个以后你的系统性能会有较大提高。
传说模板和模型都是可以被替换的，虽然笔者认为此法不妥，如果你把它们都替换了，那你用django来作什么，搞个web.py多爽啊。

    在架构上，当单机无法达到性能要求的时候，要作的依然是首先分析瓶颈在哪里，如果是数据库的问题，那就优化数据库，数据库分表，分区，作主从模式，这个django有一定程序的支持，可以去看官档。如果是memcache的问题，就增加memcache的机器。如果到了这一步，你将面临的就是痛苦但快乐着的系统重构，你可以放弃django选择性能更强的框架，但我不认为这样是最好的选择，因为我们可以挖的东西还有很多。

    如果你的网站一台机器已经无法满足需求了，那么恭喜你，你离成功又近了一步。

    最后的优化在于语言层面，比如怎么使用python更高效的语法描述，以及对关键点使用混合语言编程来提供效率等等，这里就不再细说了。

    此系列文章到这里就要结束了，我想，关于django的话题可以有很多，当然不限于只写一个blog。最后的最后想提一下：一切的一切都是为了产品服务，产品的一切都是为了用户的需求。而前面的一切都是为了---赚到钱。感谢稀的看的同学，也希望和你们交流。很长一段时间以来一直保持晚睡的习惯，有人如是说：熬夜，是没有勇气结束这一天；赖床，是没有勇气开始这一天。勇气这个东西在时间的面前，不知道还剩下了多少(声音越来越远，越来越小)。。。

转自：http://ddtcms.com/news/2011/12/25/wo-yu-django-bu-de-bu-shuo-de-gu-shi-shi-liu-wan--xing-neng-you-hua-jia-wai-yi-pian-hun-he-yu-yan-kai-fa/