2008年2月的归档

数据恢复中....

| | Comments(3) | TrackBacks(0)
  blog数据丢失快一个星期了,期间丢了不少重要的数据,还有几篇没有发表的翻译"High performance web sites"的章节也没由于没有备份而丢失。本计划这周能完成翻译到第五章节,但由于这突发事件而延后了。

  备份真的很重要,看有有必要单写一专题来讨论一下备份了。这年头,真的一切皆有可能。
  之前在 What is scalability ? 一文中,John对系统的扩展方式和度量做了一些讨论,但我们还是要知道:对于系统扩展,没有放之四海而皆准的方案,只有最适合自己实际情况的解决方法。在 的一篇有趣的文章:what's your scalability plan ? 中,Todd把一个网友发在留言板中的扩展方案又贴了出来,希望引出更多的草根方案,呵,看这网友贴的方案,就仿佛又看到了一群在创业中经历辛苦但享受梦想的人们。

  这位网友说他的网站是从零开始的,以下是他的扩展计划:

  第1阶段:
  单服务器一台,双路四核的2.66G CPU,8G的内存,10块500G的RAID硬盘。
  操作系统: Fedora 8 。
  代理缓存: Varnish (John:这位网友说 Varnish 比 squid要快,这是真的吗??)
  web服务器:lighttpd ,原因:比Apache2快,更重要的是配置简单。(John:这完全符合创业者的特点)
  对象缓存:  memchched
  编程语言:PHP 5,原因:简洁,没有臃肿的框架。(John:确实,php仍然是创业者的首选,不过现在rails也很值得推荐)
  PHP缓存: APC
  数据库: MySQL 5

  第2阶段:
  把内存升级到64G,缓存所有能缓存的东西。

  第3阶段:
  购买负载均衡设备,为前端增加2台服务器,配置与第1阶段类似:Varnish,memcached,lighttpd.
  原先的机器做为独立成MySQL数据库服务器使用。

      第4阶段:
      看负荷和规模的增长情况了,可考虑水平扩展增加一台数据库服务器或是文件服务器,主要是解决数据的访问瓶颈;若有必要,也可以考虑把Varnish ,Memcached,Lighttpd 分离到独立的服务器中。对于静态的文件,也可以考虑CDN了。

  第5阶段:
  把所有的服务器都升级到64G的内存,我们的口号是:缓存,缓存,缓存。

  第6阶段:
  如果这个网站能走到这一阶段,那现在应该不是缺钱了(风投或是盈收),毕竟没有多少网站能走到这一步。那么就把所有机器都换成是最高配置的。更重要的是,要保证web应用中每一层都能扩展,并且是能横向的通过增加机器来水平扩展。

  哈,这还真是个比较simple的草根扩展方案,但real world往往是复杂和万变的

《High Performance Web Sites》 :Chapter 1

法则 1: 尽可能减少HTTP请求数 Make Fewer HTTP Requests

      在Chapter A中介绍的性能黄金法则,揭示了一个现象:只有10~20%的用户响应时间是花在请求html源文件上,剩下的80~90%的时间则是在请求页面中的各个组件(图片,script,样式表,flash等)。因此,我们的第一个提速的方法就是尽可能的减少这些组件的数量,我们的目的就是要减少HTTP请求的数量。

  减少页面组件的建议,通常会让人在性能和产品设计上产生冲突。毕竟我们的页面现在所蕴含的元素越来越多,更多的小图片,不同的样式表,script等,这一章节,我会介绍一些技术方法来帮助我们平衡性能与产品设计上的冲突。这些将要出场的技术包括:image maps, CSS sprites,inline images以及尽量使用独立的js和样式表文件。使用这些技术方法在我们的案例中能减少50%的响应时间。


Image Maps
  将一个页面中所要引用的图片整合成一个单一的图片文件,按顺序排好,再分切出里面的链接区域。这样对整个图片群的需求样式没有变,但减少了对图片的http请求数。
      图1-1显示的是一个有五个图片组成的导航栏,每个图片对应一个独立的超链接。我们常规的做法,当然就是做五个图片,然后为每个图片做一个链接;但为了更高效,我们把五张独立的图片做成一张image map,这样从五个HTTP请求,就变成了一个HTTP请求,相应的响应时间也就会变的更快了。

  您可以试一下下面的两个链接,自己体会一下Image maps所带来的速度上的不同。

No Image Map
http://stevesouders.com/hpws/imagemap-no.php
Image Map
http://stevesouders.com/hpws/imagemap.php

  如果使用IE6在DSL(~900Kbps)的网络环境下,用image map的方法组成的导航栏要比用单独图片文件的所组成的导航栏要快56%(354ms 比 799ms).这是因为image map会减少四个HTTP请求。

  Image Map最常用的实现方式是使用HTML的map标签,把大图片分成一个一个的小块,并设置其不同的链接。如下:
 
<img usemap="#map1" border=0 src="http://7career.org/images/imagemap.gif">
  <map name="map1">
    <area shape="rect" coords="0,0,31,31" href="http://7career.org/home.html" title="Home">
    <area shape="rect" coords="36,0,66,31" href="http://7career.org/gifts.html" title="Gifts">
    <area shape="rect" coords="71,0,101,31" href="http://7career.org/cart.html" title="Cart">
    <area shape="rect" coords="106,0,136,31" href="http://7career.org/settings.html" title="Settings">
    <area shape="rect" coords="141,0,171,31" href="http://7career.org/help.html" title="Help">
 </map>

  但是它所带来的缺点就是你得手动确定图片的坐标,这会比较乏味和容易出错,并且它只适合把图片都组合在一个长方形的区域里。

CSS Sprites (您可以参考YouTube和iGoogle的首页,它们就是采用的这种优化方式)
   与image maps类似,CSS Sprites也是把若干小图片合成一个大图片,但是CSS Sprites方式更灵活。为了实现CSS Sprites,是把各个小图片像组成一个棋盘一样地合成一个图片。如下图:   然后通过HTML中任何能支持背景图片的元素,如<span>或<div>,再通过CSS中的background-position属性来定位要显示的大图片中的某个小图片的位置。如下,就是要在上面给出的在图片中使用"My"这个图标来充当下面这个div的背景:
<div style="background-image: url('a_lot_of_sprites.gif');
       background-position: -260px -90px;
       width: 26px; height: 24px;">
</div>


  我把前面我介绍image map的例子转成CSS Sprites的形式:把导航栏的五个链接都放到一个名为navbar的DIV中。每个链接都有一个SPAN元素,在#navbar的样式中为SPAN元素定义了背景图片spritebg.gif,但每个SPAN都有一个不同的class以指明其具体显示的背景图片的偏移位置,正是利用了CSS中的background-position属性。

<style>
#navbar span {
   width:31px;
   height:31px;
   display:inline;
   float:left;
   background-image:url(/images/spritebg.gif);
 }
.home { background-position:0 0; margin-right:4px; margin-left: 4px;}
.gifts { background-position:-32px 0; margin-right:4px;}
.cart { background-position:-64px 0; margin-right:4px;}
.settings { background-position:-96px 0; margin-right:4px;}
.help { background-position:-128px 0; margin-right:0px;}
</style>

