Python论坛的帖子：

星期四十二月 6 19:08:49 HKT 2007

前言
使用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	内存/ CPU
Delphi盒子			ASP/SQLServer		21.05w   /3.57w /3w			1GRAM/NA
好看簿				Django				16.9w    /7.05w /NA			3服务器
JavaEye				ROR					2w       /24.6w/15w			4G
豆瓣（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.

-- 
Blog http://vicalloy.spaces.live.com/
My googlepage http://vicalloy.googlepages.com/
OldPhoto http://www.lzpian.com/

标题：[python-chinese] Django很可能存在性能问题