对于构建 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--

Posted by Fenng at 10:11 PM | Permalink | Comments (2)

对于前端优化技术，我之前根据已经从 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--

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

Posted by Fenng at 8:51 AM | Permalink | Comments (6)

搜索引擎的行为会对网站架构稳定性有影响么? 肯定的。影响都有哪些呢? 且说，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 以及其他搜索引擎默认行为都是可以承受的。

Posted by Fenng at 9:06 AM | Permalink | Comments (3)

广而告之： 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, 注意到火车站和机场的公示牌显示倒是挺符合阅读习惯的。

Posted by Fenng at 12:57 PM | Permalink | Comments (8)

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

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

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

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

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

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

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

--EOF--

Posted by Fenng at 9:41 PM | Permalink | Comments (7)

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

误区一：SQL 慢，加索引

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

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

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

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

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

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

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

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

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

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

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

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

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

--EOF--

Posted by Fenng at 5:48 PM | Permalink | Comments (13)

前面几天介绍的 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 页面测试一下。

Posted by Fenng at 9:25 PM | Permalink | Comments (3)

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--

Posted by Fenng at 9:16 AM | Permalink | Comments (8)

Web 前端优化最佳实践第六部分面向 图片(Image)，这部分目前有 4 条规则。在最近的 Velocity 2008 技术大会上，Yahoo! 的 Stoyan Stefanov 做的 Image Optimization: How Many of These 7 Mistakes Are You Making 也非常有参考价值。结合一起说一下。

1. 优化图片 (Optimize Images)

使用 GIF 、JPG 还是 PNG 格式的图片? 尽可能的使用 PNG 格式的图片，更多的功能，更小的尺寸(与 GIF 相比)。

对于 PNG 图片，考虑用 Pngcrush 或类似的工具进行优化。常见的工具如下表:

• pngcrush http://pmt.sourceforge.net/pngcrush/
• pngrewrite http://www.pobox.com/~jason1/pngrewrite/
• OptiPNG http://www.cs.toronto.edu/~cosmin/pngtech/optipng/ (refer: 教程)
• PNGOut http://advsys.net/ken/utils.htm

另请参见: Five Tips For the Effective Use of PNG Images

对 JPEG 图片的优化工具：

• jpegtran (http://jpegclub.org/)

必需要强调的是，图片设计的同学啊，请考虑设计面向 Web 的图片，不要动不动就设计超过可接受尺寸之外大家伙，这应该是一种习惯，而不是什么高超的技能，只需要记住就成了。

2. 使用 CSS Sprites 技巧对图片优化 (Optimize CSS Sprites)

之前提到过，简单的说就是"利用 CSS background 相关元素进行背景图绝对定位"，把多次 HTTP 调用变为一次调用，更多参考：CSS Sprites: Image Slicing's Kiss of Death

补充一下：对于这个技巧我曾经见到有人滥用的。把多个背景图片揉成一个，减少　HTTP 调用，这是一个很好的思路。但一定要记住这个大图片不能太"重"，我看到过 100 多K 的背景图。一个图片就把整个网站拖得很慢。比较好的例子可以参考雅虎关系的这个图.

更新：使用 CSS Sprites 的一个潜在的副作用是客户端将消耗更多内存(参考)。

3. 不要在 HTML 中使用缩放图片 (Don't Scale Images in HTML)

更多的时候，可能是因为偷懒而没有制作合适大小的图片，如果是批量处理图片的话，可能一条 ImageMagic 命令（convert ）就能搞定 。必须提及的是，看到太多的对图片拉伸很难看的页面，救救这些页面!

4. 用更小的并且可缓存的 favicon.ico (Make favicon.ico Small and Cacheable)

更小，可缓存，这两条可能都不是问题。问题是，太多站点根本没有 favicon.ico 。有的时候，判断独立域名的 Blog 是否专业，基本看一下是否有 favicon.ico 就差不多了。

--EOF--

补充：视觉设计者应该尽量考虑控制图片大小，推荐在 200K 以下。这不是胡说的，参考页面。

Posted by Fenng at 8:56 AM | Permalink | Comments (12)

Web 前端优化最佳实践之 JavaScript 篇，这部分有 6 条规则，和 CSS 篇 重复的有几条。前端优化最佳实践，最重要的还是"实践"，要理解这东西容易得很，关键是要去"实践"，去"执行"，去"反馈"，去获取受益。

1. 脚本放到 HTML 代码页底部 (Put Scripts at the Bottom)

当一个脚本在下载的时候，浏览器干不了其它的事儿(串行了)。所以，把它扔到最后面去处理。对于一些功能性的脚本，可能实现起来有些两难。不过对于国内网站来说，有很多使用 Google Analytics 服务进行网站数据分析的。这这一点来说，绝对可行的建议，放到页面最底下。

2. Make JavaScript and CSS External

参见 CSS 篇的描述

3. 精简 JavaScript 与 CSS (Minify JavaScript and CSS)

参见 CSS 篇的描述

4. 移除重复脚本 (Remove Duplicate Scripts)

对于一些历史遗留站点或是论坛类的网站来说，这倒是比较常见的。接手维护人前后变化过多，每个人都有自己的一套。这就会带来一些潜在的麻烦。

5. 减少 DOM 访问 (Minimize DOM Access)

• 缓存已经访问过的元素 (Cache references to accessed elements)
• "离线"更新节点, 再将它们添加到树中 (Update nodes "offline" and then add them to the tree)
• 避免使用 JavaScript 输出页面布局--应该是 CSS 的事儿 (Avoid fixing layout with JavaScript)

6. Develop Smart Event Handlers

除了英文解释外，这里也提醒一下注意关于 Java Script 内存泄漏的问题。

另外推荐一篇《如何优化 JavaScript 脚本的性能》，关于 Ajax 优化指导原则，可以参见 提高 Ajax 应用程序性能，避开 Web 服务漏洞。

后记1) ：整理得差不多之后，发现网络上已经有一篇 《Yahoo!网站性能最佳体验的34条黄金守则》，是翻译稿。看来我做了一部分重复劳动。

后记 2)：CSS / JavaScript 都有优化规则。但似乎缺少了对 Flash 的优化实践。

--EOF--

Posted by Fenng at 12:32 PM | Permalink | Comments (1)