<div id="navbar" style="background-color: #F4F5EB; border: 2px ridge #333;
                                  width:180px; height: 32px; padding: 4px 0 4px 0;">
  <a href="javascript:alert('Home')"><span class="home"></span></a>
  <a href="javascript:alert('Gifts')"><span class="gifts"></span></a>
  <a href="javascript:alert('Cart')"><span class="cart"></span></a>
  <a href="javascript:alert('Settings')"><span class="settings"></span></a>
  <a href="javascript:alert('Help')"><span class="help"></span></a>
</div>

  这比image map的方式的例子要更快:342ms VS 354ms,但是他们之间的实现方式只有很小的不同。但重要的是,这可比用单独的五个图片的例子要快57%了。
CSS Sprites
   http://stevesouders.com/hpws/sprites.php


  我们看到,image map的方式要求所有的图片是连续的组合在一起的,而CSS Sprites没有这个限制。关于CSS Sprites的优缺点在Dave Shea的权威文章"CSS Sprites: Image Slicing's Kiss of Death"中已经有详细的介绍,但我已经从CSS Sprites中体会到它的优点:减少了HTTP请求,比image maps灵活。另一个让我没想到的优点是它减少了下载的数据量。大多数人可能会认为一个拼合成的大图片肯定要比这此小图片的总量要大,因为它会有一些小图片的间隔区域。实际上正相反,大图片减少了图片中的color tables和格式信息等,而使得大图片比一堆小图片实际size要小一些。

    如果你的网站中有很多背景图片,按钮图片,导航栏图片,那么你应该用CSS Sprites方式来优化你的页面了。(您可以参考YouTube和iGoogle的首页,它们就是采用的这种优化方式)


 Inline images(注:IE暂不支持,您可以跳过这一部分;但说不定什么时候IE就支持了)
  我们上面所做的都是为了减少HTTP请求,现在有一个更绝的方式,把所有的图片都以base64编码以源代码的形式写在HTML源码里:data:[<mediatype>][;base64],<data>   所有对图片的HTTP请求,都化在了对HTML源文件的第一次请求里。

      我们在HTML中肯定都用过ftp:,file:,mailto:这样的标签,实际上像这样的标签还有很多,只是我们平常不太使用,像:smtp:,pop:,dns:,whois:,finger:,daytime:,news:,urn:等等.

      data:URL标签是在1995年第一次提出,按RFC2397规范的描述:它是"allows inclusion of small data items as 'immediate' data.(允许在页面中包含一些小的即时数据)"。如一个内嵌的小红星的图片可以这样引用:(在firefox下可以出来)
   
  <IMG ALT="Red Star"
SRC="data:image/gif;base64,R0lGODlhDAAMALMLAPN8ffBiYvWW
lvrKy/FvcPewsO9VVfajo+w6O/zl5estLv/8/AAAAAAAAAAAAAAAACH5BAEA
AAsALAAAAAAMAAwAAAQzcElZyryTEHyTUgknHd9xGV+qKsYirKkwDYiKDBia
tt2H1KBLQRFIJAIKywRgmhwAIlEEADs=">

  这样是挺方便吧,但它的不足之处也很明显:目前IE不支持;再就是FireFox1.5所能处理的line image有大小限制,不能超过100K;base64的编码会增加HTML的容量,总体下载量会增多。
       Inline Images:http://stevesouders.com/hpws/inline-images.php

      data:URL是内嵌在页面中的,所以它不会在页面之间缓存。所以您别用这种方法存储您公司的logo,因为它会增加您每个页面的容量。要解决这个问题,您可以把inline image写在CSS中,尽管date:URL不会被缓存,但CSS是可以被缓存的,Inline CSS Images:http://stevesouders.com/hpws/inline-css-images.php

下面就是接上面的例子,为每个SPAN加上inline image:

.home { background-image: url(data:image/gif;base64,R0lGODlhHwAfAPcAAAAAAIxKA...);}
.gift { background-image: url(data:image/gif;base64,R0lGODlhHwAfAPcAAAAAAABCp...);}
.cart { background-image: url(data:image/gif;base64,R0lGODlhHwAfAPcAAAAAADlCr...);}
.settings { background-image: url(data:image/gif;base64,R0lGODlhHwAfAPcAAAAAA...);}
.help { background-image: url(data:image/gif;base64,R0lGODlhHwAfAPcAAAAAALW1t...);}

       PHP的file_get_content函数可以很轻松的实现inline image的那串base64的图片编码。我上面的例子就是用的这个函数:

.home { background-image: url(data:image/gif;base64,
<?php echo base64_encode(file_get_contents("../images/home.gif")) ?>);}
.gift { background-image: url(data:image/gif;base64,
<?php echo base64_encode(file_get_contents("../images/gift.gif")) ?>);}
Combined Scripts and Stylesheets | 15
.cart { background-image: url(data:image/gif;base64,
<?php echo base64_encode(file_get_contents("../images/cart.gif")) ?>);}
.settings { background-image: url(data:image/gif;base64,
<?php echo base64_encode(file_get_contents("../images/settings.gif")) ?>);}
.help { background-image: url(data:image/gif;base64,
<?php echo base64_encode(file_get_contents("../images/help.gif")) ?>);}

      我们比较一下上面的几个例子,image maps与CSS Sprites的响应时间基本上相同,但比使用各自独立图片的方式要快50%以上。用inline image与CSS组合的方式虽然增加一个HTTP请求,但是它可以以样式表的形式被缓存。

Combined Scripts and Stylesheets
尽量使用独立的js和样式表文件


  现在的前端开发少不了JavaScript和CSS,但我们还是建议:使用外部的js和css文件引用的方式,因为这要比直接写在页面中性能要更好一点(细节会在Chapter 8中讨论)。但是如果你滥用这条规则,把你的代码切割成了很多个小文件,那只会增加更多的HTTP请求而影响性能。
       表1-1是10大网站首页中js和样式表的数量表,它们的样式表都不多,但js显然还有优化的余地。
       下面的例子中,你会发现用独立的一个js比用多个js文件组成的页面载入要快38%.
Separate Scripts
    http://stevesouders.com/hpws/combo-none.php
Combined Scripts
    http://stevesouders.com/hpws/combo.php

       有的人可能会习惯于按功能或模块来把js分成各种不同的文件,但以我的经验,如果一个网站的页面引用大量的js文件,那应该要分析一下这些分类是否真的便于管理。


结论
      这一章节介绍了我们在Yahoo!用到的以减少HTTP请求数量的技术方法。也是对访问网站很重要的一条法则。它会提高用户第一次访问您网站时的体验速度。而更快的访问速度将会使用户更愿意常回头访问您杰作。

相关章节:
翻译:High Performance Web Sites(1)-Chapter A
翻译:High Performance Web Sites(2)-Chapter B

《High Performance Web Sites》 :Chapter B

