前言
使用Django开发WEB2.0的同学注意了，Django很可能存在性能问题，而且是灾难性的。（和算命先生一样，先吓唬吓唬人，危言耸听）
问题
WEB2.0提倡的是用户交互，因此WEB2.0站点不可能和传统站点一样，将大部分的页面都静态化。在频繁的交互中，数据库的访问必不可少。但Django的O/R
Map实在让人没底。
Django的O/R Map使用方便，但基本是个黑盒，难以进行优化。也许有人说优化是以后的事。但很多时候在最开始没有留下优化的余地，到真正需要优化的时候将苦不堪言。
对数据库的优化主要有减少数据库的访问和sql优化。将少数据库的访问可以通过cache等方式实现，这部分应当都一样，没有太多可以讨论的。对于SQL的优化，Django的O/R
Map实在封得太多，似乎也不存在太多优化余地，只能将O/R Map换成SQL。
但O/R Map在一定程度上是一种设计思想，将一个已经上线的O/R Map换成SQL并不会是一件很轻松的事。
分表也是常用的数据库优化方式，像Hibernate还可以使用Native Sql实现对分表的支持，但Django就不行。这时候有得换成Sql。
等改完后，原先优美的代码都已经变得惨不忍睹了。
相关数据
Django的应用中一直没有出现过什么大流量的网站。Django的普及程度可以说明一定问题，但或许Django本身就不适合做这个。
由于我并没有什么大流量的django站点，因此我的数据只能从网上找了。PS：我的小站，使用的是Bluehost主机中最便宜的一款，虽然没什么流量，但我进管理平台的时候几乎100%的500错误。
网站名称 使用技术 Alexa排名/收录量/PageView 服务器
Delphi盒子 ASP/SQLServer 21.05w /3.57w/3w 1G RAM
好看簿 Django 16.9w /7.05w/NA 3服务器
JavaEye ROR 2w /24.6w/15w 4G RAM
豆瓣（2006数据Quixote NA /NA /30w NA
备注：
好看簿
虽然具体流量不清楚，但参考Alexa的排名，流量应当在10w以下。
这个最早是有木头那听来的，知道是Django做的。今天在网上看到好看簿的介绍，说换了3台服务器。
对于创业期的网站来说，如果不是处于性能原有，应当不会如此奢侈。
因此猜测在单服务器时候，负载已经不太低了。
Delphi盒子
这个不属于WEB2.0页面交互比较少，因此数据库访问应当不会太过频繁。
仅仅做参考。
JavaEye
这个大家应当都比较熟悉。关于JavaEye的流量站长大人自己说得最清楚了。
HP DL145 G1，两路AMD Operton 2GHz CPU， 4G DDR RAM， 73G SCSI 15k Disk
Linux Kernel-2.6.7，lighttpd-1.4.13，MySQL-5.0，ruby-1.8.4(GC patch)
由于网站的访问量大部分集中在早上9.00到晚上9.00这12个小时的范围内。因此可以大致粗略的认为12小时处理12万动态请求，平均每小时处理1万动态请求，也就是说平均每秒处理3个动态请求。
服务器的平均CPU使用率在繁忙的时候，大概15%左右，MySQL数据库繁忙的时候平均每秒发送超过100条SQL语句，24小时平均每秒发送45条SQL语句。硬盘IO非常少
豆瓣
WEB2.0的代表，通是使用python开发。阿北在豆瓣的早期有谈论过豆瓣的性能问题。
现在cpu使用15%左右。每天30万页访问（白天每秒10次的样子)，100%是动态页面。服务器的访问响应时间平均仍在0.05秒以下。
加上所有的封面照片，是有几十个G。不过这些不在数据库里。数据库现在有5G, 最多的是书的信息(40多万条)和用户收藏和评价(50多万条)。这个不包括冗余。
mysql用了innodb和myiam. 读/写频繁的用innodb, 读多写少、写多读少(比如log)或者需要full text
index的用myiam. replication/cluster还没有，不过很快会有。现在每晚用mysqldump做backup.
后记
主要是这两天看了些Scaling（可伸缩？）方面的东西。感觉Django的O/R Map的功能难以支撑Scaling。当然，对于我来说这些东西应当都不是问题，至少暂时不会是问题，还没机会遇到这些问题。
在很多时候性能问题很可能是给伪命题。对于大多数网站来说很可能根本没机会遇到性能问题。类似Django/ROR等快速开发框架的好处是可以让你快速实现你的想法，给你一个演进的机会。如果真有机会遇到性能问题，那也是一个挺不错的事情（网站发展到一定规模）。