January 3, 2008

hi,2008

2007年最后一天早晨6点多,我趴在床上写这个blog,打算作为这纷乱一年的结尾。
其时叶总应该还在我家客厅的大沙发上睡着。叶总是来帮助我和tiny的新公司设定明年的方向,解决一些销售和管理问题的。北京城更远的一端,她应该也在梦中。

桌上放着xuyou从美国带来给我的lonely planet<CHINA>,和Tao of Jeet Kune Do,2本中国买不到的书。我盼了很久,这下终于遂了我的愿。

新年要来了,虽然有这么多那么多的糟糕事,想到还有那么多人关心我,惦记我,不由得觉得一阵温暖。谢谢你们!

随后,发现blog不能访问了。折腾了一番,发现我的主机商把我的站点转移到了一个被大陆gfw的服务器上。于是赶快mail联系。或许因为老外也在假期,一直没回应。直到昨天凌晨我发了第4封信表示了万分着急,今天终于收到回复,这台新服务器终于是可以访问的了。我回来了。这已经是2008.1.3了。


贴回来那天写的没发上来的部分。
------------------------
2007年最后一天,前几天花了不少时间打扫这个blog的垃圾评论。也该重新恢复这个长草的blog了。
最近几个月,因为私人事务,很少写blog。无数人催我,不过还是没写什么。现在总算恢复了点状态,可以多写一些了。

说起来,最近还是作了不少有意思的事的,包括一个很值得说的项目。随后慢慢写吧。

今天发现,导致我ibook变慢的主要原因是FIT输入法。放弃换回苹果默认的,虽然不好用,但至少快多了。反正FIT新版也不支持10.4Tiger了,换回来也好。

现在ibook硬盘再也不乱响了。这很好,似乎回到了旧日时光。

其实不止硬盘,太多的事情在剧烈的变动中复原。2007终于过去。2007我以一次旅游开始,现在终于一切完结。

该和新年问个好了。

写完发现,我的blog上不去了....

October 2, 2007

我讨厌腾讯,但是这次腾讯确实没做错

腾讯和珊瑚虫QQ一事,因为上升到了刑法,最近被炒的很热闹。很多人都有一个坏毛病--“同情弱者”,而完全不顾事实和法理。且不说合法合理,感情激动起来,甚至往往连合情都忘了。


一 珊瑚虫有没有插件

我的看法是有的。
在我曾经的使用QQ的一段时间,也曾经用过珊瑚虫。也曾经不幸因此中过流氓插件。当然现在我没证据了。幸好互联网保存了太多的历史。让这些过去的事情尚可追溯。

在追溯之前,我们来明确几个概念。

1 随光盘附带的,帮助用户安装的软件并非是流氓软件。
比如文档光盘里面附带了pdf阅读器,视频光盘附带的播放器,音乐光盘附带的mp3播放软件。这些是为了必要的用途,帮助用户安装的软件,而且有提示,用户也可以卸载。所以算不得流氓。拿着一张都是pdf的光盘,不装pdf阅读器,那就什么也看不到了。流氓软件则不提供这种必须的功能,可以算不请自到的垃圾。

2 诱导用户安装,且不能通过普通方式卸载的软件。
这种就是我们称之为流氓软件的东西。一个软件是否捆绑流氓软件,不能根据其安装时候提示:“本软件过程中将附带安装XXXX”来判断。而应该检查软件安装包本身是否包含了不能正常卸载且对用户没有必须功能的软件,并且可以通过软件安装程序进行安装。凡符合这个条件,都可算作捆绑流氓软件。

据老罗转来的消息,珊瑚虫工作室的人说绝对没有捆绑过流氓插件。那么我们来寻找证据吧。

首先是珊瑚虫捆绑了yok插件。
还有人发现了易趣插件
然后是珊瑚虫工具条

另外的证据是 海淀区人民法院 海民初字第25301号 中提到:除安装了珊瑚虫版**QQ外,用户电脑中同时还默认安装了360安全卫士、Zcom娱乐、珊瑚虫手机铃声下载、珊瑚虫在线查询IP数据等程序或者网页。