HTTP Overview

      在开始介绍具体的优化法则之前,您务必要理解超文本传输协议:HyperText Transfer Protocol(HTTP)对性能的影响。HTTP是浏览器与服务器之间通过Internet通信的方式。HTTP的规范是由万维网联盟:W3C(World Wide Web Consortium)和互联网工程任务组:IETF(Internet Engineering Task Force)共同制定,而最终形成的RFC 2616规范。HTTP/1.1是目前流行通用的版本了,但还是有一些浏览器只支持HTTP/1.0。

  HTTP就是描述请求request和响应response的c/s模型协议。一个浏览器发送HTTP请求(request)到一个指定的URL,这个URL所指定的服务器接到请求后返回一个HTTP响应(response)给浏览器,就这么简单。与很多互联网服务一样,这个协议用的是简单的明文格式。请求的种类有:GET,POST,HEAD,PUT,DELETE,OPTIONS和TRACE。下面我只重点介绍GET请求,这一最常用的。

  一个GET请求把所请求的URL组装在头信息(headers)中,然后发送到这个指定的URL。服务器接收到请求后,经过响应处理,返回一个包含状态码,头信息(headers)和具体明文文本(一般是Html源码)所组装的数据包。如下图,就是请求yahoo_2.0.0-b2.js时的HTTP头信息(headers)的内容示例。

压缩
  如果浏览器和服务器都支持,可以通过压缩来减少响应返回时的数据量。浏览器通过头信息中的Accept-Encoding元素来告诉服务器是否可以接受压缩数据,以及何种压缩方式。而服务器则通过头信息中的Content-Encoding元素来告诉浏览器,我目前支持哪种压缩方式。如下图

  注意上图中返回的数据是已经被压缩的数据。Chapter 4会专门介绍HTTP压缩,以及在代理缓存下产生的一些问题,当然还会讨论一些其它的头信息(headers)。


有条件的GET请求  Conditional GET Request
  如果浏览器已经缓存了一个组件,但是浏览器该怎么知道这个组件是否还有效呢,于是就产生了有条件的GET请求。如果缓存里的组件是有效的,浏览器就继续使用这个组件来加载页面,以减少响应的数据量从而加速了用户体验。

  一般来说,判断缓存的组件是否有效是检查它的最后修时间。浏览器通过response响应数据中名为Last-Modified的头信息来获取这个时间值。再次有相同组件的GET请求时,浏览器会将名为If-Modified-Since头信息随GET请求一起发送到服务器,带着这一条件信息给远程的服务器,这就好像是浏览器对服务器呐喊:"我已经有一个版本的组件了,这里它的最后修改时间,这次我还可以继续使用它吗?"(只要网络不断,服务器总是会听见这呐喊声的)

  如果这个组件在这个Last-Modified描述的时间之后没有被修改过,服务器就不会返回这个组件的具体数据了,而返回一个"304 Not Modified"状态码,这样可不就提高了响应速度了。在HTTP/1.1里,名为ETag和If-None-Match的头信息也可以起到类似的作用,这两个都会在Chapter 13中有讨论。

过期 Expires

  有条件的GET请求和返回304状态码能让页面载入的更快,但它还是需要在客户端和服务器端进行一个往返的验证过程,HTTP请求仍然存在。而名为Expires的头信息会则会避免这种验证过程。

 一旦浏览器发现响应返回的头信息中有Expires属性,它就会把这个属性所描述的日期与组件保存到浏览器缓存中,只要再次访问这个组件时的日期没有超过Expires属性里描述的日期,就会一直被浏览器使用而不会再次发送HTTP请求。Chapter 3会有关于Expires和Cache-Control头信息的更多介绍。



Keep-Alive

  HTTP是建立在TCP协议的上层的实现,在早期的HTTP实现中,每个HTTP请求都会打开一个新的socket连接。实际上效率很低,因为大多数的HTTP请求都是针对同一个服务器发出的(想像一下我们浏览一个页面的情形,是不是该页面的组件大多数都是在这个页面所host的服务器上)。于是,长连接(persistent connections)的概念被引入了HTTP,以解决这种同一个服务器不停地打开关闭socket连接的情况。它能够让浏览器的多个请求只通过一个连接完成。浏览器和服务器就是通过相互传递Keep-Alive头信息来判断是否支持这一特性。

  浏览器或服务器可以通过发送一个close头信息来关闭连接。从规范来说,keep-alive并不包含在HTTP/1.1中,但是绝大多数浏览器和服务器还是支持这一特性的。

  Pipelining, 定义在HTTP/1.1中,它允许在一个socket连接中发送多个请求而不用等待响应返回。Pipelining比长连接(persistent connections)有着更好的性能。但是很不幸,IE不支持(IE7已经支持了),FireFox 2以后的版本虽然支持,但默认是关闭的。所以在Pipelining还没能普及以前,我们就还只能用Keep-Alive的方式来优化浏览器与服务器之间通过socket的通信。这个特性对于HTTPS很重要,因为HTTPS的连接都是长时间的连接.


