作者归档:vicalloy

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

越来越受不了JAVA的官僚主义了

前言:
    发发牢骚而已。在JAVA的世界里,毕竟还是官僚主义占上风。如果在别的地方发牢骚,肯定要被人批死。在自己的blog。我的地盘我做主。

——start——

    不知道是否是玩python的后遗症,还是一直以来就没有真正的喜欢过JAVA,反正最近是越来越受不了JAVA的官僚主义了。
    开口一定要设计模式,不然现得你浅薄。程序中一定要用很多的框架,不然显得你很没品。千万别题JDBC,别人会当你和很无知,现在都Hibernate3.xx/EJB3了。程序中一定要有很多的接口,不然就是你的设计能力太差,连接口都不用。配置文件也是越多越好,而且都是XML的。即标准又方便,要改的时候改配置文件就可以了。
    设计重要,但重要的是好的设计,不是过度设计。过度的设计同样将带来复杂度的提升。好的设计可以便于日后的扩展,但关键是很多东西是不可以预知的。一个设计不可能在最开始就做得尽善尽美。好的设计应当是一个可重构的设计。
    说到设计,JAVA中的接口是滥用得最厉害的东西。在很多JAVA程序中,有事没事加一堆的接口,还美其名曰解耦。有耦合才需要解,没耦合,你解个啥。就入Dao到service间的接口,好处是实现和调用没有关系,以后换数据库方便。但,有多少情况要换数据库?即使万一真的要换,到时候再重构一次,抽取出个接口能麻烦多少。而且在经过hibernate的封装后数据库间的差别已经消灭得差不多了。
    而且在大多情况下也不是加了接口就一定可以解耦的。接口只是解耦的一种途径,并不是万能药。
    框架也是。现在用JAVA做WEB开发,确实很难不用框架。但框架就和设计模式一样,是为了方便开发的,如果为了框架而框架那就是自讨苦吃。在提供方便性的同时,将一些实现细节进行了封装。如果对框架的理解不够透彻,很可能带来不少问题(最近有些问题比较头大,不知道是否和hibernate+OpenSessionInView有关)。在一个工程中开发框架尽可能统一,这里说的是尽可能,不说一定(绝对就官僚了)。一些简单的问题,为什么就不可以用简单的方法处理?难道写个1+1也要MVC一吧?
    配置文件也是个讨厌的东西。真不知道为什么JAVA要这么多的配置文件。哪有这么多的东西需要在发布后进行修改的。就入struts里的view,难道真的有人在项目发布后修改过?直接在代码中配置,IDE可以提供代码提示等,配置文件的书写比直接写XML流畅得多。

热键助手1.1.1 phoenix版发布

    在沉寂多日之后,热键助手终于又有了次新的更新。其实这对我自己来说都有些难以置信,这个小软件我居然维护了这么多年。不过不管怎么说,有新版本发布总归是好事。
    新版本的增加了一键搜索的功能。也就是你可以给搜索引擎设置一个快捷键,在按下快捷键的时候自动调用搜索引擎搜索当前选中的文字。目前该功能还只支持baidu,如果这个功能真有人用的话就将google也给加上(反正也就几行代码,我主要不想做那个向导窗口)。
    下载地址见我的googlepage

开源项目发布『老照片』

项目地址:http://code.google.com/p/oldphoto/
没有整理发布包,代码直接在SVN中取。
项目的演示地址见:http://www.lzpian.com/
许可协议使用的是MPL1.1。
由于fckeditor有点大,我在开源项目中将fckeditor给去掉了。
虽然网站还有些小bug,不过功能方面还是基本完善的。
希望对学习Django的人能有所帮助。

备注:
本来想将这个web站点作为对web2.0的一次尝试,但目前看来基本上是失败的。
关于这个网站的分析可以见下面的文章。
老照片分析:http://vicalloy.spaces.live.com/blog/cns!96F003C204150CFE!708.entry