2006年,《电脑报》发起的流氓软件大调查中,捆绑软件危害榜排行第一的就是珊瑚虫QQ,捆绑的东西叫做KK图铃通。


综上所述,珊瑚虫不仅捆绑了流氓软件,在不同的历史时期中还捆绑了不止一种。如果珊瑚虫工作室认为绝对没捆绑过,我倒是想知道海淀法院的判决书怎么来得。何况,soff在那段视频里面自己也承认了捆绑插件。这事实够清楚了吧。

二 珊瑚虫违法,腾讯开发的IE外挂违法吗?


很多人都在作这个类比:既然珊瑚虫违法,腾讯开发的腾讯浏览器也是在IE基础上开发的,算不算违法?

事实上,腾讯浏览器不算违法。腾讯浏览器是在微软公布了IE内核调用接口的情况下,基于IE内核开发的产品。

微软甚至为IE开发者提供了一个文档中心,还有相关教程。可以说,微软是支持第三方开发者开发这种产品的。

而腾讯没有公布过任何接口文档。珊瑚虫无论是打包QQ还是外挂,都是通过反向工程完成的。

所谓计算机软件反向工程(Reverse engineering)也称为计算机软件还原工程,是指通过对他人软件的目标程序(可执行程序)进行“逆向分析、研究”工作,以推导出他人的软件产品所使用的思路、原理、结构、算法、处理过程、运行方法等设计要素 。

QQ安装时候的用户协议,3.4.2/3.4.3节约定了禁止进行反向工程,未经腾讯书面许可,不得借助QQ发展与之有关的衍生品,作品,服务。
qqinstall.jpg


综上所述,用珊瑚虫和腾讯浏览器类比是不对的。 珊瑚虫确实违法,腾讯浏览器没违法。

三 盈利问题

很多事情,没有盈利是不会出问题的,盈利就很危险。而且在目前的经济条件下,很容易成为所谓“数额巨大”。
我反对把珊瑚虫当作共享软件的看法,这是一个商业软件,确实获利了,在违法的产品上获利,即所谓不当得利。

四 腾讯做错了什么?


腾讯私下沟通过,北京海淀法院判过,但是珊瑚虫都没有重视。就算藐视腾讯,也应该遵守法院判决。面对判决书耍小聪明,这就是在玩火。出现这种情况并不奇怪。

腾讯作为一个民营企业,马化腾作为一个程序员创业成功者,都没有任何背景。腾讯不是中石油,不是中央电视台。一家民营企业家,这种做法算错吗?

从新闻中我们可以看到,此案是经侦支队在进行侦破。可见已经成为经济犯罪案件。这是有法可依的。请分清法院,派出所,刑侦支队,经侦支队的职责和权限。这样就更容易理解此案了。


最终结果,让我们等待吧。无论是什么样的结果,都是在推动行业进步。面对侵权,一直弱势的软件企业终于奋起反抗,对于在这行业中生存的我们,这一定是有积极作用的。

我不喜欢腾讯这家公司,我也很久很久不用QQ了,但是这次,我仍然要说,到目前为止,腾讯没做错任何事。


September 10, 2007

投降主义

比特世界的文化大革命。和现实中的文革一样,投降主义盛行。

我的做法:


1 越到这个时候,越用国外服务。
2 绝对不在国内注册域名,更不用cn域名。
3 绝对不用国内的虚拟主机。(我这个blog,2年前备案风兴起的时候搬到国外的,服务很好,价格便宜,每月才3$,在人民币升值的大环境下,用国外服务更合适。)

顺便跟某些管事的探讨探讨,不管他们看得到看不到。

1 过去所有媒体都国有的时候,你们有油水捞吗?
2 网监处在没有互联网的时候,一没实权二没钱三没政绩,现在呢?

想想是谁让你们地位上升的,管管事可以,但是别太白痴了。压力大到不能再大的时候,总会有很多新鲜的办法想出来,到时候可就不一定谁难办了。

September 5, 2007

也说怎么对付专有文档格式

