对于构建 Web 站点，《构建可扩展的 Web 站点》重点并不是讲述 How-To 的 -- 讲述 How-To 的书已经很多了，却很少有图书愿意分一部分篇幅讲述 Why 。所以有的人可能认为"缺少细节"，有的人则读罢大呼过瘾。我一般的建议是，如果你觉得这本书没劲，那就再读一下第二遍。

为什么我推荐这本书? 主要的原因是这本书给出了可扩展站点的必备要素，而书的内容几乎全是作者在 Flickr 站点实战中得来的经验谈，如果您的站点是个发展中的 Web 2.0 站点，你可以认为这本书是个技术"标本"。如果回顾一下我的 Blog 的话，会发现多则关于 Flickr 的技术话题：

• 学习 Flickr 的 基于 LAMP 的容量规划经验
• Flickr 的开发者的 Web 应用优化技巧
• Flickr 的访问统计实现以及其他
• 从 Flickr 的 DB 服务器配置说起 Swap

当然，这些这些都是皮毛。

如果你正在为你的网站性能问题而苦恼，那么建议直接去读第八章，这一章也是让很多人觉得有价值的章节，因为讲的是"瓶颈"(可见如何解决网站性能瓶颈是个多么普遍的话题啊)。如果严格的来说，这一章的内容并非有多么深入，但对于需要对网站性能瓶颈建立全局概览的朋友来说，足够了。毕竟我们看书不是挑刺，解决自己的问题是首先要考虑的问题。

对我来说，第九章也让我收获良多。第四层负载均衡和第七层负载均衡的差别，什么时候合适用第四层均衡，什么时候用第七层均衡，如何构建一个第七层负载均衡网络... 这些看似都是基础的问题，但实践中是需要仔细平衡的一个事儿。并非想象的那么简单。

如果 Cal Henderson 能有下一部书的写作计划，我倒是希望能看到设计可扩展的 Web 2.0 站点的主题，当然，可能我们看不到了，因为，Flickr 被 Yahoo! 收购后似乎缺失了进取心，谁知道 Cal 会不会跳槽而走呢?

PS: 这也是我认为"Web 2.0 网站架构不可或缺的图书"清单中的一本。

--EOF--

对于前端优化技术，我之前根据已经从 14 条增加到 34 条的 Exceptional Performance 做了一份笔记：

• Web 前端优化最佳实践之 内容篇
• Web 前端优化最佳实践之 Server 篇
• Web 前端优化最佳实践之 Cookie 篇
• Web 前端优化最佳实践之 CSS 篇
• Web 前端优化最佳实践之 JavaScript 篇
• Web 前端优化最佳实践之 图象篇
• Web 前端优化最佳实践之 Mobile(iPhone) 篇

这些最佳实践看似没什么艰深的技术含量，而网络上也能看到很多关于网络前端优化的文章，但是实际上我发现能操作、执行下去的网站还是不多，更多的时候，大家把类似的信息当成参考信息而已，看过，丢掉，如此而已。Web 前端优化的时间准则有些其实也算是常识。我曾经听到过某家大型网站的案例：用户反映网站速度慢，进行了多次技术会议，多个方案评估之后，"发现"是图片拖慢了整个网站，于是，大家的意见统一了，建设更多的 CDN ... 可实际上，这个问题或许不需要过多的投入研究，简单的分析一下页面元素比例就知道了。

这本《高性能网站建设指南》的内容以最初的 14 条优化准则写的，精炼简洁(几个小时就能读完)，我觉得已经抓住了前端优化的至少 80% 的内容，加上书中的一些引申内容(尤其是涉及到的 RFC)，如果这些都能做好，那么已经能够解决绝大部分问题了。所以是绝对值得网站运维人员一读。而且，我也认为这是 Web 2.0 网站架构不可或缺的图书 之一。

另外，发现博文视点的这一批 O'Reilly 的图书都是有索引的，很难得。

--EOF--

链接：购买《高性能网站建设指南》

搜索引擎的行为会对网站架构稳定性有影响么? 肯定的。影响都有哪些呢? 且说，Google 的 Jayant Madhavan 在 VLDB 2008 会议上做了题为 Google's Deep-Web Crawl 的报告。这个报告其实也透漏出了 Google 对一些网站的潜在影响的某个方面。

何为 Deep Web ?

• HTML 表单后的隐藏内容(表单提交后显示的内容)
• 通过普通搜索引擎获取不到的内容