更多

  这个章节只是大致的介绍了HTTP,并把重点放在介绍影响性能的方面。如果要了解更多,您可以参考HTTP规范(http://www.w3.org/Protocols/rfc2616/rfc2616.html)和由David Gourley 与 Brian Totty编写的《HTTP: The Definitive Guide》(O'Reilly; http://www.oreilly.com/catalog/httptdg)。上面所例举的资料将会您理解我们后台的章节有很大的帮助。

2007感动中国十大人物

| | Comments(0) | TrackBacks(0)
民族脊梁钱学森:
      

感动中国组委会授予钱学森的颁奖词:在他心里,国为重,家为轻,科学最重,名利最轻。5年归国路,10年两弹成。开创祖国航天,他是先行人,劈荆斩棘,把智慧锻造成阶梯,留给后来的攀登者。他是知识的宝藏,是科学的旗帜,是中华民族知识分子的典范。

     感动中国推选委员阎肃,对钱学森老人这样评价:大千宇宙 浩瀚长空,全纳入赤子心胸。惊世两弹 冲霄一星,尽凝铸中华豪情,霜鬓不坠青云志。寿至期颐 回首望去,只付默默一笑中。

     感动中国推选委员杜玉波,在推荐钱学森老人的时候这样写:辗转回国,钱学森展现了中国科学家的硬劲;力学、喷气推进、航天技术,钱学森展现了一位科学家在研究上的牛劲;东方红卫星、神舟飞船、嫦娥奔月,钱学森给中国航天事业打了足够的底劲;今天,这位中国航天之父所开拓的事业正阔步向前,冲劲十足!

     感动中国推选委员陈章良,在推荐钱学森老人的时候这样写:他不仅以自己严谨和勤奋的科学态度在航天领域为人类的进步做出卓越的贡献,更以淡泊名利和率真的人生态度诠释了一个科学家的人格本质。

    钱学森 中国航天事业奠基人

     浙江杭州人,1938年在美国获博士学位,1950年开始争取回归祖国,受到美国政府迫害,历经5年于1955年才回到祖国。1958年起,钱学森长期担任火箭导弹和航天器研制的技术领导职务,为中国火箭和导弹技术的发展提出了极为重要的实施方案。

     1965年,钱学森正式向国家提出报告和规划,建议把人造卫星的研究计划并列入国家任务。在实施人造卫星研制计划中钱学森在许多关键技术问题的解决上贡献了智慧。

     钱学森对科学技术的重大贡献是多方面的,他以总体、动力、制导、气动力、结构、计算机、质量控制等领域的丰富知识,为组织领导新中国火箭、导弹和航天器的研究发展工作发挥了巨大作用,对中国火箭导弹和航天事业的迅速发展做出了卓越贡献。


天地英雄 李剑英:

    感动中国组委会授予李剑英的颁奖词:

    烟笼大地,声震蓝天。星陨大地,魂归长天,他有22年飞行生涯,可命运只给他16秒!他是一名军人,自然把生命的天平向人民倾斜。飞机无法转弯,他只能让自己的生命改变航向。

    感动中国推选委员陈小川,在推荐李剑英的时候这样写到:李剑英说过这样的话:"老百姓对我们那么好,我们要常怀感恩之心。"正是军人的沛然正气与感恩之心,塑造了一位真正的英雄。      

    感动中国推选委员任卫新,对李剑英这样评价:生为国生,荣为国荣,碧空长剑,英雄不死。永恒的十六秒,他用军人的生命谱写了热爱人民炽烈的壮歌。

  李剑英 英雄试飞员

    李剑英,河南郑州人,空军上校军衔,历任飞行员、飞行中队长、领航主任等职。

      2006年11月14日,李剑英在完成训练任务驾机返航途中,遭遇鸽群撞击,发动机空中停车。此时,飞机高度194米,跳伞就能保住自己的生命。从鸽群撞击点到飞机坠毁点2300米跑道延长线的两侧680米范围内,分布7个自然村,居住着3500口人。当时飞机上还有800多公升航空油,120余发航空炮弹,1发火箭弹,还有易燃的氧气瓶等物品,如果跳伞后的飞机失去控制,坠入村庄,后果不堪设想。16秒的时间内,为了保护人民群众生命和国家财产,他先后三次放弃了跳伞逃生的机会,毫不犹豫地选择了迫降。迫降过程中,飞机受到高出地面水渠护坡阻挡,爆炸解体,李剑英同志壮烈牺牲。在16秒时间里,他用生命写出了人民军队爱人民的优美赞歌。

    李剑英曾荣立二等功1次,三等功2次。2006年12月6日,空军党委为他追记一等功,并追授"空军功勋飞行人员"金质荣誉奖章。


树仁立德钟期荣胡鸿烈
香港教育界的传奇夫妻:

    感动中国组委会授予钟期荣 胡鸿烈的颁奖词:

    狮子山下的愚公,香江边上的夫子。贤者伉俪,本可锦衣玉食,却偏偏散尽家产,一生奔波。为了学生,甘为骆驼。与人有益,牛马也做。我们相信教育能改变社会,而他们为教育做出楷模。

    感动中国推选委员陈淮,对钟期荣、胡鸿烈两位老人这样评价:作好事并不难,难的是一辈子作好事,始终不渝的作好事,把一件好事做到终生!

    感动中国推选委员王晓晖,在推荐两位老人的时候这样写:他们的信仰观照了许多社会无力的角落,当我们每个人都去弥补社会缺位的时候,其实也弥补了更多缺位的人心。他们为百年树人,更树仁义于百年。

    感动中国推选委员王振耀,在推荐两位老人的时候这样写:我想到了中国的武训。胡钟夫妇本为青年才俊,意气风发,但感于贫困学子,即抛家舍业,投身教育,一座树仁学院就是一座丰碑,永远感动中国。   

    钟期荣 胡鸿烈 香港教育界的传奇夫妻

    两位均已89岁高龄,香港树仁大学创办人。1987年胡鸿烈获委任为第六届的全国政协委员。1993年第八届开始,他连续两届获委任为全国政协常委。

    胡鸿烈及钟期荣夫妇青年时代已经是民国司法外交界的青年才俊, 1953年两人学成回香港后,一直是执业律师。因感于许多年轻人没钱上大学,1971年他们自资创办树仁学院,牺牲了自己的青春和健康,为香港社会培养数以万计的人才。

    35年来,胡氏夫妇为学校拼尽心力,生活非常节俭。胡鸿烈更不惜以迟暮之年,回律师楼工作,出入法庭打官司,为学校大楼挣工程费。据估算,两人创立树仁学院,奉上毕生积蓄估计至少4至5亿元。

    1979年,胡博士获邀回大陆,出席中国国庆三十周年纪念,获邓小平接见,成为第一位踏足内地的立法局议员,并在1987年获委任为第六届的全国政协委员。


义无反顾孟祥斌
为救落水者牺牲的年轻军人
:

    感动中国组委会授予孟祥斌的颁奖词:

    风萧萧,江水寒,壮士一去不复返。同样是生命,同样有亲人,他用一次辉煌的陨落,挽回另外一个生命。别去问值还是不值,生命的价值从来不是用交换体现。他在冰冷的河水中睡去,给我们一个温暖的启示。

    感动中国推选委员彭长城,对孟祥斌这样评价:我们常常无时无刻地追问自己人生的意义,也许意义不在于追问,而在于行动。而孟祥斌用纵身一跃放大了自己生命的价值。

    感动中国推选委员纪宝成,在推荐孟祥斌的时候这样写到:真的仁者视他人的生命如自己的生命,真的勇者愿为他人的生命付出自己的生命。(纪宝成)

    孟祥斌 为救落水者牺牲的年轻军人

    男,28岁。第二炮兵某旅机要参谋。

    2007年11月30日上午,孟祥斌带着妻子叶庆华和女儿到市区购物。11时20分左右,在经过通济桥时,一名轻生女青年从10余米高的桥上跳下,孟祥斌一边冲向桥边,一边脱掉身上的衣服,不顾江水寒冷,跳水救人。

    10分钟后,前来救援的摩托艇渐渐靠近了他们,孟祥斌用尽最后一丝力气将女青年托出水面,交到救援人员的手中,自己却再次沉入水中。13时40分,被打捞起来的孟祥斌被送往医院急救,但是却没能挽留住他年轻的生命。

    12月4日,在孟祥斌的葬礼上,浙江金华市近3万名群众自发从四面八方赶到金华市殡仪馆,为舍己救人的英雄孟祥斌送行。

    孟祥斌1997年12月入伍,山东齐河人,爱学习、肯钻研,曾当选第二炮兵工程学院第七次党代会代表。


实践信仰方永刚
把忠诚献给最壮丽的事业
:

    感动中国组委会授予方永刚的颁奖词:

    一个真正的战士,在和平年代也能找到自己的方向, 一个忠诚的战士,在垂危的时候,不会忘记自己的使命,他是一位满怀激情的理论家 ,更是敢于奉献生命的实践者。在信仰的战场上,他把生命保持在冲锋的姿态。

    感动中国推选委员陆小华,对方永刚这样评价:有人说,理论是灰色的。他作为一个理论工作者,以他的实践和人生告诉人们,理论是彩色的,生命之树常青。

    感动中国推选委员陈小川,在推荐方永刚是这样写到:他从古今中外的历史中,思考中国的今天和未来,他是伟大理论的真诚播火者,他所传播的理论和他的道德人品一起,赢得了青年一代。

    方永刚 把忠诚献给最壮丽的事业

    男,44岁,中共党员,海军大连舰艇学院政治系中国特色社会主义理论教研室教授。方永刚入伍20多年来,以对马克思主义的坚定信仰,立足本职岗位,深入学习、积极传播、模范践行党的创新理论,在党的理论武装工作中做出了突出贡献。

    方永刚热爱本职,兢兢业业,在军校教员岗位上忠实地履行着自己的职责。他把业余时间全部用在了刻苦学习和研究党的创新理论上,正是凭着这种水滴石穿的精神,从邓小平理论、"三个代表"重要思想到科学发展观,党的创新理论每前进一步,他的学习研究就会跟进一步、深入一层,不断推出研究成果。他先后出版16部政治理论专著,完成10项国家和军队重点科研项目,发表100多篇学术论文,荣获全军院校育才银奖、全军政治理论研究优秀成果一等奖。

    方永刚作为辽宁省国防教育讲师团成员、大连市委讲师团成员、沈阳军区联勤部客座教授,先后为部队和地方党政机关、社区、企事业、干休所、学校等单位作辅导报告1000多场,从军队到地方、从城市到乡村、从北国的漠河边防到南疆的海防哨卡,都留下他传播创新理论的足迹,被官兵群众誉为"平民教授"、"大众学者"和"科普专家"。

    2006年11月,被确诊为晚期结肠癌的方永刚,仍然以顽强的毅力与病魔抗争。他坚持从医院回到学院,为学生上完最后两节课,还躺在病床上完成了对3名研究生的学期教学和毕业论文写作辅导任务。

    方永刚真学、真信、真情宣传、真诚实践党的创新理论,用生命的激情诠释了一名军校教员的敬业奉献精神和高尚师德师风。


心灵强者李丽
身残志坚的湖南张海迪:

  感动中国组委会授予李丽的颁奖词:

    残疾打不垮、贫困磨不坏、灾难撞不倒,坚强和她的生命一起成长。身体被命运抛弃,心灵却唱出强者的歌。五年时间,温暖八万个冰冷的心灵,接受、回报、延伸,她用轮椅为爱心画出最美的轨迹。

    感动中国推选委员王振耀,对李丽这样评价:我们从李丽的事迹中感到了爱的力量。李丽也证明这样一点,一个人无论多么平凡,无论多么孱弱,只要孜孜不倦,奉献爱心,就一定能够促成社会的良好道德风尚的广大。

    感动中国推选委员于丹,在推荐李丽的时候这样写:孱弱的身体,强大的心灵,这个座标对太多健康的躯体是一个提示,让我们更多自省,看到真诚与善良的心灵力量是无边的。

    李丽 湖南张海迪

    女,45岁,衡阳人,1岁患小儿麻痹症,童年从未站起来过;40岁时再遭厄运,车祸让她下半身完全瘫痪,从此与轮椅为伴。

    在多舛的命运里,她不仅没有怨天尤人,还选择了一条向社会传播爱心之路。

    她创办了"李丽家庭教育工作室"和公益网站"丽爱天空",长期从事公益事业和青少年心理教育工作,先后义务深入省内外100多个学校、企业、社区、监狱开办家庭教育和心理健康教育系列讲座,听众达10万余人次;帮助近百名厌学孩子重返校园、数十名中学生戒除网瘾,为近万名学生树立自信。4年多时间里,她的善行使得20多万人获得心灵的洗礼。她还成了很多服刑人员的"偶像",被人们誉为"感恩天使"、"湖南的张海迪"、"中国的海伦•凯勒"。



人生如炬闵恩泽
国家科学技术大奖获得者
:

    感动中国组委会授予闵恩泽的颁奖词:

    在国家需要的时候,他站出来!燃烧自己,照亮能源产业。把创新当成快乐,让混沌变得清澈,他为中国制造了催化剂。点石成金,引领变化,永不失活,他就是中国科学的催化剂!

    感动中国推选委员陆小华,对闵恩泽这样评价:归国五十多年,奠基中国炼油催化应用科学,以知识报效国家,一生成果难数,开发生物柴油推动绿色化工,凭贡献乐享人生。

    感动中国推选委员任卫新,在推荐闵恩泽的时候这样写:青春投学,爱国有志;耄耋赤子,报国有恒。成就卓著,贡献卓绝,桃李不言,下自成蹊。

    闵恩泽 2007年国家科学技术大奖获得者

    男,84岁。石油化工催化剂专家,1994年当选中国工程院院士,我国炼油催化应用科学奠基人。2008年1月,经国务院批准,他成为2007年度国家最高科学技术奖两位获奖人之一。

    闵恩泽1955年在美国学成后冲破重重阻碍回国。60年代在极端艰苦的条件下,为中国自主开发了微球硅铝裂化催化剂,打破了国外技术封锁,满足了国家的急需,为我国炼油催化剂制造技术奠定了基础。70年代,在特殊的政治条件下,他没有忘记科研工作,领导了多种催化剂等的研制和开发,也均投入生产和应用,使我国炼油催化剂迎头赶上世界先进水平,实现了我国炼油催化剂跨越式发展。

    1980年以后,他指导开展己内酰胺磁稳定床加氢研究,使我国裂化催化剂生产达到世界先进水平,满足了我国炼油工业的发展和油品升级换代的需要。

    闵恩泽院士是德高望重的著名专家,为我国石油化工工业培养了大批科技人才,凝聚了产学研相结合的科技创新团队,近年来,他进入绿色化学的研究领域,把催化剂科学技术扩展到了应用于生物质资源的加工利用。2001年起,他指导的生物柴油生产和应用的研究已经取得长足进展。

    从60年代,闵恩泽已经多种疾病缠身,并被发现有肺癌,切除两片肺叶和一根肋骨。但是他没有放弃中国的石油催化事业,一直坚持工作并不断取得突破进展,至今仍工作在科研第一线。


大医医心陈晓兰
坚守医德无私无畏医生

    感动中国组委会授予陈晓兰的颁奖词:

    虽千万人,吾往矣!曾经艰难险阻,她十年不辍,既然身穿白衣,就要对生命负责,在这个神圣的岗位上,良心远比技巧重要的多。她是一位医生,治疗疾病,也让这个行业更纯洁。

    感动中国推选委员彭长城,对陈晓兰这样评价:她只是一个弱女子,却挑起了维护医疗环境纯洁的大任,屡遭报复,陷入困窘,依然坚持,无怨无悔,最终推动主管部门出台多个法规性文件。她所作的对得起作为一位医生的良知。

    感动中国推选委员于丹,在推荐陈晓兰的时候这样写到:一个弱妇女子冒着生命危险揭露行业潜规则,她代表了这个社会核心价值的方向。

    陈晓兰 坚守医德无私无畏医生

    陈晓兰,女,55岁,原上海一家地段医院的理疗科医生。近年来,陈晓兰一直从事医疗器械行业打假,被她揭露的各种医疗器械达20多种,其中8种假劣医疗器械被查处,因此被央视评为2006年度"3•15质量先锋" 。

    在她与假劣医疗器械10年的斗争中,为了取得一手证据,她曾假扮病人,冒着危险 "以身试针"。在她的推动下,国家专门多次下发文件,取缔和查处了七种一度使用很广的伪劣医疗器械和治疗方法,曾受到国家食品药品监管局的肯定和奖励。

    目前,上海市食品药品监管局已经正式聘请她为"食品药品安全社会监督员"。


var para_count=1

有信延信谢延信
细心侍奉亡妻家人33年
:

    感动中国组委会授予谢延信的颁奖词:

    当命运的暴风雨袭来时,他横竖不说一句话,生活的重担压在肩膀上,他的头却从没有低下!用33年辛劳,延展爱心,信守承诺。他就像是一匹老马,没有驰骋千里,却一步一步地到达了善良的峰顶。

    感动中国推选委员杜玉波,对谢延信这样评价:这个人对爱情忠贞,对老人孝顺。谢延信,人如其名,信守一生。

    感动中国推选委员陈淮,在推荐谢延信的时候这样写到:家庭是什么,是人世间最可信赖的社会细胞。谢延信作到的不仅仅是孝,这是对家庭亲人的忠诚,我们这个社会需要的就是这种忠诚。

    谢延信 细心侍奉亡妻家人33年

    男,55岁,河南焦作煤业(集团)鑫珠春工业有限责任公司机电科工人。

    1973年,刘延信与同村姑娘谢兰娥喜结良缘,第二年7月,谢兰娥去世前,嘱咐丈夫要好好照顾自己的爹妈和智障兄弟。此后,刘延信付出了33年的忠贞与孝心,成就了一个大孝至爱、感天动地的谢延信(刘延信后改姓为谢)。

    1979年岳父患重度脑中风,再也没有站起来。一老,一瘫,一傻,一幼,家庭的重担全部压在了谢延信的肩上。

    谢延信老了,病倒了,但他的意志没有垮、孝心没有变、责任没有失、良心没有丢。他隐藏起最沉重的哀愁,担负起让希望生生不息的重任。


真爱无疆罗映珍
700个日夜唤醒沉睡爱人
:

    感动中国组委会授予罗映珍的颁奖词:

    把爱人从沉睡中唤醒,是生命的奇迹,还是心灵的力量?她用一个传统中国女人最朴素的方法诠释了对爱人不离不弃的忠贞。甜蜜不是爱情的标尺,艰难才能映照爱情的珍贵。

    感动中国推选委员刘姝威,对罗映珍这样评价:谁说久病床前无贤妻?罗映珍用行动告诉我们:爱是这个世界上最伟大的力量。

    感动中国推选委员王晓晖,在推荐罗映珍的时候这样写:苦难磨励爱情的坚强,爱情总因苦难而显光芒。她不仅唤醒了丈夫,也唤醒了许多人在这纷杂时代中对内心情感最深处的拷问。   

    罗映珍 700个日夜唤醒沉睡爱人

    女,27岁,中共党员,从1998年9月起在云南省临沧市永德县小勐统镇计生服务所工作。

    罗映珍的丈夫罗金勇是云南省永德县公安局民警。作为一名警察的妻子,罗映珍模范遵守社会公德,积极弘扬家庭美德,不但热心本职工作,而且热爱公安事业、关心支持缉毒工作。多年来,她以实际行动谱写了一曲当代女性的奉献之歌、正气之歌、爱心之歌。

    2005年10月1日,罗金勇与妻子罗映珍回家探望父母,途中罗金勇临危不惧与3名毒贩进行了殊死搏斗,因寡不敌众身受重伤,成了"植物人"。从那以后,罗映珍肩负起了照顾丈夫的责任,不离不弃,精心呵护,无怨无悔。罗金勇在医院接受治疗期间,罗映珍在医院附近租了一套房子,省吃俭用,每天全身心地守候在丈夫身旁,和丈夫说话,并含泪写下了600多篇爱的日记,用日记呼唤着丈夫意识深处的觉醒。

    现在,罗金勇已从深度昏迷的植物人状态中苏醒过来,能眨眼,能开口讲"你好"、"是"、"累了"等几个简单的字,并在特殊的体位下能喝水。见证了这个奇迹的人们都说,是罗映珍的坚持和爱,唤醒了沉睡的丈夫。

    2006年,她被评选为感动云南十大人物。2007年,全国妇联、云南省妇联分别授予罗映珍三八红旗手荣誉称号,临沧市公安局还授予罗映珍二级警司警衔。罗金勇及其妻子罗映珍的先进事迹经全国各大新闻媒体宣传报道后,引起了强烈的社会反响,社会各界纷纷伸出关爱和援助之手,积极支持好警嫂罗映珍。

今天是情人节,首选就从New Yorker的2000年情人节刊开始欣赏吧:

2000年情人节
没想到里面还有动物的亲吻,美国人很有幽默感

 

"Stairway to the Stars," Philippe Petit-Roulet, October 1, 2007.
(
多读点书吧,书能让你走的更高)


"Autumn Tales," Benoî;t van Innis, November 19, 2007.
(
秋天的传说,很有诗意,收获的季节)

 

(不见驴,只见一只被束缚的狂野大象-共和党,国会楼前草坪上的是什么人?看不太清....)

 

(纪念萨翁)

 

"Fill 'Er Up"BY ANITA KUNZ / May 22, 2006

 

"Losing Face"BY FRANCOISE MOULY / May 29, 2006
丢脸了吧不知美国人的词汇里有没有丢脸这一说?)

 

