June 2008 Archives

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。目前共计有 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--

延伸阅读：

• 《Web 前端最佳实践之内容篇》
• 《Web 前端最佳实践之Server篇》
• 《Web 前端最佳实践之Cookie篇》

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

我们将基于千万级的用户群基础开发一个互联网网站平台，前所未有，不同以往，寻求开发高手加盟。

开发语言以 PHP 为主，数据库 MySQL，搜索用 Lucene 实现。

您将在以下环境下工作：

1、一个完全自行开发的高度定制 Full Stack PHP 框架，单一入口方式，全面支持分布式部署的多层架构方案。开发简单，安全高效；

2、开发环境与生产环境完全基于 Slackware Linux，软件版本更新与时俱进，高度定制编译优化，大致列举如下：

• Nginx 0.7.3
• PHP 5.2.6
• MySQL 5.1.25
• jQuery 1.2.6
• Xcache 1.2.2
• Memcached 1.2.5
• ImageMagick 6.4.2-0
• Varnish 2.0.0 tech preview 1
• Lucene 2.3.2

3、一个基于 Lucene 实现的可应付高并发请求的搜索框架，集成简单，伸缩性好。

4、高度注重对前端体验的优化，并在框架内实现了透明化的优化处理；

5、注重任何细节，为了减少 1ms 的程序执行时间，或者为了减少哪怕一个 http 请求，我们可以研究一整天，一直到认为最优化为止；

6、对框架和整体代码进行不断的 review，以理论上的的安全和高效执行的标准来严格要求，多一分不行，少一分也不可；

7、注重国内外技术趋势，乐于参加各种业内聚会。第一期上线后，我们也会总结我们的经验教训，与大家共分享。

目前进展

• 1、第一期功能需求的开发工作即将完成，只要通过最终的代码检查和上线测试，即可上线；
• 2、在整体框架下实现的前端体验，不需要任何特殊处理，任何页面均可达到 YSlow 的 95-99 分以上的评价；
• 3、目前正在为各个功能的跨 PC、手持设备的浏览器页面自适应，绞尽脑汁中。

如果您想加入团队，您需要有以下资格：

• 1、熟悉 Linux 下的 PHP5 + MySQL5 的开发，对面向对象、三层结构开发方式有深刻的理解；
• 2、逻辑思维能力清晰，有良好的自我管理能力和团队工作心态，乐于沟通、分享和共同成长；
• 3、有 XHTML+CSS+Javascript 前端能力者更佳。有 Java、C 或者开源软件开发经验者更佳。

如何认定资格?

• 1、无任何学历限制，通过我们的面试即可。

薪酬待遇

• 1、以斐波纳契数列中第六个数字为起点。

有兴趣者，请发您的简历与 zhanghe4(at)163.com 联系。

工作地点：北京东北三环。

以上是代朋友发的招聘信息(如果有笔误是我的事儿)。另外，杭州本地也在帮其它朋友找 PHPer ，有兴趣可以联系我。

Web 前端优化最佳实践第三部分面向 Cookie 。目前只有 2 条实践规则。

1. 缩小 Cookie (Reduce Cookie Size)

Cookie 是个很有趣的话题。根据 RFC 2109 的描述，每个客户端最多保持 300 个 Cookie，针对每个域名最多 20 个 Cookie (实际上多数浏览器现在都比这个多，比如 Firefox 是 50 个) ，每个 Cookie 最多 4K，注意这里的 4K 根据不同的浏览器可能不是严格的 4096 。别扯远了，对于 Cookie 最重要的就是，尽量控制 Cookie 的大小，不要塞入一些无用的信息。

2. 针对 Web 组件使用域名无关性的 Cookie (Use Cookie-free Domains for Components)

这个话题在此前针对 Web 图片服务器的讨论中曾经提及。这里说的 Web 组件(Component)，多指静态文件，比如图片 CSS 等，Yahoo! 的静态文件都在 yimg.com 上，客户端请求静态文件的时候，减少了 Cookie 的反复传输对主域名 (yahoo.com) 的影响。

从这篇 When the Cookie Crumbles 能看出，MySpace 和 eBay 的 Cookie 都不小的，想必是对用户行为比较关心。eBay 前不久构造了 Personalization Platform ，就是从 Cookie 的限制中跳出来。

延伸阅读：

• 《Web 前端最佳实践之内容篇》
• 《Web 前端最佳实践之Server篇》

--EOF--

Web 前端优化最佳实践第二部分面向 Server 。目前共计有 6 条实践规则。【注，这最多算技术笔记，查看最原始内容，还请访问：Exceptional Performance : Best Practices for Speeding Up Your Web Site 】

1. 使用 CDN (Use a Content Delivery Network)

国内 CDN 的普及还不够。不过我们有独特的电信、网通之间的问题，如果针对这个作优化，基本上也算能收到 CDN 或类似的效果吧(假装如此)。【Tin 说国内 CDN 用的挺多，看看 CDN 厂商的市场就知道了，还没走入寻常百姓家】

2. 添加 Expires 或 Cache-Control 信息头 (Add an Expires or a Cache-Control Header)

ExpiresActive On
ExpiresByType image/gif "modification plus 1 weeks"

Lighttpd 启用 mod_expire 模块 后：

$HTTP["url"] =~ "\.(jpg|gif|png)$" {
     expire.url = ( "" => "access 1 years" )
}

Nginx 例子参考:

location ~* \.(jpg|gif|png)$ {
  if (-f $request_filename) {
        expires      max;
    break; 
  }        
}

3. 压缩内容 (Gzip Components)

对于绝大多数站点，这都是必要的一步，能有效减轻网络流量压力。或许有人担心对 CPU 压缩对于 CPU 的影响，放心大胆的整吧，没事儿。Nginx 例子：

gzip            on;
gzip_types      text/plain text/html text/css ext/javascript;

另外参见：

IIS 如何启用 Gzip 压缩?

4. 设置 Etags (Configure ETags)