Deep Web (译为深层网页?) 目前容量大约有多大? 超过100 亿的不重复表单，而且大量都是结构化数据。对搜索引擎用户来说，这部分潜藏的数据是非常有价值的。Deep Web 包括的信息内容：

• 信息型表单；
• 登录表单不要；
• 交互性表单也有用；

Google 的解决办法是基于信息模板(informative templates)。其实不难理解，这些模板（似乎也叫查询模板, Query Template）是在 Google 进行了大量的数据分析的基础上得出来，然后通过反馈迭代修正，加上Google 引以自豪的算法啦，渐渐的模板就会很好用了。

绝大多数网站表单后面是要有数据库支撑的。Google 自己计算出来的模板实际上会对应被爬行网站的 DB 查询上来(Google 也是黑箱研究嘛)，如果查询模板不是很匹配，或者是 Google 查询的频率过高，相信会对一个被爬行网站的稳定性带来很大冲击。尤其是针对数据库，一时爆发的大量查询引发的高负载可能会让系统撑不住。

--EOF--

更多的时候，搜索引擎带给一个网站的访问压力甚至大于用户带来的压力，所以，设计的时候也应该尽量采取悲观的方式，不能完全期待 Google 以及其他搜索引擎默认行为都是可以承受的。

广而告之： 7月26日QClub杭州站-- 支付宝首席架构师程立与您分享"当SOA遭遇现实"的心得

上周五去了一趟淘宝，在淘宝二楼实时展示交易信息的大屏幕前看了一会儿。发现关于商品显示的排序列表是两排，左右排列的。

1 商品名一 2 商品名二
3 商品名三 4 商品名四
5 商品名五 6 商品名六
......
N-1 商品名N-1  N 商品名 N
......

