月度归档:2007年12月

最近为Delphi吐血超过一公升

虽然这是一些牢骚,不过和编程还是多少有些关系的,先放这里吧。

    虽不敢称对Delphi有多精通,但自信对Delphi的熟悉程度绝对超过绝大多少的Delphi的开发人员。不过最近实在是吐血,大口大口的吐,血如泉涌。粗略估计绝对吐血量绝对超过一公升。按我的说法,最近真是将数年来未遇的问题都全部给遇了个遍。这些问题搜遍地了互联网,能找到的除了问题还是问题。最的的感觉是,某些和系统结合紧密的东西还是用VC吧,毕竟都是老比家的。    
    那些小吐的就不说了,这里只列举些失血过度的。
    最先遇到的是类似WORD的多窗口程序问题(一个程序的各个窗体都在任务栏上显示一个按钮)。其实这个问题以前也遇到过,而且网上也有不少人遇到。但这问题一只就没有过一个好的解决方案。Delphi做多窗口程序最大的问题就是,不能使用模态窗口,模态窗口很容易跑到主窗口后面,这时候就是死都出不来了,这能动用任务管理器。由于这个问题涉及到Delphi的VCL体系因此很难解决。
    为了这个问题,有将互联网翻了个遍。网上应用的信息实在是太少了。我将能找到的一切方法都试了个遍,甚至连hack Delphi的方法都用过了,依旧是无疾而终。真是整到让人绝望。不过好在问题最终解决了,虽然解决方式不太优雅(应当说是,实在是太uglily了),但至少算是解决了。
    然后IE插件的右键菜单问题。由于Delphi的UI并不是线程安全的,导致IE插件的右键菜单只能在当前窗口弹出,通过URL打开的新IE窗口无法弹出右键菜单。这个还好点,在网上至少还恩能找到解决方案。网上说方案有两个一个是使用API,另外一个使用线程安全的第三方控件easymenu。由于不习惯使用API(而且还不知道用API是否会带来更多的其他问题),于是先找了easymenu测试了下。死得更惨,直接挂掉。API还好,可以正常工作,不过太过繁琐。于是尝试对Delphi的控件进行扩至,可是发现根本就无法实现要求。还好,这个问题最终也算是解决了,使用的方法依旧比较无耻。
    再下面的这个问题我就实在是无能为力了,血流不止。Delphi的IE插件弹出的窗口并没有使用XP的界面风格。如果是应用程序这倒好处理,放个控件就可以,但IE插件就是不行。又是放狗(google)又是划船(baidu)的,找到的都是一些鸡毛蒜皮的东西。还拉了个兄弟帮忙,结果一同被郁闷。真的让人怀疑这世界上是否真的存在这么一样东西。(后记:就在我要吐血身亡的前一秒,终于让我找到解决方案了。EmbeddedWB里面有一个XP风格支持的Demo)
    就这些东西还不算,公司东西出的问题也是让人血流不止。
    公司用Delphi给星空极速做了个插件,看上去好好的,也可以正常的加载。但只要程序的焦点落到这个插件里,等再移开的时候程序就挂死了。即使是最简单的ActiveForm上放一个Edit也挂。用VC写了个简单的测试程序,问题依旧。用spy++,发现按在TabControl出现消息的死循环。去掉TabControl再尝试,发现OK了。本以为将TabControl全部换成TPanel就万事大吉了。那知道测试程序好了,星空急速里还是老样子。这下更惨,以前出现消息循环的地方是在插件里,这下在星空急速里就出现消息循环了,消息根本就没有传递到插件里。死得不明不白的。再次绝望。
    如果你想尝试吐血的滋味,使用Delphi写个Activex的插件吧。保证你爽到极点。

后记:
    星空极速的问题终于也被我给搞定了。给我的感觉是似乎没有什么问题是解决不了的,不过吐血已经吐得够多的了,且如果有时间我似乎应当关注些其他东西了。

Django很可能存在性能问题

前言
使用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等快速开发框架的好处是可以让你快速实现你的想法,给你一个演进的机会。如果真有机会遇到性能问题,那也是一个挺不错的事情(网站发展到一定规模)。