对于 Etag，可能是多数网站维护者都会忽略的地方。在这一系列优化规则出现之前，可能互联网上绝大多数站点都对这个问题忽略了。当然，Etag 对多数站点性能的影响并不是很大。除非是面向 RSS 的网站。【看到有朋友批评说写的简略，并且说 IE 不支持 ETag。明确说一下：IE 支持 ETag，倒是使用 IIS 要注意相关 Etag Bug。】

补充：我的意思是"很多网站在不注意的情况下都是打开 Etag 的，而没有网站关心如何用，消耗资源而不知。并不是说 Etag 不好，合理利用 Etag ，绝对能取得很好的收益.

5. 尽早刷新 Buffer (Flush the Buffer Early)

对这一条，琢磨了半天，貌似还是异步的思路。能更好的提升用户体验?

6. 对 AJAX 请求使用 GET 方法 (Use GET for AJAX Requests)

XMLHttpRequest POST 要两步，而 GET 只需要一步。但要注意的是在 IE 上 GET 最大能处理的 URL 长度是 2K。

前一篇：

• 《Web 前端优化最佳实践之内容篇》

下一篇分析一下 Cookie 。

--EOF--

Updated: 另请参见楼下高春辉的留言，很精彩。

Yahoo! 的 Exceptional Performance team 在 Web 前端方面作出了卓越的贡献。广为人知的优化规则也由 13 条到 14 条，再到 20 条，乃至现在的 34 条--真是与时俱进啊。最新的 34 条也针对不同的角度做了分类。

面向内容的优化规则目前有 10 条。

1. 尽量减少 HTTP 请求 (Make Fewer HTTP Requests)

作为第一条，可能也是最重要的一条。根据 Yahoo! 研究团队的数据分析，有很大一部分用户访问会因为这一条而取得最大受益。有几种常见的方法能切实减少 HTTP 请求：

• 1) 合并文件，比如把多个 CSS 文件合成一个；
• 2) CSS Sprites 利用 CSS background 相关元素进行背景图绝对定位；参见：CSS Sprites: Image Slicing's Kiss of Death
• 3) 图像地图
• 4) 内联图象 使用 data: URL scheme 在实际的页面嵌入图像数据.

2. 减少 DNS 查找 (Reduce DNS Lookups)

必须明确的一点，DNS 查找的开销是很大的。另外，我倒是觉得这是 Yahoo! 所有站点的通病，Yahoo！主站点可能还不够明显，一些分站点，存在明显的类似问题。对于国内站点来说，如果过多的使用了站外的 Widget ，也很容易引起过多的 DNS 查找问题。

3. 避免重定向 (Avoid Redirects)

不是绝对的避免，尽量减少。另外，应该注意一些不必要的重定向。比如对 Web 站点子目录的后面添加个 / (Slash) ，就能有效避免一次重定向。http://www.dbanotes.net/arch 与 http://www.dbanotes.net/arch/ 二者之间是有差异的。如果是 Apache 服务器，通过配置 Alias 或mod_rewrite 或是 DirectorySlash 能够消除这个问题。

4. 使得 Ajax 可缓存 (Make Ajax Cacheable)

响应时间对 Ajax 来说至关重要，否则用户体验绝对好不到哪里去。提高响应时间的有效手段就是 Cache 。其它的一些优化规则对这一条也是有效的。

5. 延迟载入组件 (Post-load Components)

6. 预载入组件 (Preload Components)

上面两条严格说来，都是属于异步这个思想灵活运用的事儿。

7. 减少 DOM 元素数量 (Reduce the Number of DOM Elements)

8. 切分组件到多个域 (Split Components Across Domains)

主要的目的是提高页面组件并行下载能力。但不要跨太多域名，否则就和第二条有些冲突了。

9. 最小化 iframe 的数量 (Minimize the Number of iframes)

熟悉 SEO 的朋友知道 iframe 是 SEO 的大忌。针对前端优化来说 iframe 有其好处，也有其弊端，一分为二看问题吧。

10. 杜绝 http 404 错误 (No 404s)

对页面链接的充分测试加上对 Web 服务器 error 日志的不断跟踪能有效减少 404 错误，亦能提升用户体验。值得一提的是，CSS 与 Java Script 引起的 404 错误因为定位稍稍"难"一点而往往容易被忽略。

这是内容篇的 10 条。应该说具体引导性的内容还不够详细。逐渐会根据自己的理解补充上来。

--EOF--

几乎每个接触类 Unix 操作系统的工程师都知道如何查看系统负载。但这东西的工作机理到底是怎样的，可能没有多少能说清楚。对比了一些相关信息，加上自己的理解，做一下笔记。

什么是 Load ? 什么是 Load Average ?

Load 就是对计算机干活多少的度量(WikiPedia: the system load is a measure of the amount of work that a computer system is doing)。也有简单的说是进程队列的长度. Load Average 就是一段时间 (1 分钟、5分钟、15分钟) 内平均 Load 。【最好的参考文章：UNIX® Load Average Part 1: How It Works】

下面是一个 uptime 命令输出：

$ uptime
 18:57:48 up 423 days,  3:55,  2 users,  load average: 1.16, 1.12, 1.20

尽管各种信息来源的定义都不太确定。能确定的一件事情是，你不能精确获取当前时间的 Load . 最小的计算粒度是 5 秒钟(CALC_LOAD 每 5HZ 计算一次, 5HZ 为 5秒钟，这里的 HZ 是系统定义的变量). 参见 Linux Kernel 这段代码:

 869        count -= ticks;
 870        if (unlikely(count < 0)) {
 871                active_tasks = count_active_tasks();
 872                do {
 873                        CALC_LOAD(avenrun[0], EXP_1, active_tasks); 
 874                        CALC_LOAD(avenrun[1], EXP_5, active_tasks);
 875                        CALC_LOAD(avenrun[2], EXP_15, active_tasks);
 876                        count += LOAD_FREQ;
 877                } while (count < 0);
 878        }
 879} 

如何判断系统是否已经 Over Load ?

对一般的系统来说，根据 CPU 数量去判断，如上面的例子， 如果平均负载始终在 1.2 以下，而你是 2 颗 CPU 的机器。那么基本不会出现 CPU 不够用的情况。也就是 Load 平均要小于 CPU 的数量。