此文甚好,基本道理都说清了。可惜是说清了也没用,因为通常没道理的事情未必行不通,有道理的事情也未必行的通。

所以偶尔也要用点坏招。

我的坏招是这样的:如果我要求你帮忙,我自然优先发送txt/html/pdf/odf格式文档。如果是合同,没话说,老老实实doc。反正能导出doc的工具很多了。

但是如果你找我帮忙,嘿嘿。

比如你给我份简历让我帮你找工作,doc免谈,我一定告诉你,重新贴到邮件里面给我发过来。比如你给我一份文档让我帮忙看看,我一定告诉你给我txt或是html,否则我看不了。

如果你找我要个文档,过去我通常发odf格式。现在因为OpenOffice在我的老ibook G4上慢如牛车,只好作罢,发pdf。

发rar的自然会被要求重发。如果我发出去的通常是tag.gz或是tar.bz2。

反正就是,尽量潜移默化的改变大家的习惯。虽然给别人添了点小麻烦,但总比指望某些机关或是组织觉悟更靠谱。

August 26, 2007

web2.0推动的互联网基础技术变革

胡狼发来 http://tech.51cto.com/art/200703/42476.htm 给我看。

这篇文章最有趣的地方是说到了web2.0公司更加善于不重复发明轮子。而在这个领域最成功的案例是amazon的S3和EC2服务。amazon和google是我们一直关注的两个公司,某种程度上他们代表了互联网的未来和方向性。这事情值得讨论一番。

行业的变化

其实整个行业的变化早就在不经意间发生,就算是看起来最稳定的领域。很多人认为unix世界是稳定的,windows世界是快速变化的,其实正好相反。unix世界每分钟都在变化。同样,在互联网最基础的层面,变化也在时刻发生。

互联网基础的基础,是带宽和服务器。95年的时候,建网站一般是自己拉一根专线到办公室,接在“服务器”上。其实直到现在,很多企业还在自建机房。比如我过去工作过的税务报社,比如过去我们的兄弟单位经济日报社,都是自己的机房。这些都是有钱,且更在乎信息安全的单位,算特例。

IDC的产生我认为是通过集中管理带宽来产生效益的方法。机器放在IDC托管,比自己建机房便宜,投入小,而IDC还能赚到钱。这是规模效应产生的利润。 IDC满足了99%的网站。除了刚才说的那种国企和机关。

更特殊的是google和amazon。他们对带宽的要求,对成本的控制,整体的规模要求,已经没有idc能够承担了。于是也只好自己建机房。不仅建造机房,为了支撑自己的服务,他们还要开发很强的软件用于管理。比如google的gfs和bigtable用于存储(在修改过得linux文件系统上面的一层),gws用于负载平衡和web 服务。按照机器数量和带宽数量来衡量的话,google是世界上最大的IDC了。

amazon做得更有趣一些。除了自己建立了大型的分布的机房,完成了各种软件应用,还把空闲的资源分割开出租。这就是AWS(aws.amazon.com)。AWS应用最成功的服务是存储服务S3(Simple Storage Service)和运算服务EC2(Amazon Elastic Compute Cloud)。这东西价格便宜到不可想象的地步,核算一下成本就会发现,任何规模小点的公司自己建立存储,都不如采用S3划算和安全,小公司的带宽投入价格甚至会超过购买同样带宽的S3。而且不需要投入开发人员,直接用就行了。

这仍然是“规模效应产生利润”。前面说了,IDC完成了“带宽”这个基础的规模效应。同样拥有大量带宽的amazon,同时又具有强大的软件系统,这种基础将可以进行规模效应的产品向上推了一层。不再是硬的带宽和服务器,而是软的存储技术。这就是我称之为互联网基础技术的东西。

amazon在规模效应上远高于IDC。首先,带宽采购量更大,价格更便宜。其次,服务器和存储设备统一采购,价格更便宜。然后,自己开发的软件进行统一管理,大大降低管理成本。后面两个层次是IDC所不具备的。这是软件的力量。

新一代网站与基础技术渴望

与其叫他们web 2.0,我更愿意叫他们新一代网站。他们有几个特点:

