Monthly Archives: June 2008

Web 前端优化最佳实践之 JavaScript 篇

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–

Web 前端优化最佳实践之 CSS 篇

Web 前端优化最佳实践第四部分面向 CSS。目前共计有 6 条实践规则。另请参见 Mozilla 开发者中心的文章：Writing Efficient CSS

1. 把 CSS 放到代码页上端 (Put Stylesheets at the Top)

官方的解释我觉得多少有点语焉不详。这一条其实和用户访问期望有关。CSS 放到最顶部，浏览器能够有针对性的对 HTML 页面从顶到下进行解析和渲染。没有人喜欢等待，而浏览器已经考虑到了这一点。

2. 避免 CSS 表达式 (Avoid CSS Expressions)

个人认为通过 CSS 表达式能做到的事情，通过其它手段也同样能做到而且风险更小一些。

3. 从页面中剥离 JavaScript 与 CSS (Make JavaScript and CSS External)

剥离后，能够有针对性的对其进行单独的处理策略，比如压缩或者缓存策略。

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

如果没有 JavaScript 与 CSS 可能更好。但，这是不可能的，SO，尽量小点吧。语法能简写的简写。

5. 使用 <link> 而不是@importChoose <link> over @import

在 IE 中 @import 指令等同于把 link 标记写在 HTML 的底部。而这与第一条相违背。

6. 避免使用Filter (Avoid Filters)

–EOF–
延伸阅读：

Oracle Hint: GATHER_PLAN_STATISTICS

今天 Oracle 公司 Real-World Performance Group 的 Andrew J. Holdsworth 与 Bob Carlin 来阿里作交流。尽管语言沟通上不是很顺畅，还是讨论的不亦乐乎。Andrew 过去也来过阿里巴巴作交流。

Andrew 今天提到了 GATHER_PLAN_STATISTICS ，这已经是短短一段时间第三次遇到这个 Hint 了，上次看到是在 Lewis 的 BLOG：DBMS_xplan in 10g，第二次在 Greg Rahn (也是 Real-World Performance Group 的成员)的 BLOG：Troubleshooting Bad Execution Plans ，以前或许也看到过，可能忽略了。

这个 Hint 在调查执行计划突变的时候非常有用，执行 SQL 的时候收集额外的统计数据。走投无路的时候，或许能用来救急。

另外一个以前忽略的话题是 CARDINALITY 评估错误引起的错误执行计划。事后查了一下，居然还有个 CARDINALITY hint (对，还有个 CARDINALITY Hint! )能直接指定 CARDINALITY 。

一天的讨论学到了两个知识点，已经很不错了. 这一天比较充实的.

–EOF–

下载 PPT : When to Use the Appropriate Database Technology，第二遍阅读的时候，发现这个 PPT 还是很好的。

Facebook 海量数据处理

对着眼前黑色支撑的天空 /  我突然只有沉默了
我驾着最后一班船离开 / 才发现所有的灯塔都消失了
这是如此触目惊心的 / 因为失去了方向我已停止了
就象一个半山腰的攀登者 / 凭着那一点勇气和激情来到这儿
如此上下都不着地地喘息着 / 闭上眼睛疼痛的感觉溶化了 
--达达乐队《黄金时代》

好几个地方看到这个 Facebook – Needle in a Haystack: Efficient Storage of Billions of Photos，是 Facebook 的 Jason Sobel 做的一个 PPT，揭示了不少比较有参考价值的信息。【也别错过我过去的这篇Facebook 的PHP性能与扩展性】

图片规模

作为世界上最大的 SNS 站点之一，Facebook 图片有多少? 65 亿张原始图片，每张图片存为 4-5 个不同尺寸，这样总计图片文件有 300 亿左右，总容量 540T，天! 峰值的时候每秒钟请求 47.5 万个图片 (当然多数通过 CDN) ，每周上传 1 亿张图片。

图片存储

前一段时间说 Facebook 服务器超过 10000 台，现在打开不止了吧，Facebook 融到的大把银子都用来买硬件了。图片是存储在 Netapp NAS上的，采用 NFS 方式。

图片写入

尽管这么大的量，似乎图片写入并不是问题。如上图，是直接通过 NFS 写的。

图片读取

CDN 和 Cachr 承担了大部分访问压力。尽管 Netapp 设备不便宜，但基本上不承担多大的访问压力，否则吃不消。CDN 针对 Profile 图象的命中率有 99.8%，普通图片也有 92% 的命中率。命中丢失的部分采由 Netapp 承担。

图中的 Cachr 这个组件，应该是用来消息通知(基于调整过的 evhttp的嘛)，Memcached 作为后端存储。Web 图片服务器是 Lighttpd，用于 FHC (文件处理 Cache)，后端也是 Memcached。Facebook 的 Memcached 服务器数量差不多世界上最大了，人家连 MYSQL 服务器还有两千台呢。

Haystacks –大海捞针

这么大的数据量如何进行索引? 如何快速定位文件? 这是通过 Haystacks 来做到的。Haystacks 是用户层抽象机制，简单的说就是把图片元数据的进行有效的存储管理。传统的方式可能是通过 DB 来做，Facebook 是通过文件系统来完成的。通过 GET / POST 进行读/写操作，应该说，这倒也是个比较有趣的思路，如果感兴趣的话，看一下 GET / POST 请求的方法或许能给我们点启发。

总体来看，Facebook 的图片处理还是采用成本偏高的方法来做的。技术含量貌似并不大。不清楚是否对图片作 Tweak，比如不影响图片质量的情况下减小图片尺寸。

–EOF–