这是 Solaris 性能与工具(Solaris Performance Tools ) 一书推荐的评估方法。【在这里要推荐一下这本书，尽管在 Load 这个地方没有达到我期望的那么细致。但全书揭示了非常多的性能信息。每个 DBA、架构师 的必须书。】

这么说实际上带来另外两个疑问：

1 如果是多核 CPU / 超线程的机器怎么判断? 对这样的机器，我的建议是看操作系统怎么识别的 CPU，根据系统识别出来的逻辑 CPU 数量来判断。如果要考虑性能系数，建议参考一下 Oracle 针对不同架构下多核 CPU 的收费标准。

2 如果应用是面向线程的怎么判断? 这实际上和 M:N 线程模型有关。你的系统是怎样的? 把这个问题考虑进去即可了。

多数情况下，Load 过高都未必和 CPU 有关。或许倒是有一个例外的，就是应用场景的问题。比如用单 CPU 的机器去做高并发 Web 服务器，麻烦就来了

Load 与容量规划(Capacity Planning)

任何一个相对成熟的站点都会利用 Cacti（基于RRDTool） 等工具进行容量规划工作。抓取的 Load 会传 1、5、15 分钟列值过去，这三个度量采用哪个呢? 15 分钟为首选【参见Gunther 的 PPT】。

Load 与系统预警

很多对可用性要求比较高的环境都建立了 邮件或SMS 报警机制。关于 Load 报警阈值的制定也有看到不太合理的时候。这里建议 Critical 值(如果用 Nagios 之类的工具你明白这是什么)上限为 物理 CPU 的个数(当然你可以设置比这个低)。但比这个值高的话，意义就不大了。比如，数据库服务器有 4 颗 CPU，那么 Load 高于 4 就应该报警出来，设置比 4 高可能意义不大，因为接到报警还有个人为响应时间...

误解 一：系统 Load 高一定是性能有问题。

误解 二：系统 Load 高一定是 CPU 能力问题或数量不够。

真相：Load 高只是代表需要运行的队列累积过多了。但队列中的任务实际可能是耗 CPU的，也可能是耗 I/O 乃至其它因素的。

误解 三：系统长期 Load 高，首选增加 CPU。

真相：Load 只是表象，不是实质。增加 CPU 个别时候会临时看到系统 Load 下降，但治标不治本。

小小一个 Load 讲究其实不少。英文信息其实比较全的，尽量保证加入一点新信息到这篇文章里。入看到有写的不合理的地方或者有异议，请指正或告知。

--EOF--

FAQ 1：数据库服务器突然 CPU 100% 繁忙，咋办?