尽管符合从左到右的阅读习惯，看起来感觉怪怪的。前一段时间有不少关于电梯楼层按钮排列问题的帖子(一，二），针对电梯的按钮应该说已经讨论的很好了，但我感觉如果针对 Web 页面上大量列表项的排列显示来说，很有值得商榷的地方。

我再抛一个另外的反面例子，关于百度 Mp3 歌曲 Top 500 的列表展示：

(点击图片看大图或者到 Baidu 站点上体验)

假设 M 行 x N 列的展示，如果 M 很大，而 N 很小，在前面几行过去之后(一般是 N行*N列后)，会发现非常难以定位你要找的歌曲。尤其是越到后面效果越差。如果 M 和 N 都很小，那么相差是不大的(不知道这是什么心智模型? 尤其是对该项的描述也符合 M：N 值很小，比如 Flickr 的图片展示）。

这个其实和电梯楼层按钮排列的问题不太一样：电梯上面只有一个按钮(楼层号)，而 MP3 列表排列项后面还有该项的名字或描述(MP3 名字, 艺术家名字)。需要展示的内容性质和信息量已经变化了。

这只是 UE 门外汉的个人看法。供参考。

--EOF--

BTW, 注意到火车站和机场的公示牌显示倒是挺符合阅读习惯的。

在 IBM developerworks 网站看到一篇不错的介绍 Nginx 的文档：使用 Nginx 提升网站访问速度。针对其中的几个描述，我个人感觉不是很清晰：

# 目前官方 Nginx 并不支持 Windows，您只能在包括 Linux、UNIX、BSD 系统下安装和使用；

虽然 Nginx 官方并不提供 Windows 平台的下载，但还是有热心的开发者维护 Windows 平台上编译好的版本，而且，从邮件列表中观察了一段时间，和官方发布的版本基本上是同步的。

当然，我相信不太会有人在 Windows 上跑 Nginx 吧?

还有一句话我觉得也不太妥当：

# Nginx 本身只是一个 HTTP 和反向代理服务器，它无法像 Apache 一样通过安装各种模块来支持不同的页面脚本，例如 PHP、CGI 等；

其实针对 Nginx 的内建的 Perl 模块现在就是支持的(当然，更准确的说是在实验阶段)。

--EOF--

很多 Discuz! 的用户在论坛规模达到一定程度上，就要经常性的考虑优化的问题。现在网络上的很多热心的技术人都分享了 Discuz! 的优化经验，应该说，很多经验还是不错的，但也有的帖子可能会让用户走入误区。

误区一：SQL 慢，加索引

多数情况下，数据库可能是瓶颈。通过 Slow Query Log 发现执行时间比较长的 SQL 并不难，于是有的人一看 SQL 走了全表扫描，干脆添加个索引好了。

其实这个地方值得商榷的。第一，必须确定一下该 SQL 执行次数到底是怎样的? 执行真的很频繁? 那么对应的页面是否通过 Cache 可以减少对 DB 的冲击? 如果可以，尽量不要添加索引，索引本身对表的负面影响也是很大的，比如降低更新速度，影响并发能力等。

误区二：瓶颈一定在数据库上

前面说，数据库"可能"是瓶颈，但不总是瓶颈，优化的第一步，必需要有针对瓶颈优化。很多时候，图片访问带来的压力甚至比数据库压力还大 --- 有的用户数据库、用户上传的图片文件、Web 服务器都扔到一台服务器上，这时候，第一手去调整 MySQL 或许会有作用，但价值不大。

应该说，瓶颈的有效定位的确是个技术活儿，对于一个新的论坛环境，也有人用逐一尝试法来做，这倒也没什么。

误区四：盲目的静态编译 MySQL

静态编译 MySQL 有好处，但如果系统已经在线上运行了，在原有环境中进行静态编译未必能带来多大好处。我问过一些朋友，静态编译到底带来多大好处? 没有几个人能说清楚。

对于 PHP 也是这样，如果一次优化从其它方式上能带来更清晰、直接的开销，就不要重新编译

误区五：反复尝试，但不建立基准数据

这其实是第四点的延伸。而建立基准数据，实在应该是优化的最基本的步骤。这样才能有效的评估优化的效果。否则的话，象误区一描述的，添加了一个索引，短期内可能感觉快了，长期看，性能可能又会慢下来。

误区六：一次进行多个优化步骤

这可能是比较普遍的"习惯"了，有的朋友喜欢一次调整多个参数或是多个环境的设置，然后观察效果。如果每个步骤都是"对"的话，那么效果看起来是好的。如果有的步骤调节"错"的话，可能会抵消那些有效果的优化步骤。

优化策略是个见仁见智的问题。以上只是个人浅见，欢迎留言探讨。

--EOF--

前面几天介绍的 Web 前端优化最佳实践 系列离不开一个关键词：YSlow。简单的说，YSlow 是以最佳实践得到的规则为基础，进行 Web 页面的性能评估，并给出指导建议。

而 Velocity 2008 上发布的 Jiffy ，我断言是一个比 YSlow 更有前途的工具，只是当前还没引起足够的关注度。之所以说 Jiffy 更有前途，是因为 Jiffy 设计初衷是面向端到端的，不只是个工具（Jiffy 有基于 FireBug 的插件 Jiffy Firebug Extension for Firefox ），而变成了框架，对于 Web 上的每个组件，都能进行性能度量。如果说 YSlow 是类似"望闻问切"的诊断方式，那么 Jiffy 就是 CT 检查了。

下图揭示了 Jiffy 的工作机制：

通过页面中植入 Jiffy.js ，针对 Apache 做特定的设置，当用户调用页面的时候，拦截并记录 Jiffy 的相关请求，接着把所有的性能信息注入数据库中，然后从数据库中抽取数据进行展现。这正是当前绝大多数 Web 公司都缺少的性能衡量策略(尤其是 JavaScript 的精细度量)。唯一美中不足的是使用 Oracle XE 做性能信息存储的数据库，相信不久就会完美支持 MySQL 。

关心 UE 的朋友可以在自己的环境里面搭一套 Jiffy 啦，有好处没坏处。

--EOF--

更新：有得朋友说，安装了，点击了，没反应。这是因为页面中没有嵌入 jiffy.js 脚本。可以到我的 egosurf 页面测试一下。

Web 前端优化最佳实践最后一部分是针对移动应用的，其实只是针对 iPhone 的，目前只有两条规则。

1. 单个数据对象小于 25K (Keep Components under 25K)

这个似乎只是针对 iPhone 研究的。建议保持单个 Web 数据对象在 25 K 以下。为什么是 25K? Apple 官方信息指出可缓存到内存中的 Web 对象最大支持到 10M，但经过测试，发现也就是 25K 左右。

iPhone 在市场上的优异表现，让 Web 人员不得不考虑如何针对其进行优化。相信这部分内容也在不断变化中。

2. Pack Components into a Multipart Document

把Web 页面组件打包成一个多部分组成的文档。其目的是减少 HTTP 请求。对这部分语焉不详，等待后续更新吧。

--EOF--

Updated: 根据这篇 iPhone caching 的文章，可供 Cache 的最大单个数据对象是 15K，而不是前面说的 25K。iPhone 总的 Cache Size 为 1.5M。浏览器地址栏的刷新按钮将导致无条件刷新所有组件。这些也是挺有趣的。