"Back to Cool"BY BOB STAAKE / September 4, 2006
(
这孩子脑子里youtube,ipod,ps3,Aim,myspace.....)

前端性能的重要性The Importance of Frontend Performance


    
我的大部分web生涯都是在扮演后台开发工程师的角色。所以,我很自然的把每个性能作业都作为是一个后台的优化练习罢了,像什么编译器参数,数据库索引,内存管理什么的。而且也有很多关于后台性能优化的书籍和资料让大家从中找到想要的东西。但实际上,对于绝大多数的web页面,只有不到10-20%的最终用户响应时间是花在了从服务器下载HTML源文件到用户浏览器上。如果你想达到不可思议般的用户快速浏览体验,那当然就应该去关注一下那其它的80-90%的用户体验时间花在哪儿呢?又该怎么去减少这个时间呢?后面的章节就会向您讲解与目前web优化所相关的一些基础知识,并提供14条优化性能的法则。

 

来关注一下web页面的性能

为了知道怎么去提高性能,我们应该先了解最终用户们都把等待的时间花在哪儿了?图A-1是在IE上访问Yahoo!的首页(http://www.yahoo.com)HTTP响应时间图(John注:我们可以用HttpWatch(IE)Firebug(ff)工具来生成类似的图)。每一个横条都是一个HTTP请求。第一个横条,标识为html的那个,是HTML文档的初始请求(指请求HTML源文件)。然后浏览器解析这个HTML文档,并且开始下载这个页面的所有组件(John注:这里的组件是指页面所引用的图片,flash等非html文档的东西)。在我们的测试环境下,浏览器的缓存是空的,所以所有的组件都会被下载。在图上,我们可以看到,HTML源文件的下载只占整个响应时间的5%,最终用户花了近95%的时间用在等待下载组件上.还有一小部分是花在HTML,script和样式表(stylesheets)的解析上,在图中我们用每个下载时间条间的空白间隔来表示这些解析时间.

A-2显示的是我们第二次用IE浏览这个网页时的情况.HTML文档的下载占到了整个响应时间的12%.大部分的组件都不用再下载了,因为它们已经被浏览器缓存了。

A-1.gif

A-1 Internet Explorer上访问http://www.yahoo.com,空缓存

 

A-2.gif

 

A-2Internet Explorer上访问http://www.yahoo.com,预先已有缓存

 

Ok,我们来看一下,有五个组件在第二次浏览页面时仍被下载了:


一个重定向(redirect)

     这里的重定向虽然已在第一次访问被处理过了,但是浏览器还是再次请求了一次。因为它的HTTP响应状态码是302(表示"Found" "move temporarily"),在响应header中没有缓存信息,所以浏览器不会去缓存它。关于这方面我们会在Chapter B中讨论HTTP时提到。

三个没有缓存的图片
  接着的三个request请求是在上一次浏览时没有下载的三个图片。这些是经常变动的新闻图片和广告图片.

一个被缓存的图片
  最后一个HTTP request请求是一个有条件的GET请求.这个图片是上次被缓存的,但是因为HTTP的响应头(response headers)的设置,浏览器要确认一下这个图片是不是最新的.有条件的GET请求我们也会在Chaptet B中讨论它.

 

时间都去哪儿了?

再回过来看看HTTP时间响应图,我们看到至少80%的最终用户响应时间是花在了下载页面里的组件上,如果我们来仔细分析一下这个图表的内容,我们会发现浏览器与HTTP之间的交互开始有点变的复杂了。除了上面我提到了HTTP的状态码和header会响应浏览器的缓存,另外,我们还能得到下面一些观察结果:

l          凡是被缓存的组件(图A-2)大多都不会有下载动作。相反,你看到的是紧跟在Html请求后的一个没有下载的空白时间间隔,这表示这段时间是在解析HTMLJavaScriptCSS,以及从缓存中获取相关的组件。

l          在同一时间里的HTTP请求数变化了。图A-2在同一个时间切面上最多只有三个HTTP请求,而图A-1却同时有多达六到七个HTTP请求。这是因为使用了多个不同的主机名(hostname),而无论它们是使用HTTP/1.0还是HTTP/1.1Chapter 6将会解释这种多个同时下载的"平行下载(Parallel Downloads)"。(John注:是指同时下载)

l         这种平行下载不会发生在下载script上,因为在大多数情况下,浏览器会阻止其它下载scriptHTTP请求。Chapter 6会解释为什么会这样,同时也会教你如何应用这个知识去优化你的页面载入时间。

要完完整整地指出时间都去哪儿了真是一个挑战。但至少还是很容易地能看到哪儿没花时间?它没有全花在下载HTML文档上,也没全花在后台的处理上。(几乎都花在了前端下载组件上)这就是为什么前端性能如此重要了。



性能黄金法则

 

        Yahoo!主页这样只有10%-20%的响应时间花在下载HTML源文件的现象并不是一个特例。据我分析,几乎所有与Yahoo!类似的网站都是这样(这可不包括YahooSearch,因为它的页面上组件的数量实在是太少了)。甚至可以进一步说,绝大多数的网站都是这样的情况。表A-1展示了由http://www.alexa.com所统计出的当今美国前10大网站。说明一下,下面提到的网站只有AOL不在前10,因为Craigslist.org本是排在前10,但是它的页面风格没有什么图片,script和样式表,不适合这里做为研究例子,所以我挑选了AOL

A-1  访问10大网站时的下载HTML源文件所占的时间比

T-A-1.gif


        所有的网站都只花了不到20%的总响应时间在获取HTML源文件上(John注:这一部分时间更多地取决于各网站的后端性能)。但只有Google在已有缓存的情况下是个例外。因为http://www.google.com只有6个组件,其中有5个被配置成被浏览器缓存。再次访问时,所有的组件被缓存,只有一个请求HTML源文件的HTTP请求和一个图片请求。

       在做完所有的后台优化努力的情况下,你已经很难再有大的突破了。很显然,是时候关注前端的性能了。

  首先,关注前端性能所能带来的整个性能提升到底有多少。如果我们能把后台的响应时间再优化,再砍掉一半响应时间,最终用户的响应时间也只是相应减少5% ~10%John注:因为后台的性能只能是减少那个20%的响应HTML源文件请求)。相反的,如果我们把前端的性能提高一倍,我们可以把整个响应时间减少40~45%

  再说了,前端的改进一般不需要太多的时间和资源。而优化后台的性能时间基本上都得深入应用的构架和代码,找出优化的关健代码路径,增加或者改进硬件,分布化数据库等等,这些工作动辄就要以周和月为时间单位。在接下来的章节中介绍的前端性能优化法则都来自于最佳实践,比如修改web服务器的配置文件(Chapters34);将script和样式表放置到页面中相应的地方(Chapters 5 6);将图片,script,样式表组合到一起(Chapters 1)。这些实践只需要以小时和天为工作单位--远比提高后台性能需要的时间成本要低。

  第三点,前端性能的这些实践都是经过实际考验的。在Yahoo!中有超过50个小组用这些实践减少了25%甚至更多的最终用户响应时间。在一些案例中,我们分析了运用这些要点的网站,一般都能达到25%或更多的性能提升。

  在开始每个新的性能提升项目时,我都会画一张类似图A-1的图表来阐释一下性能的黄金法则:

  只有10-20%的最终用户响应时间是花在了下载HTML源文件上。其它的80-90%是花在了下载页面中的所有组件上

  俺把这句浓缩一下,就是:80-90%的用户等待时间是来自于前端的页面加载

  这本书后面的部分将会提供详细的指导法则去减少这80-90%的最终用户响应时间。为了说明这些法则,我会陆续提到很多相关的技术:HTTP headersJavaScriptCSSApache等等。

  因为一些HTTP的基本概念对理解这本书非常有必要,所以我会在Chapter B中重点简介。

  在这之后就是分章节的14条优化法则。我把这些法则按优先级列出。每条法则都有自己的适应范围。举个例子,法则2更适合商业网站而不适合个人站点。如果您应用所有适合您网站的的优化法则,您可以将页面速度提升25-50%从而增强用户体验。这本书的最后章节会告诉您如何以性能的眼光去分析美国的10大网站。