A ：一般情况下，这是由糟糕的 SQL 引起。建议抓取 Slow Query Log ，针对 I/O 开销比较大(重点看全表扫描）的 SQL 进行优化。根据经验值，每个 CPU Core 一秒钟能处理 100-400MB 数据量。如果是大量的并发 I/O 操作，尽管存储的吞吐可能还没那么大，也可能会把 CPU "塞满"。

前微软头号 Blogger Robert Scoble 采访 Twitter 的几个家伙。谈及 Twitter 的一些比较严重的问题。

谁来拯救大兵 Twitter ? 前几天看到新闻说他们请了 Pivotal 实验室来解决当前存在的问题。从这几天观察来看，好像并没有什么明显进展。也或许并非一时半刻就能完成吧。今年用的最多的 Web 2.0 服务就是 Twitter 了，没有了这东西还真的有些不习惯。

Twitter 的初期设计对消息采用了 Single Instance Storage (SIS)，这直接导致了消息持久化产生了数据库单点问题(?) . 每一种设计思路应该都有其理由。旁观者清也只是没介入到那个环境吧。接下来 Twitter 会做什么? Sharding ?

这个视频更像是 Twitter 不服气外界质疑而进行的宣传。其实 Twitter 的一些扩展性问题对 Web 2.0 站点来说是个绝佳的案例，有正面的成长参考，也有为错误买单的痛苦。或许这才是主要吸引我们关注它的地方。

--EOF--

偶然发现三年前的一个技术问题。当时比较匆忙，避免掉即过去了。现在 Metalink 上其实已经把这个问题作为一个 Bug 处理了。

问题描述：通过 JDBC 上来的 Java 查询应用，SQL 表现异常。表字段使用了 DATE 类型，针对该字段时间区域很小的范围查询(预期应该是走 INDEX RANGE SCAN)，在 SQL Map 上指定索引，发现无效。仍然是 FULL TABLE SCAN (FTS)。

罪魁祸首：setTimestamp() 把值绑定为 TIMESTAMP 类型，这样和 DATE 类型比较的时候，CBO 就会选择全表扫描。

通过 Trace 能观察到该异常行为。TIMESTAMP 在 Oracle 的 JDBC 9.2.0.1 上就有了，连续几个版本其实都有类似的问题。

解决办法：使用 setString() 而不是 setTimestamp() 方法。

这个故事告诉我们，Oracle 的 JDBC 驱动程序其实问题挺多的。同样，TIMESTAMP 潜在的问题也不少，尽管这个数据类型已经出现多时。

--EOF--

书接上文。视频请访问 InfoQ。

InfoQ中文站: 在 Web 2.0的时代，海量数据对于越来越多的开发者来说，已经不再是一个遥不可及的话题了，可能随便哪一个访问量很大的Web2.0网站都有可能拥有令人咂舌的数据量，那么对于这种网站，除了对数据库存储进行优化，除了缓存，然后还有那些策略？

Fenng: 我觉得可能主要是在存储方面会有一些大的挑战。比如存储的可靠性，像以前就有过 BSP服务商对客户的数据居然没有备份，导致了很多用户损失了一段时间之内的数据，这样总体来说对网站的声誉有很大影响、对用户的体验也很糟糕。

随着互联网的飞速发展，数据总体来说是趋于膨胀性的，在这个过程中，如何把数据有效的存储，并且有效的获取，便是个比较复杂的问题。我们前面说了太多 Web 2.0相关的话题，【换个角度】比如说我所在的公司支付宝，也面临着这样的大数据量、海量数据的挑战。当前我们的一个策略，也是沿袭 SOA 的战略化思想，就是数据库相关的数据服务进行一定的 SOA 化处理。另外一个比较重要的策略就是数据生命周期的管理，我们对这样的，在数据生命周期已经完成后，会对相关的数据做一些归档化的处理，再进行二级存储或者分级存储。那么话说回来，对一些 Web 2.0 网站，我觉得也可以运用这样的思想机制: 对用户已经不大可能访问或者访问频率比较低的（数据），采用分级存储，或者额外做一些访问策略的制订，是很有必要的。

InfoQ中文站: 我们也听说过另外一种分片数据库机制，那么请你谈谈分片这种策略是怎么样一种策略？

Fenng: 分片总的来说，它不是一种比较新的技术， MySQL 在 5 .x 版本之后，有了分区功能。那么在这之前，MySQL 是没有分区功能的。当时如果需要处理一些比较大的数据量，比方说要对根据时间对数据进行历史化处理，就会比较麻烦。人们可能是因地制宜，就产生 Sharding 这样技术策略。

严格来说，数据分片其实在我们以前也有一些相关的实践，在其他(类型)的数据库上，我们也会有一些历史策略，只是当时这个名词没有完全定义下来。据我所知，这个词是从大型在线游戏中发展出来的。大部分用户会集中在某个区域。这一部分集中在某个区域的用户，会把他们放在特定的服务器上。不同区域之间的用户之间的关联度可能不大，这个场景和我们现在的数据库分片策略其实是非常非常相似的，我们当前如果对数据库做一些分片，也会采用这样的基本思想，比如说根据不同的用户 ID 范围，或者说不同的地区(来分片)。

如果建的是商务网站，可能根据产品的类型来做，我们会把不同产品类型的数据扔到不同的 DB上，这些 DB 之间的关联度是很小的。然后我们在 DB 之间，可能会有一个封装层，在这个封装层之上，对应用程序用户来说，就像是透明的，那么就达到了我们数据库上高度扩展化的目标。

InfoQ中文站: 那分片这种策略有什么利弊吗？

Fenng: 首先，分片的好处还是很容易看到的。起码我们的 DB 能达到不依赖于某个单点，而这样能做到平滑的扩展，就像大家常说的 Scale Out (横向扩展)机制。它的弊端也是比较明显，对于事务高速处理这样的网站，它有它的自己的不足之处，事实上好多朋友也应该知道，一个事务如果跨数据库，这样对设计者，对编码人员来说，还是比较棘手的。那么如果一个事务如果跨两个甚至多个 DB，Sharding 复杂度就会很高。Sharding 在业界的应用场景基本上也就是这种读应用比较重的情况，而且对事务的安全性要求不高，这样的场景会非常适合。

【上个月写了篇 Sharding 的东西给《程序员》，还不知道什么时候发表出来】

InfoQ中文站: 目前在许多网站的架构设计中有绝大多数的项目在持久化方面就是采用数据关系映射（ORM）的方式。大家对于这种高负载的大规模网站应用来说，你觉得存在哪些应用呢？

Fenng: 首先一点，我想拿我们支付宝来说，ORM 大家觉得用得非常好。在一个相对比较大的开发环境，对开发团队来说，它的弊端可能就不大容易看出来。因为我们用的是 ORM，就很容易把中间 DB 这层完全隔离出来。然后把这一层的 SQL 处理交给专门的 DB 人员----我们这边还有专门的开发DBA，由他们来专门对这层进行集中的监控管理，乃至一些规划类的工作。这样开发工程师还有架构师这边，他们可以集中精力在其他方面做更多的投入，一个比较大的团队中我觉得像 ORM 这些还是很容易能看到好处的。

【ORM 还有个比较好的地方在于安全性，能有效减少 SQL 注入的隐患】

在另一方面，我们看一下它的弊端，因为像一些 Web 中小网站，可能相对人手也比较少，大家 用的(开发)工具(或框架)呢，可能像 PHP、 ROR 这些东西，也就是在开发上，上手又比较容易的。那么这个时候，事实上一个潜在的问题是，当代码规模到一定程度，如果没有去做一些 ORM，那么可能会给网站带来一些潜在的比如说代码管理上的问题，这一点只是我的个人看法，实际上大家在具体的应用场景可能会有各自头疼的问题，我在这方面不是专家，也仅供大家参考。

InfoQ中文站: 那你所做的支付宝，其实是企业级别的应用，在企业级别应用所采用的这种架构策略和一般 Web 2.0 网站所采用的这种架构策略会有什么异同？

Fenng: 事实上，很明显的一点，支付宝其实业务是非常复杂的【也有一部分人误解支付宝业务很简单】，这和我们很多的Web2.0公司不大一样，Web2.0它可能从一个点切入进去。在这一点上，我觉得做得比较透。支付宝呢，它可能有点像我们以前做的一些通用软件，他要考虑不同的行业、不同的用户、还有像买卖之间，与这么多银行之间的关系等等，这个复杂度还是很大的。

这实际上就从一定程度上决定了我们和 Web 2.0 公司截然不同的应用解决方案，像当前我们在支付宝，在一年之前，甚至两年之前就已经考虑，把我们的整个网站 SOA 化、组件化。在这个过程中，也考虑了一些像 Web 2.0 中的技术元素，但总体的思路呢，还是说向SOA 化，向面向服务这方面大步的跨进，然后就从 SOA 这一点，事实上很多 Web 2.0 公司，他们未必能完全的实现，完全的做到这样的面向服务化，我觉得这可能是两者截然不同的一个表面特点。

另外，像支付宝也在尝试做一些，对外部客户、服务提供一些接口，甚至完全开放的一个平台，这一点又和我们当前这些像 FaceBook ，或者是说，像美国的 MySpace 这样的社交区、SNS 网络了有一些共通之处。

InfoQ中文站: 那目前在 Web 2.0 网站这个领域里面，网站的架构主要有哪些趋势，下边还将有怎么样一个走向呢？

Fenng: 其实作为一个技术人员，每当要谈到趋势，肯定要给大家笑。从中长期来看，国内的一些 Web 2.0 新服务逐渐涌现出来了，随着发展，我相信会有更多的商业化元素加进来。像以前是好多 Web 2.0 公司是完全使用开源的技术，伴随规模扩大化，一些以前提供开源技术的组织或个人他们会尝试进行一些商业化的运作。商业化并不是个坏事情，一方面给我们提供更好的服务。另一方面，他们得到了足够的商业支持，反过来之后他们又会对整体的开源开发环境、发展环境起到很好的促进。我相信在未来的两到三年之内，会有一部分的商业公司涌到 Web 2.0 的发展生态圈里面。

然后从技术方面来讲，像前面几个月 MySQL 被 Sun 收购，起码是在 Web 2.0 这样的软件链条中的一个重要环节(MySQL),有些人可能会感觉出了一些问题。但现在像在数据库这一层呢，也不排除像 PostgresSQL 这些其它的数据库，趁这个机会被商业公司所拥抱，他们也会做出一些更大规模的应用场景出来。在数据库这方面可能会限制大家，几家开源数据库形成一个僵局，Sun 在......这个有些扯远了，还是绕回来。像现在很多的 Web 2.0 公司，他们对 Web 服务器这方面也会采用一些比较新的，像 Nginx， 我觉得在起码在接下来的一段时间内会吸引绝大多数公司长期、大规模的去使用它、去拥抱它，甚至为它开发一些更激动人心的新特性。

【这段时间比较热炒的开放平台、云计算也或许能给我们带来一些思路：很多有技术积累的的公司都有自己打造一套底层的架构的意图，比如针对存储层面向应用的虚拟化等。】

InfoQ中文站: 那最后作为一个由 DBA (Administrator) 成长为DB Architect，同样都是A，但这个A已经有一个变化，那么你对后来者有哪些建议呢？

Fenng: 建议谈不上，跟大家谈谈自己在这个过程中的一些转变。首先从DBA(的角度说)，因为 DBA 做一些实际相关的维护工作，从这个过程转到架构师这边，是相对从这比较"实"的岗位转换到现在看起来相对好像稍稍"虚"了一些，但是在这个"虚"的过程中，又相当于我们且退一步，然后就能看得更远一些，能看到整个软件架构的网站发展，甚至是公司战略上的一些事情，这对个人成长是有好处的，我希望大家如果有这个意愿也可以稍微尝试一下，因为 DBA 只是我们整个软件开发行业中的一个环节，那么在这个环节前面和后面，其实都有很多可以做的事情。

其实每个人都不是不可替代的，那我们是否可以尝试一下是否能够去替代别人呢？谢谢大家。

--EOF--

在 InfoQ 对我的采访发布后，我看到已经有网站在转载文字稿。其实口头的东西转换到文字，自己的话难免有些辞不达意的地方，征求 InfoQ 泰稳的意见后，我在这里就部分问答作一下修正，以免误导。

以下是正文:

InfoQ中文站: 作为一名资深的 DBA，大辉却在自己的 BLOG 上边写了不少关于网站架构这方面的一些文章，能不能谈谈 DBA 跟网站架构这方面的关系呢?

Fenng: 好多朋友和我开玩笑，说我做一个DBA，却总去写一些架构相关的东西，"是不是这个厨子不看菜谱，看兵法了？" 其实这二者之间我觉得是有些关系的。像数据库的维护，甚至设计、架构相关的工作，做到一定程度上还是要向前再走几步：也就是说要把我们架构相关的一些事情融合进来。当然作为一个 DBA 没必要一定要像我们的相关架构师这样，去做一些编码之类的实际工作，不过一些和 DB 结合的比较紧密的东西是一定要关注一下的，这也是我在 BLOG 上写了不少与架构相关文章的一个主要原因。

InfoQ中文站: 一般来说要提升网站的性能，瓶颈主要都有哪些，如果要解决这些瓶颈，又都存在哪些最佳实践呢?

Fenng: 在以前，可能瓶颈多数会在数据库上，也即最后瓶颈会落在 IO 上面。但是现在随着一些 Web2.0 发展而涌现出相关的技术解决方案，当前一个网站真正能否应付大流量、高并发，主要的问题还在于 Cache 能够充分、灵活、正确使用上，这点十分重要。【补充，因为这个整个话题基本是面向 Web 2.0 方面的，所以这里说 Cache 会是主要问题，如你所知，电子商务站点的话，事务处理能力无疑是比较棘手的事情】

InfoQ中文站: 一个要经受住大规模、高并发、访问量考验的成功 Web2.0 网站在设计的架构中要注意哪些东西呢?

Fenng: 这个在前期的规划中肯定是需要做一些预防性的措施，比如说选择适合的技术架构。这是第一步应该必须要考虑的事情。另外还有在产品设计上也会有很多需要注意的地方，现在我们的很多 Web 2.0 网站，包括国内的这些新兴的一些 Web 2.0 网站，多多少少存在一些过度设计的现象。这些设计不经意之间可能会对后台带来灾难性的影响，这就会对开发人员、架构师，甚至维护人员都带来很大的压力。

另一方面呢，参考当前业界上一些已经相对比较成熟的技术 DIY 搭建架构还是很关键的。我们做一个网站就好比造汽车一样，不一定非要造得像奔驰这样顶级豪华的(那成本会非常高)，我们只需造一辆能跑起来，跑得很好的汽车，这可能就已经达到成功的一半了。

InfoQ中文站: 那刚才在网站性能和调优这方面，你刚才也提到了，缓存的作用是非常重要的，那么它到底处于怎么样一个重要的地位呢？如何对缓存进行优化从而提升性能?

Fenng: 就我以前的相关经验，基于 Oracle 环境的一些实践，一方面是在应用程序高并发的设计上有一些必须注意的事项，另外一个就是能否充分利用 Oracle 自己的内存，最后实质上看其是能否充分利用自己的 Cache 机制。对于 Web 2.0 网站，可能很少有使用 Oracle 数据库(多是 MySQL)，但在MySQL上，一方面 MySQL 有自己的 Cache 机制，应该说还做得不错，再一个，绝大多数网站都会考虑使用像 Memcached 这样的外部组件进来，然后在这个地方，其实我们最后考量的是命中率，衡量命中率的高低，这是大家必须要注意的扩展性、性能指标。

命中丢失的 I/O 实际上最后压到我们的数据库上，到数据库的 I/O 命中再丢失有可能会压到最下面的磁盘上，这样磁盘【或存储】一定要能支撑住我们当前的最低需求。举个最简单的例子，我们的应用 Memcached，可能前面的 I/O 命中率是 80%，那么有剩下的 20% 会压到后面的 DB 上，这个 DB 的命中率有可能达到95%，剩下的5%，乘以前面那个 20%，总体 I/O 量 x 20% x 5%，这个 I/O 量会打到最后端的硬盘【或存储】上。而硬盘【乃至存储】的整体响应能力又是有限的...我们或许是做 RAID，也甚至可能出现单块硬盘支撑应用这样的情况。从这个基础往前推，就能计算出我们当前的系统能承载 Cache 的瓶颈，进一步知道整体 I/O 的处理能力。在设计的时候，一定要考虑到这样的情况，否则当压力突然增加到我们不能承受的时候，临时做一些扩展的手段，可能就会比较麻烦。

InfoQ中文站: 你刚才说到Cache命中率，那对于一个比较成功的这种网站，它Cache命中率一般会在多少呢?

拿 Oracle 来说，它本身的命中率做到 90% 甚至是 99.99 这样的情况，在MySQL的环境下可能做不到这样， Memcached 据我所知，可能70%～80%已经不错了【不同的应用表现差异很大，比如豆瓣的朋友告诉我他们命中率是 97% ! 】。当然命中率只是一个表面的现象，我们还要看实际真正的应用程序到底是怎样，可能不同的 Web 应用类型所能承载的访问频率也不大一样，所以并没有固定的比例，这里只能是凭一些经验。总体来说肯定是命中率越高，会越好一些。

第一部分先到这里。明天有时间修正剩下的部分。

上个礼拜三下班后和同事东哥闲聊，说起各自走的技术路线，回忆了不少以前学习路上走的弯路。今天想起来，越发觉得有意思。

最近好几个同事都对 Python 感兴趣，由这个开聊。我开玩笑说，当初我还搞过几天 Python 呢，如果坚持到现在...嘿，可能都饿死了。几年前，Python 新手估计真的养活不了自己。这倒幸亏自己没有坚持下去。其实还在学校那会儿，自己也不知道学什么好，好比没头苍蝇乱窜，东一耙子，西一扫帚，现在看来，这倒是个好事情，起码自己知道了那些东西不适合自己。

要说那会儿学习热情可真是高啊，节衣缩食买了好多图书回来，可真正啃完的其实没几本。我经常自欺的说，每本书学到一个知识点，如果累计起来也不少了。谁让咱是非科班的呢。每次搬家，那些舍不得扔掉的书都是一层灰...

如果怨天尤人一点的话，最坑人的是谭浩强的那两本 BASIC 和 C 的教材，绝对是坑了一大群学生，尤其是 C 语言那本书，把好好的 C 变成了数学算法实现工具，说起来不怕丢人，对于 C 我现在还是门外汉。倒是东哥说的这句话让我感觉很是欣慰，"并不是某个语言太难了，很可能这个语言不适合你" -- 当年可能大家都干过类似的事儿。还记得当年学校的一景: 一个菜鸟掤着本厚厚的 Delphi ，对着书上的例子在计算机前狂敲代码(上机时间有限嘛)。可是，那些人到哪里去啦?

最近有两三位朋友给我发邮件来，要我说说怎么能做个 DBA。我想每个人的经验可能都是不可复制的，正如一路走来，沿途的风景也不尽相同。刚开始工作的时候，很难确定什么是自己真正感兴趣的，作数据库管理也是这样，没有把你扔到实际的环境中，你不会知道自己是否喜欢这份工作的。如果要我说点经验，那可能最主要的一句是"隔河观景的心态应该尽量避免"。

--EOF--

整理一下 Windows Vista 下使用支付宝控件、证书的常见问题。

问题：错误提示 "Cenroll 为空或不是对象，错误代码 800A138F"

场景：安装支付宝数字证书时出现。

解决办法：
1) 确保 Windows Vista 服务 Protected Storage 是启动的。开始->控制面板(经典视图) -> 服务--Protected Storage
2) 确保 https://www.alipay.com 在 IE 的信任站点中。
3) 下载微软 Cenroll 控件。

