iJohn.org

Optimizing MongoDB: Lessons Learned at Localytics

Sun JDK 1.6内存管理 -调优篇

Sun jdk 1.6内存管理 -使用篇

第五章我们将样式表放置于HTML的HEAD中以加快页面渲染。其实script也有类似的问题，但解决的方法正好相反:把script放到页面的下端，会利于页面的快速渲染。

为了更好的说明这第6条法则，我们先看一个反例吧。把script放在HTML页面的中间位置，看看这种方式页面的下载情况，如：http://stevesouders.com/hpws/js-middle.php

《High Performance Web Sites》 :Chapter 4

法则4:使用Gzip压缩组件　　Gzip Components

前端开发工程师能力的好坏直接关系着页面的访问快慢（John：要知道，用极其丑陋的table套table做出的页面比简洁的div与table做出的页面无论是从K字节上，还是载入速度上都是极大的消耗），但另一些如用户的带宽等我们无法控制的因素，也会影响到用户访问您web应用的速度。法则1和法则3介绍了如何通过减少不必要的HTTP请求来提升页面加载时间，法则2介绍了用CDN，可以让我们离用户更近，但我们总不能把所有的HTTP请求都优化掉吧。于是，我们这法则4应潮流而生。

法则4，是通过减少HTTP响应的数据量来加快响应速度。要知道如果一个HTTP的响应足够少，那传输的时间多快呀，因为从服务器端传送到浏览器端的数据包小了，也少了，岂有不快之理。这对像那些网络不太好的用户可是特有效。这一章节就会展示如何通过gzip去压缩HTTP响应，这是减少数据量最easy的方法，但有得到就会有付出，gzip也会有一些不好的影响，这个后面介绍。

压缩是如何工作的

很久以前我们就把文件压缩应用在电子邮件和FTP站点当中。直到HTTP/1.1的规范制定，web客户端才开始通过HTTP请求中的 Accept-Encoding 头信息来来表示其支持压缩。

如果web服务器在请求信息中看到这个头信息，它就可以通过响应的 Content-Encoding头信息来返回服务器可用的压缩方式。

gzip是目前最流行和高效的压缩方式。它是一个可以自由使用，不受专利权限制的压缩格式，是由GNU项目开发出来并定义在RFC1952规范中。另外还有一种压缩方式是deflate，但它不如Gzip那么常用和高效，其实上，我只发现一家网站在使用deflate：msn.com 。而支持deflate数据压缩的浏览器，也支持Gzip，所以Gzip是非常好的选择。
 

该压缩什么

服务器要压缩什么是取决于文件格式。很多网站只压缩HTML文件，其实script和样式表文件的也都值得压缩（事实上，任何文本型的数据都可以压缩，包括XML和JSON数据）。图片和PDF文件的则不必再用gzip压缩，因为它们本身就是压缩格式，再多余的压缩只会浪费CPU资源，也得不到多少的文件压缩量。

gzip压缩需要消耗服务器端的CPU，而客户端也需要执行解压gzip格式的数据。至于是否值得压缩的问题，我觉得任何超过1K或2K的文件都值得压缩。mod_gzip_minimum_file_size 参数就可以配置您想要压缩的文件的大小范围，它的默认值是500 bytes.

老套路，我又调查了美国10大网站使用gzip的情况如下图。有9家都用gzip压缩他们的HTML文件，7家还用gzip压缩了script和样式表文件，其中有5家是完全压缩了所有的script和样式表。一个网站如果压缩所有的HTML文件，样式表，script文件，甚至可以减少70%的数据量，这是我们下面的段落里会提到的。

节省The Savingsgzip压缩后，返回的数据量一般会减少70%，如下图所示，显示了scrtip，样式表文件在压缩前和压缩后的数据量的变化，同时也显示了如果用deflate方式来压缩的数据量对比。

很显然，从上图中就知道我们为什么要选择gzip了。gzip会减少约66%的数据量，而deflate只会减少约60%。

配置 Configuration

配置gzip的模块要取决于您Apache的版本：Apache 1.3使用的是mod_gzip，而 Apache 2.x 使用 的是mod_deflate。这一段落就会讲解如何配置每个模块。

Apache 1.3: mod_gzip