recover myself

| | Comments(0) | TrackBacks(0)

    一年又一年。
      又是同学聚会的时候了,小柯说我的口音已经有了京味,剑同学带着老婆来了,朱同学还没怎么变,还和高中时的记忆里的一样,洪那家伙还是满口喷粪... ....

      时间过的不知不觉,但有时又有知有觉。回忆总是一件好东西,我以前总认为只有人老了,才会不停的回忆,现在看来,我要更正一下了,回忆,是找回自己的方式,它只与生活的阅历有关,与年龄无关。

      这几天在家,抽空把以前收藏的CD,全转成了MP3。听着这些歌曲,我就会想起我在大学时代听这些歌时的心情,场景或是人。学生时代,是人一生中最美好的时代,不用忧国忧民,在校园这个小社会里,除了身上没钱,一切都是那么潇洒和自由,当然了,临近毕业前,为自己的前途到是彷徨了好一阵。

      十年前的我们,肯定想像不到十年后的情形,但至少我们还能回忆起十年前的样子,那时看过什么电影,听过什么歌,看过什么书,和某人约过会,逛过哪条待,暗恋过某人,或是被某人暗恋过,有太多太多的回忆,都足以让我们微笑着去回味。

      春节回到家,也要给自己来个年终总结,去年去了哪几个城市,看了什么电影,读了什么书,办了什么事,好好细想一翻。08年,到是已经列下了书单的阅读计划;电影方面当然是期待赤壁和功夫之王了;继续努力工作,积累很重要;要抽时间多运动,奥运年嘛;然后还有..... .....(以下省略汉字数千。)

      多和朋友聊聊天,那是一扇扇的窗户,窗户多了,进来的阳光也就多了。

      recover myself,recover youself.