另一个同事告诉我，降低 IE 安全级别也可能解决问题。但这毕竟也会带进来新的隐患。

问题：浏览器页面自动关闭

场景：Vista 操作系统，IE7 浏览器，在登陆支付宝的时候出现页面自动关闭。

解决办法：开始->控制面板(经典视图) -> 用户账户 -> 打开或关闭"用户账户控制" -> "使用用户帐户控制(UAC)帮助保护您的计算机" ，点击把"对号" 去掉，确定。

按提示重启电脑。严格来说，这不是个很彻底的解决方案，但是目前 Vista 的 UAC 机制并不是很灵活。我们可以针对 IE 设置下面提到的 "Configure an application to always run elevated" 模式，这样安全性稍微好点。

• 延伸阅读 1) Configure an application to always run elevated
• 延伸阅读 2) Windows Vista Secret #4: Disabling UAC

附注：UAC 关闭是否安全? 见仁见智的问题。UAC 是个好东西，但是过份作为就变成了对用户的干扰。另外，说一下这个 Vista 上的一个很关键的特性，熟悉 Ubuntu 的朋友会发现这和 Ubuntu 的设计哲学(或者 Unix 的 sudo 机制)有些神似.

友情提示

BTW: 针对这个贴只算整理者，将持续更新。尽管转载。有相关问题可以在这个帖子下面提问，也便于我整理出更多的问题。

