« June 2007 | Main | August 2007 »

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倍这个目标。

July 7, 2007

银河系漫游指南,闪光的生命

从telipu同学家看到了这本70年代的科幻小说《银河系漫游指南》。这可能是最另类的科幻小说之一,你永远也想不到下面会发生什么荒唐事,稀奇古怪的。但是就是很好玩。科幻小说首先要是本小说,这样才有趣。

翻开扉页,赫然印有 姚海军 主编 几个中号的字。

猛然想起,和海军竟然已有10年未见了。上次见面还是在天津的某个旅馆里,那时是97年。海军以办地下科幻爱好者杂志《星云》而被大家认识,辗转曲折。这10年过去,我似乎已经放弃了对于科幻小说的梦想爱好。这老兄仍然不倦,神人也。因星云之名,老董创办天津星云(nt.cn),不过现在连这个也不作了。你看,这10年多少变化啊。

前天听说了柳文扬去世,不知道说点什么好。这也是我过去最喜欢的作者之一,似乎97年亦有一面之缘。很多事情,不知不觉就变得陌生了。想起来上次和星河吃饭也是4年前了。这老兄还高兴的调侃:“一转眼,当年的小读者都要吃我吃饭了,赶紧把我的新皮鞋找出来穿上...”

柳文扬的《闪光的生命》是最难忘的作品。100年的生命又如何,30分钟的生命又如何?去做你认为值得的事情吧。

文扬37岁走的。《银河系漫游指南》的作者道格拉斯.亚当斯49岁走的。或许,精彩的短的生命,比无聊的长得生命有意义得多?

about me:
me.jpg
CC License. Some rights reserved.
署名·非商业用途·保持一致
本站之所有未作特别说明的内容均使用 创作共用协议.
POWERED_BY_MT_3.2