Monthly Archives: June 2008

Web Clickstream 分析

点击流(用户访问路径分析) 似乎是互联网站必须要做的一件事情（我是 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–

这么多的 Oracle 性能工具

偶然看到 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 的性能问题

尽管最近又拿到了一笔风险投资，但 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–