1 目标更收缩集中。相册能作成一个大网站(flickr.com),书签能作成一个大网站(delicio.us),甚至唧唧歪歪的留言也可以(twitter.com)......任何一个独立的领域都有可能成为一个单独的服务被拿出来。
2 公司规模更小。比起传统的互联网企业,新一代的网站工作人员数量变得很少。不再需要那么多编辑,不再需要那么多销售...
3 传统行业大量涌入。大量的传统行业者利用现有资源,突击互联网。他们的特点是行业资源强,盈利能力强,技术能力差。
4 网站的架构变得更加简单。因为目标收缩集中了,网站的架构也就简单了。
5 内容量快速增加。用户创造内容并非空话,新的网站中内容增加的速度远远高于过去。
6 网站之间因为api的缘故,互相连通更加容易。

目标更加集中,导致架构简单,而强大的互动特性导致了用户贡献内容,使得公司规模更小,更追求低成本。应用层技术要求下降,基础技术要求提高。比如:应用层就一个bbs,但是这个bbs有了5000万个帖子。这时候需要的是存储技术,而不是简单改改bbs程序就能解决的。过去复杂的网站架构已经变成了简单应用+高稳定+大负载+高容量的简单架构。架构简单了,但是难度反而提高了。作一套复杂的论坛程序还是简单的,但是做一个高稳定+大负载+高容量的存储服务,就很困难了。

我们急切的需要抹平这个技术鸿沟。现在做一个网站有很多可选组件了。比如,论坛有的是开源程序,图片可以通过flickr api放在flickr,需要地图可以用google map api 或是51ditu api,至于facebook api提供的功能就更多了。有了这些东西,做出一个想象中的应用就变得简单多了。而,在应用之下的技术基础服务,却仍然不够丰富。只有amazon算是前瞻的走出了一步。

我们做咨询的过程中,发现大量网站因为基础技术问题而导致不稳定。这问题在一年后会变的更为突出。这一年所累积的内容和数据会令很多网站不强大的技术基础彻底崩溃。

基础技术服务

以我看来,基础技术分为几类,存储算一方面,搜索算一方面,负载算一方面。tiny早有名言说:每一个网站都应该有反向代理缓存,每一个网站都应该有搜索技术。至于存储,不是每个网站都需要,至少也是大部分网站都需要。

所有公司都习惯租办公室而不是买楼,租比买好。按照新一代网站的实际情况和务实性,他们也应该更喜欢租用这些服务。amazon S3在美国的火爆充分证明了这一点。我们开始尝试的对外出租搜索技术的目前看来情况也不错。

而最好的服务模式,我觉得是以机房为单位,在一个机房内网范围内提供基础技术服务,这样速度有保障,且不产生外网流量,非常理想。一个网站可以用这些东西拼拼搭搭,完成自己的服务,把精力放在自己特定的业务和客户上,他们不可能因为技术垄断而产生竞争壁垒,也就没必要为了技术投入太多资源。

在还没有amazon的中国,这个服务恐怕需要几个角色合作完成了。

事实上,互联网的特征是,一个东西一旦普及到一定程度,就应该免费。然后通过在此之上的增值服务赚钱。这也是必然的趋势。

胡狼说了个很好的比喻:"带宽和合适的软件的结合,就好像intel+ms的联盟一样"。窃以为然。

August 1, 2007

pica,移动,IM,互联网融合

这几天突发事件比较多,没写blog。补记一下。
上周应sina科技凯锋之约,参加了pica产品沙龙。起初觉得诧异,找我这种除了打电话就不干别的的人,是不是找错目标了?手机对我的用途只有三个,打电话,闹钟,用屏幕亮度当手电筒。至于pica之类的玩意,想也没想过。不过他们据说就是想找非典型用户参加。于是欣然前往。

pica以被腾讯起诉而出名,现在已经成为了跨越pc/web/手机的im平台,同时还是个类似myspace的东西,用户可以在里面交友,发照片,发blog什么的。说实话我不太看好这些东西,或许是岁数太大了,或许是使用习惯,我觉得这些功能都距离我很远。
整个产品,唯一让我有兴趣的就是语音传送的功能。(好像叫“语信”或是什么来着?)。语音彩信很常见,但是能一次发一群人,而且使用方便的语音功能就很少见了。加上了这个功能,pica就变成了无线电台的模式。