Home,now

| | Comments(0) | TrackBacks(0)

   终于到家啦!
    祝大家新春愉快,合家团圆。

    一起迎接2008金鼠奥运年 : )

What is scalability ?

| | Comments(0) | TrackBacks(0)

     什么是scalablity? scalablity译成中文是:可扩展性,伸缩性。

      很多人都在谈论系统性能,系统可用性,但我觉得scalablity(可扩展性)并不是这些,虽然我们仍然需要关注速度,性能,高可用性,程序平台,网络等等,但这些并不是scalablity的全部。
     scalablity,简单的说,就是关于您如何把事情做的更大。扩展(scaling)一个web应用就是指怎么做才能使您的系统允许更多的人去访问或使用您的应用。
  在目前的业内实践中,有两种扩展WEB应用的方法:

  • "垂直扩展--Vertical Scalability" - 通过增加资源来增强系统的处理能力。如:给现有的系统升级CPU,或是为RAID/SAN扩充更多的硬盘。
  • "横向扩展--Horizontal Scalability" - 增加多个应用处理单元的机器。一般是集群,分布式文件系统,负载均衡的形式来横向扩展系统。

       每一个组件,无论是CPU,服务器,存储系统或是负载均衡,都还是会有一些运营上的开销。当您尝试扩展您的系统时,您一定要清楚到底哪些升级或扩展是对您系统影响比例最大的,这要经过一些测量。我们把比这些测量的结果叫做"可扩展性因子"。比如:您每为系统增加一个CPU,但因为一些开销要耗掉这个CPU 5%的性能,实际上您的可扩展性因子是0.95,也就意味着您只能使用到这个CPU 95%的资源。

  • 如果可扩展性因子是一个常量(=1),我们就称之为 "线性扩展linear scalability".
  • 但实际上有很多组件的扩展性并不太好,如上面介绍的增加CPU时的有非功能性开销的例子. 如果扩展性因子小于 1.0,我们就称之为 "子线性扩展性-sub-linear scalability".
  • 有一种情况比较少见,就是通过增加组件而获得性能(扩展性因子>1)的大幅度提升(如把在多个磁盘上的I/O操作移到一个RAID上),这种情况我们称之为 "超线性扩展supra-linear scalability".
  • 还有一些设计的不好的应用,根本不适合扩展,扩展的努力只会让系统更糟 ,我们就称之为"负可扩展性negative scalability".

      如果您需要扩展系统,垂直扩展是最简单的方式(只要您银行存款足够,这事就成了)。一般在不做代码优化的情况下,您可以把您的系统程序迁移到一个超级的,也更贵的64位CPU的服务器上;也可以把存储系统换成EMC,日立或Netapp的产品。但是垂直扩展只会让您的花费越来越大。

  横向扩展,则不一定要相当数量的昂贵服务器。因为它可以通过普通的机器和存储硬件以达到规模效应来解决问题,像早期的Yahoo!,Google都是这样。横向扩展不仅仅是便宜,它是把应用程序构建在多个服务器组成的一个大server的基础上,这样就会随之有两个常见的问题: "Split brain"(功能,数据分割) 和 "hardware failure"(硬件故障,毕竟机器太多了)。

  无限的线性横向扩展是很难实现的,无限的垂直扩展则更不可能了(硬件的性能都有极限)。如果您正在建设中的系统事先无法确定用户的数量,那么用垂直扩展比较明智。但如果您正在建立一个给百万网友使用的WEB应用,那垂直扩展是一个错误,它实在太昂贵了。

  可扩展性不仅仅是关于CPU(处理能力)的,一个成功的可扩展的WEB应用,它的所有层都应该能够方便的扩展,如:存储层(文件集群系统),数据层(数据分区,数据联合),应用层(memcached,scaleout,terracota,tomcat集群等),WEB层,负载均衡层,防火墙。举个例子,如果您对您未来的WEB应用网络负载没有考虑负载均衡,那么花再多的钱在WEB层的横向扩展上都是浪费,因为您的WEB访问的将会被瓶颈限制,而这时只有负载均衡能解决问题。

  选择一个正确的可扩展性方案取决于您的系统应用规模和您的银行帐户情况。如果有人说他有一个能解决所有问题的方案,那人肯定是个骗子或是外行。如果您再参加某人的"可扩展性"讨论,您一定要先问问他:What is scalability ?