“老照片”分析

    自认为对互联网多少还是有些了解的,因此一直都想将自己对互联网的看法实践下,只是因为懒,迟迟没有行动。在经过了无数次另人崩溃的延期和烂尾楼之后,我终于将我的第一个网站给部署好了。
    虽说网站并没有真正的发布,但近乎于0的访问量,也并不是我想看到的。
    人们在做事情的时候,都多少有些理想化。看见了黑暗中的灯光就以为拥有了一切。且不说路途上的暗礁,涡流。就单那个灯光,到底是登塔,还是专门诱惑旅人的鬼火都还不一定呢。
    对于一个新网站来说,流量的主要来源应当是自己的推广和seo。推广方面,我只在我那个没有光顾的BLOG和QQ空间上有介绍,没人来这也是理所当然的。不过因为网站还没有发布,这个问题不大。如果网站发布了要如何推广?去相关论坛发帖?或许,这个再看。
    SEO主要包括推广(到处挂URL)和网站结构的优化。因为域名还没下来,挂URL的暂不讨论。页面方面,作为图片站,文字本来就比较缺乏,这部分应当说是存在一定的劣势。页面方面我对SEO做了少量的优化,但其中存在一个很大的问题。通常的网站会写“XXX的老照片”,不过对于一个专门的老照片网站来说,再用“XXX的老照片”做标题似乎不妥。在这问题上,对于搜索引擎而言他不知道你的这张照片是“老照片”,在搜索的时候又出现了劣势。出于SEO的考虑,我给网站取了个很通俗易懂的名字“老照片”。但搜索引擎似乎对这个会有所忌讳。总之现在的结果是,不管在那个搜索引擎,以“老照片”的关键字,我的网站都排在了50开外。被搜索到的几率几乎为0。
    资源是另外一个问题。对于一个web2.0网站来说,用户是网站建设的一部分,网站的资源需要用户的贡献。但对于一个新站来说,你必须要先吸引到用户。如果你无法吸引用户还指望啥贡献。要吸引用户需要一些基础的资源,一些让用户感兴趣的资源。对于任何一个网站的建设初期,都存在一个资源搜集的过程。资源的搜集方式一般有两种,手动和自动。所谓手动就是自己整理资源,手动添加。所谓的自动,就是找个目标网站,然后放一堆的虫子,让虫子自己抓。出于资源质量的考虑,我现在采用的手动收集的方式,不过进度实在是慢:(。为了平衡质量和速度,以后的资源收集可能需要采用自动收集加手动整理的方式。
    还是资源问题。虽然互联网上有不少数据资源,但另一部分资源比数据资源更难搞到,这就是人。对于交互式的网站(老的如论坛,新就是现在所谓的web2.0),必须需要有一定量的核心成员。核心成员不但是主要的资源贡献者,还是网站风格的引导者。对于网站而言,网站的管理员必须担负起核心成员的角色。但目前网站真正的核心成员就我一个,而且还是一个缺乏资源的核心成员。按照我最初的设定,网站的主旨应当是老照片的交流。大家可以到网站上show一show自己的一些老照片(如自己小时候/父辈的照片),一些老物品(小时候的玩具/衣服/古董)等。但我实在是没啥东西可以show,而且我本人也不属于很喜欢show的类型。
    有一定量的核心成员才能吸引到人气,有了人气才可以吸引到更多的核心成员,从而形成良性循环。但现在是没有核心成员,就没有人气,没有人气就没有核心成员的恶性循环。
    吸引核心成员的方式一般有两种,人气、氛围。中国人就爱扎堆。就如土家烧饼这样的东西,拉两三个拖在哪里排队,都能吸引到一票的人来扎堆,搞得好像很怎么样(不过现在似乎已经那里来回哪里去了,毕竟这不是正道。PS:所谓的托是我YY的,是否真的有托,这个只有他们自己知道了)。所谓的氛围就是人不是很多,但都是志趣相投(或者说臭味相投:))。通常一个论坛发展到一定规模后,核心成员的地位就开始弱化。对于喜欢“氛围”的玩家来说,这已经不值得留恋了。于是,其中某一位兄弟,开始组建了一个新窝,然后又拉了一批“好兄弟”过去。这就是所谓的挖墙脚。有不少论坛就是这么发展起来的。
    今天去爬梧桐山,山下登山团队就不少,其中很多都是各个网站组织过来的(在山下还收到张VV网站的名片)。驴友也是个费米米的主,作为一个商业价值较高的群体,竞争激烈也是理所当然的。从一同登山的驴友那里了解到,除了“XX”,还有个“YY”的势力比较大。两个网站之间的关系也是剪不断理还乱(典型的墙角之争)。

老照片内测了

    其实也没有什么所谓的内测了。拖拖拉拉,7788,终于将网站的基本功能给做完了。在经过了多次的烂尾以及难产之后,终于有个工程基本做完了。先挂到朋友主机上玩玩。如果感兴趣就上去看看吧。等那天觉得准备得差不多了,就去申请个域名发布了。
    下面还是先给网站做个简单的介绍吧。
    照片是凝固的历史,分享老照片,触摸岁月的痕迹。
