Flickr 是 Web 2.0 的代表站点。面对的网络问题除了一般 Web 站点都会有的内容优化之外, 还有必须要灵活处理 JavaScript 与CSS的频繁变化后部署分发带来的复杂性。

　　设定文件大小的策略 首先面临的一个问题是把所有的 JavaScript 与 CSS 放到一个文件中好呢，还是分割成多个文件? 从减少网络请求的角度上考虑, 前者更好，后者差。但是从并行的角度考虑, IE 与Firefox 默认情况下都只能同时从一个域请求两个资源. 这会在很多情况下给用户带来不良的使用体验–必须所有的文件都下载完毕才可以看到像样的页面. Flickr 采用了折衷的办法–在保持文件数量尽可能少的情况下，把JavaScript 与 CSS 分成多个子文件. 这在开发上带来了复杂性，但是对性能的收益是巨大的。

　　压缩的优化问题 毫无疑问，对站点内容进行压缩是一个比较常用的 Web 优化手段.但是并不一定都能达到理想的效果。原因在于mod-gzip 模块不但消耗服务器端 CPU 资源，也消耗客户端 CPU 资源. 而且, mod_gzip 压缩文件后创建的临时文件是放到磁盘上的，这也会给磁盘 IO 带来严重的问题. Flickr 采用的是 Httpd 2.x 以后支持的mod_deflate 模块.压缩操作都在内存中进行。mod_deflate 在 Httpd 1.x 是不可用的, 不过可以通过创建RAM 盘的方式来间接提高性能。

　　当然, mod_gzip 到也不是一无是处, 对于预压缩的文件, 还是有好处的. 而且, 采用压缩的时候,也要注意策略. 图片文件压缩就没什么必要了(Flickr 上图像多, 而且压缩得不到什么好处). Flickr 只对 JavaScript 和 CSS 进行压缩. mod_gzip 新一点的版本能够自动通过配置 mod_gzip_update_static 选项自动处理 预压缩的文件. Cal 也指出这个特性在一些旧版本的浏览器上会出问题。

　　压缩的另一个主要手段是内容的压缩. 针对 JavaScript 可以进行通过减少注释、合并空格、使用紧凑的语法等小技巧(Google 的所有脚本都非常难读，而且非常紧凑，思想类似).当然，经过这样处理的 JavaScript 可能带了很多括号不容易解析，Flickr 使用了 Dojo Compressor 来构建解析树。Dojo Compressor 开销很低，而且对于最终用户是透明的. JavaScript 的处理方法介绍过，CSS 处理则相对简单.通过简单的正则表达式替换(比如把多个空格替换为一个空格符), 最高可以获得 50% 的压缩比。

　　Caching 的优化 Flickr 的开发者充分利用了 Http 1.1 规范定义的 Etag 与 Last-Modified 机制 来提高 Caching 的效率。值得注意的是，Cal 介绍了一个在负载均衡条件下的 e-Tag 小技巧. 即可以设定 Apache 通过文件调整时间与文件大小获得 E-Tag ,而默认情况下, Apache 是通过文件节点获取 e-Tag 的。当然，这也不是很完美，因为会影响 if-modified-since 。

　　灵活运用mod_rewrite 据说Flickr 网站应用是进行每日构建的(Daily Build)。 如果没有一个灵活的机制恐怕这是不可想象的。而且，在 Flickr 这样的站点, 内容的修改同步的处理都是很让人头疼的难题. 他们的利器是 mod_rewrite 的灵活运用。通过配置 URL 重写规则，很容易切换到不同的环境下。听起来很简单, 但是没有一定的 Web 技术功力谈何容易做到 ?!

　　通过这几个主要方法的运用，我们看到了如梦幻一般高性能的 Flickr 。

作者：DBA notes　 来源：Flickr中文网