虽然互联网远比无线电台来得方便,但是现在无线电仍然有大批爱好者。人们对于广播方式传送的信息始终还是热爱的。一个应用方便的群发装置确实能玩出很多有意思的花样来。

其实说回来,我觉得twitter的火爆,也是因为互联网没有好的及时广播装置。朝这个方向作点什么东西出来,应该还是很有趣的。

我不大看好pica的im功能,毕竟前有腾讯后有飞信,想突围很难。不过做好了移动,im和互联网的融合,应该还是很有前途的。目前这东西至少产品化程度不错,冲着这个语音功能,也是值的玩玩的。

July 23, 2007

余晟同学的blog

上篇blog:余晟与《精通正则表达式,忘了链接这哥们的blog。很多人来email来msngtalk还有留言询问。特此补上。

他的技术blog:
http://blog.donews.com/maverick
不过我觉得这个不技术的更有意思:http://www.luanxiang.org/blog/

July 17, 2007

余晟与《精通正则表达式》

博文的编辑晓菲告诉我,余晟翻译的《精通正则表达式》已经开始印刷,将在近期上市。我是这事情的推动者之一,自然有义务说说关于这本书和译者的故事。

06年末,晓菲在寻找 的译者。此书我看过电子书,甚好。可谓学习和使用正则表达式必备。我特别喜欢这书,如果被翻译坏了就太让人难过了。于是怀着私心,和晓菲推荐余晟,打算我们两个人一起翻译。

和其他候选者一样,我们试译了样张供博文审查。看到余晟的译文,我顿时自惭形愧,觉得比我的翻译细腻,精确了很多,实在是不忍把自己的拿出手了。如果我硬要参与,不是风格前后不统一,对比之下,毁了我一世好名声,就是让余晟多花气力替我统稿。于是打了退堂鼓,建议余晟自己翻译。

余晟就自己接了这档子事。随后的半年,这家伙过得极其痛苦,时常抱怨被我害惨了。那是自然,以他的完美主意倾向,做什么事情都能累的自己半死,但是对于读者这自然是莫大的好事。这半年里面,这件时常被他挂在嘴边的事,一定是他生命中一件大事。在他的blog上,我们可以看到如何字斟句酌,排列句子,推敲词句的。翻译的质量绝对配的上原著这本巨作了。

之所以介绍这个人,是因为,按照我的选书观,选出版社和责编可以保证原著质量,选译者可以保证翻译质量。博文出版了大量计算机经典著作,质量是无可挑剔的。那么好的译者就是最重要的事情。

推荐余晟是有原因的。首先他本人就精通正则表达式,对正则表达式的应用能力远超于我。这种极其专业的技术,不精通的人很难理解原文的精妙,也就当然翻译不好。其次他英语极好,不仅仅是听说能力好,而且书面能力好。用词造句都颇为考究。此人还在大学时期翻译了《权利与市场》一本,后因政局变化未能出版(好消息是,今年也要出版了)。对翻译不仅爱好,也确实尤其独到的地方。另外就是此人中文也棒,大学除了学了计算机,还选修了中文。翻译就是再创作,中文不好,就翻译不出好东西。有以上三个前提,我想这就是翻译这本书的最佳人选吧。

按照我的一贯理念,智力不是对事情的决定因素,认真才是。其实我们都可以做好任何事,无论你想写好程序,还是想考T考G考研。只要你真的拼命认真去做,结果往往令你满意。余晟智力当然也很高,但是认真态度却是最难得的。我和余晟作为同事一起工作的那段时间,他的认真态度非常令我赞叹。我交给他的事情,无论他懂或是不懂,几天之后拿出来的结果一定是令人十二万分满意的细致和完美。当然,达到这个水平的原因我也知道,那就是下班我时常要轰他回家休息,他却往往不肯,说不解决这个问题睡觉不踏实。或者是半夜时分打来电话跟我讨论问题,同样也是,不搞清楚睡觉不踏实。所有的漂亮成果都是背后努力的结果。对于这本书也一样,我目睹了他在翻译过程中的努力,辛苦,痛苦和快乐,这让我对最终的译文充满信心。