--EOF--

或许没几个人能说明白到底什么算是云计算(Cloud Computing)，但这并不妨碍大家讨论他的热情，并且热心的与之套近乎，恨不得分身两处，自己给自己隔着虚空贴上云计算的标签。

云计算，离不开规模吧? 每家公司都把自己网站弄得和信息孤岛差不多，突然就喊着云计算? 要用户怎么相信呢? Amazon 早在抛出云计算概念之前多少年，就已经提供 Web Service，这个预热过程几乎是不可避免的。对比国内，还是要补一点课的吧。

云计算，离不开核心基础架构吧? Google 有 Bigtable + MapReduce ，Amazon 有 Dynamo ，国内有那家公司弄个自己的架构并形成论文给业界看看呢? 简单的弄个名字出来怕是也没什么意义的。

另一个类似的例子是 Facebook 的开放带来的业界跟风，现在甚至天涯社区开始东施效颦...看看天涯那烂页面结构吧，谁好意思吧内容引到自己的站点上呢?

以前都说中美互联网差距有点距离，但单从嘴皮子上看，其实没什么距离--几乎是同步的的嘛。人人都言必称云计算的时候，不妨给这东西泼点冷水。该喝豆浆喝豆浆，该吃油条吃油条。满汉全席大可作为文化给大家熏陶一下就成了。