老照片是一个分享老照片的社区,在这里你可以分享任何有历史味道图片。包括老照片,老剧照,古董等。
    网站地址:http://www.lzpian.com/
    网站的注册很简单,只要填写用户名密码就可以了(其实是我偷懒,还没做邮件验证)。

    如果说个人网页,其实我也有过不少了,但这个应当是第一个真正意义上的网站。 以前的全是用frontpage做的HTML页面。本来机器上还保留了,些以前的页面做为纪念,可惜年代已久。在经过了数次“灾难”后,已经遗失了不少。
    在N年前,网络泡沫正旺的时候,满世界的免费主页空间,于是我也就整过一个。当时我将我所有能找到的东西都给堆了上去,然后自我感觉良好。现在再看,实在是惨不忍睹。
    后来玩过一段时间的flash,因为美工不咋的,于是就做了个flash首页。还好,经过了第一次的“灾难”过后开始有点觉悟。虽然不是怎么帅,但也还过得去。因为只是玩玩FLASH,而且当时已经处于互联网泡沫的后期,免费空间难找。这个网站就从来没有上过互联网。
    也曾玩过一段时间的fireworks,尝试用fireworks为网站做效果,然后进行切图。于是有整理了个所谓的班级主页(其实这个网站几乎就没人知道了:)),主页里放的都是我的一些PS作品。当时开到网易的免费主页又开通了,跑去申请了个放上去。哪知道几个月再去看,网易居然有给关了:(。当然,这本来就是一个没人理会的网站。
    自己做些小软件,需要一个网站发布。于是搜遍了互联网,找了个国外的免费空间做了个单页的网站。可惜免费的东西就是不怎么样,几个月后被关了。过些日子后换过了一个主页空间,再次关闭。接收了免费没好货物的事实,终于买了个最便宜的个人主页空间,100¥两年。这期间改版数次,当然,都是小改。
    毕业后,很长时间都没有动过这个空间。某日,忽然又想起了这个。对主页进行了一次比较大的改版,多加了几个页面。
    因为工作的原因,没有继续摆弄Delphi,改做JAVA。WEB是做不少,可是这些都已经是工作了。自己的个人主页在到期后就没有继续摆弄了。也想过做个自己的WEB,不过因为太懒一直没有动手。直到这次终于有个基本完成的东西了。不过有意思的是,我没有用java,用了python。或许是喜新厌旧吧。
    在出现blog前,我喜欢在自己的个人主页上写下自己的心情。可惜在丢过数次数据后,这些东西也都丢了。
    有时候在想,工作后实在是遗失了太多的东西。以前本来还喜欢摆弄摆弄PS什么的,现在连为数不多的一点艺术细胞都没有了。

备注:
    说到网页其实我还有两个了,一个是我的googlepage,另一个是我的开源项目于crystal cursor的项目首页。不过这个都属于零维护的单页展示页面,要说主页实在是有些勉强。

该死的DIV

    或许真是犯贱,放着简单实用的table不用,要用div。调了半天,终于调好了。放到IE下一看,居然面目全非(firefox的调试功能比较好用,所以一般用firefox)。
    看来得同时进行IE和firefox进行调试,不然等页面做好就郁闷了。

好的设计

    怎么样的设计猜是好的设计?功能完备的设计?也许。但复杂的设计将直接导致开发的困难,接连而至的是没完没了的bug和工程的延期。激情就在这么一而再,再而三的延期中慢慢的丧失。最后工程完成了,却依旧是bug多多,真正好用的功能没几个。时间优势没了,开发者的信心被打击了,最后的用户体验也没好到哪里去。
    一个好的设计首先应当是精简的,用20%的工作保证80%的需求。另外20%需求的引入很可能增加80%的工作量,而且在这20%的需求中还很可能有10%是凭空假想出来的。
    其次当然是可扩展的了。在我看来互联网的用户向来是最苛刻的。他们可以很容易的接受到很多新鲜事物。如果你不能满足用户的新鲜感,那将很难留住他们。为了实现这点,你必须对自己的产品进行持续的改进。网站容量的扩展问题也是值得思考的一个问题。总不能,用户一多网站就挂了吧。
    最少的代价获取最高的回报,并在和用户的交互过程中对产品的设计进行不断的修正,最终完成真正符合用户习惯的产品。
ps:
    在我看来最难的地方应当是精简。也许是我比较苛求,我很容易的就将设计做得很复杂。