More to say:

  • Always try to identify the worst case scenarios.

  • Always build for the worst case scenarios.

  • Always test the known worst case scenarios.

And , always have a back-up plan!


      更多资料:http://www.royans.net/arch/

如果一切是真的

| | Comments(0) | TrackBacks(0)
    微软提以446亿美元购雅虎
    这是真的吗?如果我是微软,我希望是真的。如果我是yahoo!,我会说,微软,一边玩去!
    微软能否在互联网中确立他在操作系统市场的地位?不会的,但收购一个有资历的互联网公司,是他唯一的机会,正巧他们看中yahoo!了。
"Bird's Eye View," Eric Drooker, January 15, 2007.



"While Rome Burns," Anita Kunz, January 22, 2007.



"Subway Connections," David Heatley, February 12, 2007.



"Say Cheese," Bruce McCall, March 5, 2007.



"Uphill Battle," Barry Blitt, March 26, 2007.



"Style Sheet," Ivan Brunetti, May 7, 2007.




"Big City Romance," Lou Romano, June 25, 2007.



 "Bright Idea," Bob Staake, July 2, 2007.



Slide Show



"Summer Reading," Jooste Swarte, August 20, 2007.


最近的留言

John发表于JAVA Puzzlers下载: Java Puzzl
justified发表于JAVA Puzzlers下载: 你能给我传一下电子版
John发表于Google公司十大彩色幽默(ZT): 呵,对,就是叫“幸福
燕子翔发表于Google公司十大彩色幽默(ZT): 那部电影的名字叫做《
John发表于读史记5:   讙兜推荐共工,尧
John发表于读史记4:   尧说:“哪一位能
John发表于读史记3:   帝喾娶陈锋氏的女
John发表于很美,很美,昨晚奥运开幕式带妆彩排的炫目烟火: 现场更美了
bannoorse发表于很美,很美,昨晚奥运开幕式带妆彩排的炫目烟火: 真是太美了!
bannoorse发表于很美,很美,昨晚奥运开幕式带妆彩排的炫目烟火: 真是太美,太壮观了!
John发表于读史记2:   黄帝共有二十五个
John发表于读史记1: 译:   黄帝是少典
John发表于谁的Bug ?: 嗯,对。一直觉得JA
huang发表于谁的Bug ?: Calendar中的
John发表于Kernel的编译过程(freebsd): 终于等到骆驼了,期待