--EOF--

可能是因为 Discuz! 庞大的用户群的原因吧，发现有些中小网站也有在 Discuz! 基础上做二次开发的，巧的是，到了某个阶段，不约而同的遇到类似的问题：开发进度明显滞后。

个人觉得 Discuz! 设计的初衷是面向中小站长的，对于二次开发可能并不是很重视。去官方论坛看了半天，甚至都没有专门二次开发的板块。莫非大家的二次开发都是各自为政，摸着黑搞的么?(好像的确是这样，代码开源，对着修改就成) 一些简单的门户开发估计问题都不大的，如果业务复杂一些，并且流量相对较大，可能隐忧就会比较明显了。

有次因为要验证一点东西，看了一点 Discuz! 的代码，发现一些基本的模块性能上并非很好(我自己并不很懂 PHP，只是出于性能考虑罢了)，类似的页面在一定规模下并不会对性能有太大影响，可一旦突破某个量级，影响就非常明显了。有的网友可能会说，别装了，你不知道 Discuz! 功能有多强大吧? 问题可能恰恰就在于功能强大这儿了，一个软件如果自身已经在一些细节上考虑的足够细致，那么无疑也会给二次开发带来不必要的开销。就这一点上说，或许 Discuz! 有必要开发一个面向二次开发的版本，削减一些锦上添花的小功能。

另外，UCenter 这个 SNS 产品我觉得也不会有太大作为，千站一面的 SNS ，除了让大家消磨一些无谓的时间，会带来什么创新呢?

这只是我心血来潮，对产品设计的一点思考罢了，可别真的绕到 Discuz! 到底有哪些优点上去...

--EOF--

更新，有朋友和我说

Discuz! 代码里面本身包含监控隐私的东西，如果你的网站达到一定数量的用户，程序会触发通知 Discuz! 公司。

附加阅读:

• 百万记录级MySQL数据库及Discuz!论坛优化
-- Fenng 注：严格来说，百万记录级别并不是很大。但是一些思路非常值得新手借鉴。

微软 IIS 上如何启用 Gzip 压缩机制? 或许看过 YSlow 优化规则并且正在使用 IIS 的朋友比较关心这个问题。

基本步骤可以参考微软官方指导，直接一点的方式通过命令行执行如下命令启用对动态/静态内容的压缩输出:

appcmd set config /section:urlCompression /doDynamicCompression:True
appcmd set config /section:urlCompression /doStaticCompression:True

添加一个新的 Web Service Extension (如果原来没有的话) ，输入 gzip.dll 的全路径 。

IIS 6.0 上压缩额外的文件扩展名

修改 MetaBase.xml 文件中 HcFileExtensions 添加额外的文件扩展名。

IIS 7.0 上压缩额外的文件扩展名

修改 ApplicationHost.config 文件，添加合适的 mimeType 并指定激活. 打开文件参考原有的行照葫芦画瓢就成。可能要设置多次才会成功，因为 mimeType 定义可能有些歧义。

记录一下，备忘。

--EOF--

前段时间 阿里巴巴网络侠客行大会上，我提到 InfoQ 对我做了个视频采访，现在这个采访已经可以访问了。

• 视频页面：与冯大辉谈数据库架构 (另：新闻页面)

这是个人第一个成功发布的视频访谈。去年 Oracle Open World 的时候, IT168 非要作采访，结果牺牲了两个会议时间，折腾完后再也没看到关于那个视频的消息。

说实话，采访之前自己还是比较担心效果的。这次 InfoQ 的采访效果比我的预期要好多了，因为现场发挥的地方比较多，有口不择言的时候，还望读者朋友海涵。

赞一下 Infoq 的几位朋友(泰稳、Jason、X5)! 和他们合作很愉快。我身边的很多同事都认为 Infoq(中文站) 是国内最好的技术信息站点。接下来，还有对我另外一位同事的采访(比我更为重量级)即将发布，我在采访现场听了都很过瘾。敬请期待，绝对不忽悠 :)

--EOF--

耐着性子看完了这部《没有青春的青春》(Youth Without Youth) 。因为是大导演弗朗西斯·福特·科波拉的十年回归之作，所以坚持看完 :) 个人的理解是导演把语言当作时间的参照系来表现，具体要表达什么说也说不清楚，或许这才是导演目的。

电影的氛围和博尔赫斯的小说有异曲同工之妙(庄生梦蝶的这个典故在里面也被用了多次，好像西方文学家中博尔赫斯最喜欢这个梦蝶的故事了...)，看到结尾字幕才知道这是改编米尔恰·伊利亚德(Mircea Eliade) 的小说。导演应该也是博尔赫斯小说的拥趸吧?

又看到 Tim Roth 的表演了，怪才。什么时候找到 Rob Roy 看看。另外，风软的字幕把导演的名字都打错了。

--EOF--

《庄子.蝶梦》: "昔者庄周梦为蝴蝶, 栩栩然蝴蝶也, 自喻适志与, 不知周也。俄然觉,则戚戚然周也。不知周之梦为蝴蝶与, 蝴蝶之梦为周与? 周与蝴蝶则必有分矣。此之谓物化。"