这家伙还是个非常准时,有规律的人。从不迟到,从不失约,答应的事情一定做到。但是这并没影响他的趣味。我们始终把“聪明,有趣,善良”作为对人生的最大目标和要求。当然,人非完人,太认真往往令周围的人不好接受,太技术化往往缺乏对社会的认识。好在这些与读者无关。所以大家尽可放心阅读。

有这样的译者,这本书想必会相当具有价值。如果你对正则表达式有兴趣,那我可以负责任的推荐你,这本书你应该读。

update:此书8月份上市,到时候应该各大书店和网络书店都能买到。

July 16, 2007

让你的网站快100倍! (2) web程序的流程和层次

我面试程序员的时候,最爱问的一个问题是:“请描述一下一个php(或.net/jsp...)页面被用户访问后,服务器都做了什么。”

这个问题看似简单,但是很多熟手都说不清。这也就说明了很多程序员并不真正理解web程序是如何工作的。不懂这个,就分不出层次,自然也就无从下手优化。这次我们先要把这个问题说明白了。

静态内容当然是这样。


有程序的就这样



有数据库的就这样



多个数据库作了复制或是集群或是负载均衡的就这样。



多个web服务器作了负载均衡就是这样


类似的东西还有很多。不过本质是一样的。都是用户请求到webserver,经过相应的处理模块(静态直接返回,cgi运行程序,动态脚本运行,虚拟机执行字节码生成html代码),将结果返回,这个过程中如果需要数据库,程序会连接数据库处理,取回结果。这个简单的过程就是web程序的本质。

无论多么复杂的结构,都是这些过程的组合。通常顺序也不会发生变化。知道了这个,我们回头看后面几个架构,就会发现他们做的事情都一样,就是把负载分开。当然这里分散负载的方式有很多,但原理无非就是2种,一种是分散开的各节点内容一样,所谓集群或是分布。这种做法好处是可以有通用产品。因为模式是统一的,就是复制出来多个一样的节点而已。另外一种是拆分服务,把不同的服务拆开到不同的机器上。这样做的好处是效率提升更大,每个部分都可以再进行单独优化,比如把负载最重的部分复制多个节点出来分散压力等等。后面我们讲到架构设计的时候再细致讨论这些问题。这里只做常识介绍。

负载问题的解决,常用的也是两种办法,一是开源,二是节流(其实所有问题解决都是这两种办法,企业管理也好,个人财务也好)。放到我们这个特定问题中,所谓开源,就是提高单个部分运行效率,让该部分能负担更多的工作。比如优化一下程序,优化一下数据库,都属于此类。所谓节流,则指降低对高资源消耗部分的使用次数。通常采用缓存的方式来处理。

我们沿着一个web程序的运行过程来看看具体的东西。这时候,我们先忘掉所有的负载平衡,集群之类的东西,集中精力来解决一个最简单的应用过程中的性能问题。

整个层次用图表示就是这样的:

蓝色是必备的层次,绿色是后期可加入的缓存,黄色是可以进行优化的部分,黄色的比例是一般情况下优化能带来的效果比例。看起来很简单?但实际做起来也没那么容易。

1 用户访问:我们当然可以通过降低用户重复请求同样的内容的方法来提高用户浏览速度和降低压力。
两种办法。一种是利用浏览器缓存,正确的设置http header中相关设置,让浏览器不重复请求没变化的内容。一般来说图片倒是可以这样做。页面也可以作一些,不过考虑到pv就是广告费的问题,还是让用户多多直接访问页面吧:D
另外一种办法是利用js,将部分数据存放在js脚本里面(js会被浏览器缓存),或是存放在cookie里面,用js取回。由此降低用户访问次数。

虽然有一些效果,但这些办法解决不了太实际的问题。所以不放在最优先考虑位置。