Apache1.3的gzip压缩功能是通过 mod_gzip 模块来现实的。mod_gzip 有很多的配置参数，这些在mod_gzip的站点上有说明，在这里我介绍一些最常用的参数。

mod_gzip_on
开启mod_gzip.
mod_gzip_item_include
mod_gzip_item_exclude
定义要被gzip压缩或不压缩的文件的类型，MIME类型, user agent, 等等。

大部分的web服务器都会打开mod_gzip，并把text/html设为默认文件类型。最重要的是您应该为script与样式表文件也打开gzip功能。您可以参考下面对Apache 1.3 的配置：

mod_gzip_item_include 　file 　　　\.js$
mod_gzip_item_include 　mime　 ^application/x-javascript$
mod_gzip_item_include 　file　　　 \.css$
mod_gzip_item_include 　mime 　^text/css$

gzip的命令行程序可以控制压缩的级别以及CPU的使用率，但在mod_gzip中却无法配置这些。有时对数据流的压缩会造成CPU的过分负荷，我们可以选择缓存压缩后的响应数据到磁盘或是内存中，如果要手动实现这一功能就太麻烦了，还好，我们可以通过mod_gzip来自动保存压缩后数据到磁盘上，还可以及时的响应更新。实现这一功能则要配置 mod_gzip_can_negotiate 和 mod_gzip_update_static 参数。

Apache 2.x: mod_deflate 

Apache 2.x 是通过mod_deflate 模块来实现压缩。尽管它的名字是deflate，但实际它是实现的gzip压缩方式（John：怪异吧！）。如果要实现像对script和样式表的压缩这种基本的配置只需要下面这一行就够了：

AddOutputFilterByType   DEFLATE      text/html    text/css    application/x-javascript

与mod_gzip不同，mod_deflate可以通过参数配置来控制压缩级别。要获取更多的信息，可查阅Apache 2.0 mod_deflate的文档。

代理缓存  Proxy Caching

以上介绍的简单配置对直接访问web服务器的方式来说没有一点问题，web服务器通过请求中的Accept-Encoding头信息来判断客户端是否可以支持压缩的数据，然后把压缩或没压缩的数据再返回给客户端，这些都是通过HTTP的header头信息来实现的。

但如果用户是通过代理上网的，那用户的请求也都是通过代理服务器中转发送的，这时就比较麻烦了：假如用户发请求给代理服务器时，并表明其不支持gzip，而代理服务器再中转数据时却将已经缓存过的压缩的数据返回给用户，这时就会造成用户看到的是一堆乱码，反之亦然。

要解决这个问题则要在服务器端加上vary头信息。mod_gzip默认是为所有的响应都增加Vary:Accept Encoding头信息，这样代理服务器就会缓存压缩和未压缩版的数据了。

特殊情况　Edge Cases

目前90%的浏览器都支持gzip。但还是会有一些特殊情况我们不得不考虑，如在早期的IE版本中，特别是IE5.5和IE6.0 sp1存在一些bug，一种比较安全的做法是用”浏览器白名单(browser whitelist)“，让服务器端只针对一部分浏览器发送gzip格式的数据。如下的设置就是只针对IE6~9的版本和Mozila 5～9的版本发送gzip数据。

Apache 1.3使用User-Agent:

mod_gzip_item_include　 reqheader 　”User-Agent: MSIE [6-9]”
mod_gzip_item_include 　reqheader　 “User-Agent: Mozilla/[5-9]“

Apache 2.x 使用 BrowserMatch :

BrowserMatch　 ^MSIE [6-9] gzip
BrowserMatch 　^Mozilla/[5-9] gzip

而针对代理缓存，一种方法是在Vary的头信息中加上User-Agent标识来告诉代理服务器，我们使用了白名单；在mod_gzip模块中，如果它发现配置了白名单，则会自动为Vary加上上User-Agent标识。但是不要指望代理服务器会缓存所有的浏览器白名单的每一个url副本。所以我们不得不采用另一个方法：为返回的响应中加上Vary : * 或 Cache-Control:private 头信息，以表明完全禁止代理服务器的缓存，不让代理去缓存任何一个组件，让用户通过代理时，都要去请求真正的服务器以获得页面数据，事实上Google和Yahoo！都是使用的这一策略，尽管它会带来更多的流量消耗。