点击流(用户访问路径分析) 似乎是互联网站必须要做的一件事情（我是 UE 门外汉）。如何从千差万别的用户访问行为发现共性，是个很有趣的可研究的东西。不知道这个地方是属于 BI 的活儿还是属于 UE 的（我是门外汉，只是对这个话题好奇罢了）。

类似的话题其实以前车东写过，几年过去了，用于进行 ClickStream 分析的开源工具真的不是很多(这或许也反应了业界对其需求吧)。常见的有 StatViz 、Pathalizer ，还有 Visitors 。

辅助工具有 ZGRViewer 、Graphviz等。

php statviz.php --config dbanotes.conf 
dot -Gsize="4096" -Tpdf -o mysite_clickstream.pdf "pairs.dot" 

第二行即为 Graphviz 在 Unix 下的基本使用。Ubuntu 系统上可以直接用 apt-get 安装 Graphviz 。

对于 StatViz 的聚合分析模式，觉得对站点分析价值不大。倒是 Individual Session Tracks (现在很多公司可能都自己开发类似的模块了)这个功能值得搞一下，可惜很多人都是集中于前者。对于中大型的站点，可以选择少数服务器激活 mod_usertrack ，收集有代表性的数据进行下一步分析。

Clickstream 这玩意儿是不是必须的? 前一段时间看云风的回忆，对"引擎加入录象" 这个细节印象很深刻。一个很复杂的系统如果缺乏缺陷捕捉能力，那么无疑不是很完美的系统。对于复杂得如迷宫一样的互联网站点，其实也是这样，你知道你的用户怎么访问自己的站点么?

--EOF--

根据 Session ID 跟踪输出的一份样例图:

度过那一天度过那一天 / 默默的伤感的过度那一天
超越那一天超越那一天 / 轻松的简单的超越那一天
--崔健《超越那一天》

早晨 8 点，还在睡梦中，蚊子把我吵醒，昨天夜里等了好半天也没猎到它，够聪明；

上午10 点，在公司开会。讨论着一件有限的预期内都不可能做的事情，可是眼前的紧急事情都假装视而不见；

中午12 点，和同事边吃午饭边技术畅想。天热；

下午14 点，接到某猎头公司电话；回头猜了半天是怎么知道我座机的；

下午16 点，尝试 Web 日志虚拟化展现。另得知计划已久好久的一个内部活动要被取消，表现我的说服力，未果；

下午18 点，匆忙晚饭后参加健康讲座，讲师满嘴伪科学，结束之前溜出；

晚上 20 点，写 Blog，都说这一天必需要点什么，嗯，超越这一天。然后，回家打蚊子去...

--EOF--

偶然看到 Tanel Poder 提到的一个 Metalink Note (438452.1): Performance Tools Quick Reference Guide 。这文档倒的确挺新，其中有几个工具值得关注一下。

LTOM：The Lite Onboard Monitor

Java 程序，定位是"实时诊断平台"。具有自动 Session 跟踪特性。另外具备自动 Hang 检测，自动数据收集等功能。该工具应该对于 Oracle 技能不太强的中小用户有比较大的帮助。但对于比较关键的系统，恐怕都不太放心跑一个 Java 程序在数据库上。

OPDG：Oracle Performance Diagnostic Guide

类似决策树的一个工具，访问的时候要打开个 Java 虚拟机，以我这样的网速根本访问不到(到了 22% 就停掉了) 。不知道等着着用这个工具的用户会急成什么样。

TRCANLZR：Trace Analyzer

格式化原始的 SQL Trace 数据，以 HTML 形式展现给用户。

HANGFG ：Hang file generator

用以收集系统 Hang 住时的状态信息。看来，Oracle 出问题比较多的时候还是系统 Hang 啊 :)

除了这几个，还有 STACKX ，用以分析 Core 文件的内容；还有以前大家都知道的 OS Watcher ，现在也做了一些改进。这个软件包基本上是 Unix 的那些传统的性能工具加上比较有好的图表展现脚本。

应该说随着 Oracle 开发、开放更多的性能相关的工具出来，对于有一定经验的 DBA 来说，会有个很好的辅助作用。对于经验不够丰富的用户来说，不是缺少工具，而是即使有性能数据，也不知道如何分析，如何定位。

--EOF--

偶然发现，Metalink 对于文档的关键字也是用 Hint 的方式, 哈

尽管最近又拿到了一笔风险投资，但 Twitter 似乎遇到了中年问题，前几天居然因为一台 DB Crash(原因是居然是连接数过多!） 而导致禁止了很多关键功能。接连几天，服务都是及其不稳定。或许是 DB 崩溃问题带来的雪球效应吧。因为这一系列问题的困扰，用户怨声载道，Twitter 倒是做了"改进": 开辟了一个子站点用于即时报告各项服务的状态问题。值得称道的是，Twitter 开发 Blog 上回答用户的技术询问倒是很端正的态度。

现在技术问题成了 Twitter 进一步发展的极其严重的制约了，在所有的 Web 2.0 站点里这倒是比较少见的。尽管 Twitter 过去号称把性能提升了 100 多倍，看来还不够哇。 前一段时间，有小道消息说 Twitter 准备放弃 RoR ，倒是 Twitter 忙不迭的辟谣。

面对很恼火的用户，Twitter 也承认架构上的一些问题，"Twitter is, fundamentally, a messaging system. Twitter was not architected as a messaging system" ，而最初的架构也是面向内容管理系统而不是消息系统的，这需要一个转变过程。一直让我比较奇怪的是 Twitter 似乎没有专门的 DBA ，而是开发工程师兼任，如果 MySQL 不是瓶颈倒没问题的(有很多 Web 2.0 大站就不用专门 DBA 的)，可如果 DB 是瓶颈，那就比较麻烦了。DB 如此，其它环节也是如此。

有意思的是，随着互联网应用的飞速发展，Performance Engineer / Scaling Engineer 这样的新职位需求都出来了。这是个有挑战的活儿，值得尝试一下。

实在无聊，这只是一篇随笔罢了。

--EOF--

延伸阅读：Twitter 在自救