2 http server
用户的请求到达了web server,在这个层面,可以去硬盘读取静态文件返回给用户,也可能交给cgi程序继续处理。我们注意到,无论哪种处理方式,返回给用户的都是一个已经完成的html页面(或文件)。换句话说,就算是动态脚本,也是把处理结果生成html文件返回用户。如果我们能不重复这个生成的过程,那么对后端所有模块的压力都降低了。这个办法就是反向代理缓存。在http server之前使用。

3 cgi/vm
应用程序请求到达了cgi程序。那么最直接的考虑就是提高程序运行效率。不过,程序运行效率的提升多在几个毫秒的级别。除非程序非常糟糕,否则提升余地不大。而我们通常所感觉到的“程序响应慢”的原因,其实往往是在数据库上。

当然,这个层面会有一些特定的解决方案,比如zend对php的那些加速方案。(其本质仍然是不同层面的缓存)

4 database

终于到达了数据库这层。脚本和cgi程序访问数据库,获得数据才能生成html页面返回。这层的负担很重。

数据库优化是有效的。设计的好的数据库结构,搭配正确的sql语句,可以比最糟糕的设计提高数百甚至上千毫秒的时间。访问量大的时候,这个累计效应非常明显。

数据库设计往往决定了性能。鉴于目前关系型数据库的普及,很多程序员就把数据库当作了唯一的存储解决方案,任何东西都存放在数据库里。这当然是不对的,存储要结合应用特点,数据库不是万能的,很多操作在数据库中耗费资源巨大而性能非常低。例如全文like的搜索就非常消耗资源,远不如采用倒排索引的查询方式。

除此之外,数据库层面也可以进行缓存,例如memcached,或是在程序中缓存部分数据等。

5 高级优化

这些做起来就有些难度了。当所有性能都压榨完,我们只能回到web server和cgi程序本身。所以大型网站往往使用自己开发的web server(自行定制apache等),采用裁剪过的php库。

在我们还没有解决完其他部分之前,暂且不考虑这个。


顺着这个流程看,最有效,最值得做得事情显然是2和4,这些都是对系统架构改变不大,但是效果明显的方案。因此,下一章我们就从反向代理的应用说起。


ps: 另请转载此文的,请连图转走,或是留下本文链接。以免影响别人阅读。谢谢。我不在乎这点流量,所以转也就转了,但是不能因为少了图让别人看不懂。


tinyfool对此文亦有贡献

July 9, 2007

让你的网站快100倍! (1)

让网站快100倍,看这个题目,就知道我们在讲优化。没错,正是网站优化。

优化是银杏咨询的一块重要业务,也是我目前工作的重点之一。而优化这个东西是非常体现短板效应的,对知识的要求非常全面,而且要融会贯通,真正理解才能做得好。相关全面的资料很少,市面流传的东西谬误又颇多。所以我考虑把我这几年工作的经验,以及这半年来银杏咨询碰到的问题总结一下,写这个系列的文章,希望能对同行们有所帮助,抛砖引玉是最好不过的。

这系列文章里面,这第一章自然是说说大体的情况,说说常见的错误思想,统一了思想才好进行。
第二章我会讲解web应用程序的常见架构,然后分析哪里是薄弱环节,哪里有可能改进,哪里是关键点,形成一个总体认识。
第三章开始将一些实用技巧和工具,思想。
后面的还没想好写什么。且写且考虑吧。

这是第一部分,先统一思想。

1 这个时代,优化还有没有意义?

计算机芯片性能很低的时候,优化是万分重要的。性能就意味着产品质量。所以很多C程序员宁愿放弃程序的可读性,也要变态的追求性能。早期作游戏的家伙,甚至把乘法都写成加法,以期多获得几个指令周期的性能。

在这个计算能力无限廉价的时代,优化所代表的意义其实已经不同了。互联网服务是性能的压榨机。相对传统的企业应用,互联网服务的逻辑简单,结构扁平,而性能要求尤其突出。同样,这个时代多机集群,负载平衡,不再是奢侈的东西,已经变成了寻常物件了。常常听到的一个观点,就是性能糟糕不怕,与其浪费时间优化,不如去买更好的机器好了。反正硬件比程序员便宜的多。