还有一个特殊情况要指出，就是ETags（我们将会在Chapter 13章节单独提到），默认情况下它都不会被压缩，所以最好的办法就是干脆禁用ETags，这个还是放在Chapter  13章节再详谈吧。

例
下面三个链接分别是没有gzip压缩，只压缩了HTML和压缩了全部组件的三个链接页面：
Nothing Gzipped
http://stevesouders.com/hpws/nogzip.html
HTML Gzipped
http://stevesouders.com/hpws/gzip-html.html
Everything Gzipped
http://stevesouders.com/hpws/gzip-all.html
下图就是三者的具体数据量对比和时间对比：

法则3：增加Expires Header  Add an Expires Header 

在您设计网页时，快速的响应时间不应该是你唯一要考虑的，如果仅仅是这样，那我们采用法则1，把我们的页面设计成一个极端的网页：没有任何图片，script，样式表。我们都明白，图片、script、样式表这些组件可以增强用户体验，虽然它们会给页面带来较长的载入时间。你幸运了，在这一章介绍的法则3，我就要向你介绍如何最大限度地利用浏览器的缓存来使这些页面组件更高效的为我们的页面服务。

现在的网页所包含的组件越来越丰富，java applet去了，Flash来了，script也不可缺少，随着div的大潮，css样式表也少不了……　所以用户若第一次访问您的网页，则可能会产生多个HTTP请求；但如果您在请求返回中使用Expires头信息，则可以缓存这些组件，避免在随后的访问中产生不必要的HTTP请求，Expires头信息最常用于图片，其实它适合应用在所有的组件中，如scripts，样式表和Flash。但大多数当今的热门网站目前并没有这样做。在这一章节中我会提及如何让这些网站可以更快。在使用Header头信息时，也可能会有一定的额外开销，这点会在 “改变文件名”段落中再详谈.

Expires Header

浏览器使用缓存来减少HTTP请求数和减少HTTP的响应数据量，以达到更快的加载页面。web服务器通过Expries header来告诉web客户端（John：主要是浏览器）当前返回的组件在我指定的时间以前都是可用的，你（浏览器）可以留着下次备用(John：有点像我们在超市买牛奶时，随包装袋上返回的过期日期)。Expries header 在HTTP规范中描述为 “the date/time after which the response is considered stale.”，它附带在HTTP的响应中返回给客户端。

如上图，这是一个典型的expries header ，它告诉浏览器，直到2010年4月15日这个请示的返回都不会变化。如果这个头信息是随着一个图片返回的，那浏览器就会缓存这个图片，以为其后的页面浏览直接使用，以减少一个HTTP请示。 

Max-Age and mod_expires

在我解释缓存是如何更好的提升性能之前，有必要介绍一下与Expries header相关的几个头信息。Cache-Control header是在HTTP/1.1中被引入以弥补Expries header的不足。因为Expries header使用的是一个具体的日期，它就要求服务器与客户端之间要有严格的时钟检查，并且当过期日期到来之后，服务器端还必须配置一个新日期。

相反，Cache-Control 使用max-age来指定一个时间段来标识一个组件能使用多长时间。这个max-age是以秒为单位来描述的(John：有点保质期的概念)。如果在这个保质期内，这个组件再被请求，浏览器就直接使用缓存里的就行了。下面就是一个返回10年保质期的头信息。

使用Cache-Control虽然弥补了Expires的不足，但我们仍然还是得使用 Expires header以兼容那些不支持HTTP/1.1的浏览器(尽管这些流量可能还不到1%)。所以我们一般同时使用Expires和Cache-Control max-age，按HTTP规范这时会以max-age的时间为优先考虑，所以我们还是避免不了服务器与客户端之间的时钟检查和服务器端的新日期配置。幸运的是我们有Apache的 mod_expires模块，能让我们像设置max-age那样来配置Expires header，它使用ExpiresDefault来设置一个时间段，如下，为图片，scripts和样式表设置10年的有效期： 

<FilesMatch “\.(gif|jpg|js|css)$”>
ExpiresDefault “access plus 10 years”
</FilesMatch>

这个时间可以是年，月，周，天，小时，分钟甚至是秒。使用了这个模块，所有的响应返回中就会同时带着 Expires header 和 Cache-Control max-age 头信息：

其中Expires header所携带的过期时间具体是多少，则依赖于每个客户端什么时间发出的请求，在上面的例子中，始终是10年。这样就避免了我们每次在到期后都要重新设置服务器，mod_expires会搞定一切。图3-1是对10大网站使用这些headr的一个调查。有7家使用了这些header，其中有5家同时使用了
Expires 和 Cache-Control max-age(John：推荐)。各有2家分别只使用 Expires 或Cache-Control max-age。很遗憾有3家什么也没使用。 

从上图的百分比中俺发现有74.7%的组件没有被缓存或是有效期低于30天。一种解释就是这些组件因为业务关系而不应该被缓存，如新闻网站CNN.com就是个例子，138张图片中没有一张被缓存，这是因为很多新闻照片要被不断更新而不必缓存在用户端，所以这时更适合用Last-Modified heade，来通过组件的最后修改时间判断是否要读取新数据。 

表3-2的最后一项，显示了未被缓存的组件的最后修改时间的中分线，就CNN.com来说有一半的未缓存组件的最后修改时间是在227天前了，很显然这些组件是应该被缓存的。

这种情况也曾发生在Yahoo！，在过去，Yahoo！并没有缓存script,样式表和一些图片，是因为我们认为这样是经常变化的，用户有必要每次访问时都去请求一次以获取最新的。可问题是，在实际应用中，这些组件并不是我们想像中的那样要经常变化更新，我意识到应该把它们缓存来提升用户体验。后来，Yahoo！选择了去缓存它们，哪怕会带来一些额外的开发花销，这就是我马上要谈到的Revving Filenames。

改变文件名　Revving Filenames

如果我们已经为组件设置了缓存，可当这些组件又需要更新时，用户如何才到得到最新的组件呢？由我们前面介绍的Expires 或是 Cache-Control max-age header 都会让浏览器不检查任何改变，直接从本地硬盘中读取缓存，除非是过了有效期。所以我们能做的，就是在HTML页面中改变这个组件的文件名。在Mark Nottingham的文章”Caching Tutorial for Web Authors and Webmasters“谈到这个问题：

最优的方案还是改变它们的链接；只有这样，用户才能从服务器上获取更新。(The most effective solution is to change any links to them; that way, completely new representations will be loaded fresh from the origin server.)

说白了，还是要改变文件名。在已有的页面中改变文件名可能是件头疼的烦事，但是，不得不这样，如果您使用的是PHP,Perl等动态的页面，不妨利用一个变量为所有的组件命名，这样换起文件名来比较省事。在Yahoo！，我们是在组件名后面跟上版本号（如，yahoo_2.0.6.js），把这个版本号做为一个变量写在程序中，真的很省事。

举例　Examples

下面的两个链接，包包含有相同的组件：6个图片，3个script和1个样式表。第一个链接没有任何Expires header，而第二个链接，全有。
No Expires
http://stevesouders.com/hpws/expiresoff.php
Far Future Expires
http://stevesouders.com/hpws/expireson.php
我在900Kbps的DSL下测试，加了过期头设置的链接页面访问时间会减少600~260毫秒，能提升57%，如果页面的组件再多一点，这个百分比还会更高。

要说明一点，并不是说没有加过期头的组件就不会被浏览器缓存，它们也会被缓存，还记得我在Chapter B中介绍的有条件的GET请求吗，只不过，会多一个HTTP请求到服务器端以询问这个组件是否有效，如果这个组件的最后修改时间和以前一下，则直接使用缓存中的版本，HTTP返回中将不带这个组件的具体数据了。

为您页面上的组件贴上保质期吧，再加有有条件的GET请求，带来的会是减少近一半的HTTP请求数还有不必要的数据传输。

相关章节：

中文翻译：
翻译:High Performance Web Sites(1)-Chapter A　前端性能的重要性
翻译:High Performance Web Sites(2)-Chapter B　HTTP 概述
翻译:High Performance Web Sites(3)-Chapter 1    法则 1: 尽可能减少HTTP请求数
翻译:High Performance Web Sites(4)-Chapter 2   法则 2: 使用CDN 内容分发网络
翻译:High Performance Web Sites(5)-Chapter 3   法则3：增加Expires Header
翻译:High Performance Web Sites(6)-Chapter 4   法则4:使用Gzip压缩组件
翻译:High Performance Web Sites(7)-Chapter 5  法则5：将样式表放到HEAD中