这种极端的观点是害人的。在目前,硬件仍然是有极限的,硬件升级带来的性能提升最多只能达到几倍的程度。而集群技术,且不说对程序的要求更高,我们就说在可实现的情况下,如果我的应用比你的性能高100倍,就意味着我用1台服务器完成的工作,你需要用100台。硬件成本暂且不论,那么管理成本呢?用什么样的技术手段去管理100台服务器?用多少网管来管理100台服务器?所有规模快速上升的模式都会遇到这个问题,就是管理成本达到了极限。而任何东西一旦达到极限,就往往不能简单用钱解决了。

所以,为了避免达到极限,我们还是应该尽量去提高单机的负载能力。对于中小网站,这更是意义非常。或许长期可以用1,2台服务器解决问题,可能永远都不需要投入相对昂贵的集群技术。这对成本降低大大有利。


2 优化是相对长期工作

做优化过程中,我们最常见的就是“按下葫芦起了瓢”,解决了A点的性能问题,B点立刻成了主要矛盾。解决了B点,C点又来了。优化了很久,服务器的负载一点都没有降低。没错,因为产品特性,这种短板先漏水的现象非常常见。甚至可能做了一个月的优化工作,看起来完全没进展。比如,B点消耗系统50%的性能,但是因为消耗20%的A点造成的速度慢,用户从来不能打开B点所在的页面。这样解决掉A之后,反而暴露了B,性能反而还不如过去。

这种情况都可能碰上,所以要认定,优化是相对长期的工作,要花时间,认真细致的进行。

3 让数字说话

科学是不靠猜测的。所有工作开始和完成,都要用数字来衡量。数字最有说服力。眼睛和经验通常不可靠,甚至会让你做无用功。

4 优化是综合问题

优化不仅仅涉及到程序,数据库,还有系统架构,甚至产品设计。很多时候需要综合考虑,设计方案。这不是一个简单的问题,而是相互牵扯和影响的一系列问题。所以一定要细致的分析,不要想当然。设计方案要合理,力求用最简单的方式解决问题。

5 二八原则

二八原则同样适用于这里。80%的性能消耗是因为20%的问题引起。找到当前的主要矛盾是重要的。去研究代码,获取几毫秒的性能,不如去看看数据库,干掉一条执行超过1000毫秒的语句。

6 容忍缺陷,不要追求完美

比如,一个页面,实时计算需要耗费20%的性能,那么定时计算就明显节省了很多。当然效果上会有差异。这时候应该容忍缺陷。选择合理的折中方案。而技术人员也应该学会足够的沟通技能,让产品人员明白两者的差距。

而,通常一个看起来完美的架构,在实际应用中是不堪一击的。

7 记录是好习惯

无论是内部的文档系统,自己的blog,或是邮件列表,一定要记录下所做的改动。这样的资料对于以后的查错,升级,分享都很重要。

8 语言不是最重要的因素

总有人问,.net好还是java好,php快还是jsp快。在我们这个系列中,这不是重点问题。其实在真正的实践中,任何语言的差距都是相当有限的--只要你会用。优化本身是不在乎语言的。比语言造成的影响大得多的因素有的是。

当然,限于不同语言的特点,各有应用领域。而.net/java之类的语言确实在web开发上不如php那么舒服。不过这真的不是最需要解决的问题。


9 这系列文章会讲真正有用的东西吗?和银杏的业务是否冲突。

答案是,当然会讲真正有用的东西。虽然银杏咨询的业务也是这些,不过我们仍然愿意让大家多了解这些知识。理解了之后,你自然可以自己完成,但采用我们的咨询服务显然是更简单和稳妥的方案。所以这与我们的业务没有直接冲突,我将努力把我知道的东西写出来。如果有不完善和错误的地方,那一定是我水平有限,到时还请多指点。:D

原则目前就想到这些。我们会在以后的讲解过程中逐渐体会这些原则的意义。

最终,我们一定可以实现让网站快上100倍这个目标。