Archive for 技术杂谈

gappproxy2-1_0_0.zip
sha1: 4b0cb0d6340ef03584c49bed189e487e2f5e56c5

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAABAgAGBQJMgyAIAAoJEED6UmVskhksvTMIAK2cySLja/IUmiZ2JeebcGOb
XJvuqI1dDRQZqxrS33TqOMublbUSsPpnFGjpH8UNzljgI1/J37gPb2ENYw7q+lC0
Nu8e1tr73zdaIgyqXrv77UHAKNOhs8GTIcxJtJfYCcm9QQNQ8o5F/qqxVQLY0OmR
in8pM2KHi+rMhBBQKMWoakHfqZJovbR1XawLKNeSiJn6P8w2VlbhpDAbVDwkBHm9
ep19gjwNpACjBKRvZZ7q92HgSz3EiFQgZFwOjTIjS9MH5r79h1+fMao34PplkW4a
OAbY8iUlucjOqAUPhMGqvpSd9JQ7fo8mc8o1witNEJQFiu38jZXGxzfm7qeoNS4=
=PaDT
-----END PGP SIGNATURE-----
(公钥问题请见 关于页面)

实际上该说的话已经放到 README 里去了.

—

注意:
请使用 Google App Engine Python SDK 更新. 如不使用的话可能需要去掉 derived_file_type: – python_precompiled 两行.
部署后请设置 Administration – Versions 选择 secureable. 如不选择的话请注意修改 fetch server 地址.
请留意服务器证书问题. 使用 wget https://xxx.appspot.com 时不应有证书错误的提示. 可用的 IP 请自行查找.
请尽量不使用 GAppProxy2 登录访问 Google 相关服务, 特别是 HTTPS 方式. 如果有相关需求的可以试试 IPv6 方法.

安全相关问题:
不附带 SSL 证书, 不推荐通过 GAppProxy2 访问 HTTPS 网站. 证书可以用上面的命令自行生成. 使用证书并不保证 SSL 安全性. 内容传输加密依赖 SSL 层完成, 请注意证书的验证.

Changelog:
2010-08-29 1.0.0, 稳定版
基本重写, 代码更精简.
服务器端带宽利用率更高, 不再有无用的 urlfetch 请求. 增加了 x-range 以处理自适应 block size 的问题. 增加 CACHE_NAMESPACE 项, 适合与其它程序同时部署.
客户端把断点续传与主处理合并, 不再单独处理. 日志中增加 size 和 referer 项, 方便本地分析(但没有也不会做保存的功能).
本版起 Fetch_Max 可以改为 1 而不损失任何功能(断点续传适应能力可能会下降). 默认仍为 2 以平衡功能与 urlfetch 调用次数.

先从系统设置开始.

KeyRemap4Macbook, 调整重复按键速率. 把右 option 映射为 Fn.
键盘设置: Use all F1 … as standard function keys
去掉 Spotlight 快捷键(偶不用). 切换输入法快捷键设置为 control + space.
输入法是 SunPinyin, 但不是非常满意, 主要是词组少.

触摸板: Tap to click & Secondary Click (Right). 其它基本就全选了.
Three Fingers: Dragging (好像不是非常顺手, 先这样凑合着吧)

Terminal.app:
Preferences – Settings – Keyboard
Home – Action: (to send string to shell) – Press Ctrl+A (or \001)
End – Action: (to send string to shell) – Press Ctrl+E (or \005)

Dock: 桌面右侧. 缩小.
Sharing – Remote Login
Menumeters – 选了硬盘灯和网络箭头
NTFS-3G & MacFuse 无需设置. 缓存在安装的时候自己选好了.
Startup Sound – 不知道为什么 Mute 不好使. 拖到最左边还差一点的地方.

—

Adium 聊天.
AppFresh 更新软件.
Burn 刻 ISO. 内置的刻录软件刻录后必须检验完整性.
—注意一个问题, 关上盖之后就睡眠了, 所以低速刻盘再加上验证 (特别是 DVD+-R DL) 就很麻烦.
ClamXav 杀毒. 不知道有没有更好的选择. 反正也没遇见特别的情况.
Firefox 主力浏览器. 由于插件问题暂时不考虑升级 Firefox 4.
GAE Launcher 没怎么用. GAE Python 开发.
iChm 看 CHM
iStumbler 扫网络 (这个和 Kismet 差太远. 话说没有驱动, Wireshark 也不能抓包)
iLife & iWork 还没装 (这不应该拖出去打一顿… ). 虽说前者是正版的.
Lyn 看图.
MacVIM 可惜还是没完全学会用 Vim, 虽然说 vimperator 用的挺熟练的.
(这里所指的 macvim 是 google code 上的那个.)
MplayerX + VLC 播放器, 主要还是用 VLC. VLC 的快捷键必须带着 command 否则设不成. 原因未知.
TextMate 装了 D 版也不会用.
TextWrangler 至少暂时是最顺手的编辑器. 继续怀念 gedit + geany + …
uTorrent 下载工具
VirtualBox 虚拟 WinXP 用. hoho
Zipeg 难得的比较正常的解压软件. 原因是能够选择解压部分文件.

—

可以不看的杂类
Miredo for ipv6
rEFIt for multiboot
fink for wget (requires Xcode)

—

未解决的问题
HFS 的文件名存储是类 unicode 的什么东西. encoding 坏掉的话不能打开. 用 NFS 访问 Linux 机器上的文件时发现的问题. 不知 convmv 能管多少用.
装 Linux 耗电奇大. powertop 不能解决, 需要等更好的显卡驱动.

首先是五分钟法则的问题.
The Five-Minute Rule 20 Years Later: and How Flash Memory Changes the Rules

文章本身是很有意思的, 两年又过去了, 可以算一算现在的机械硬盘与 SSD 的价钱.

BreakEvenIntervalinSeconds = (PagesPerMBofRAM / AccessesPerSecondPerDisk) × (Price-PerDiskDrive / PricePerMBofRAM).
(另一个相对的公式不列了)

慢. 这个公式有个问题. 当然对缓存来说这基本是对的.
如果查询 item 存储位置的算法复杂度不是 O(1), 这个公式就要重新考虑了.

当然, 准确来说, O(logn), 这个 n 在一段时间内不会发生数量级的变化. 可以认为是常数.
但它既然不是 O(1), 那就应该把它算出来.
这里特别拿 B-Tree 来说, 要看这个树有几层. 有多少层已经被缓存到内存里了.
长期使用有 split 的问题. 空间利用率也不会到 100%.

此外 B-Tree 还有 Page Size 的问题. 原文说的很详细. 不提.

需要注意的一点是, B-Tree 的(随机)插入复杂度不可忽略.
B-Tree 不适于高 IOPS 的场合, 即便是 SSD.

—

CSDN TUP 的问题.

实时搜索.
P6 的中间, 加上 P8-9 的描述, 就是个 BigTable 的简化版.
如果有必要的话可以谈一谈 Bigtable 和 Cassandra.

内存 snapshot db 如果是可用性考虑的话好像有点道理,
这就相当于 memtable 大小设成内存一半略少.
如何平衡 bigtable 的几个 tuning 参数也是个小问题.

Feed 系统.
序列化, 压缩: Protobuf, QuickLZ
模板用 CTemplate 并不奇怪. memcached, tokyo tyrant 比较常见.
值得注意的是 Boost multi-index container 和 Flyweight.

以下摘自 http://flustar.javaeye.com/blog/160829

一、FlyWeight模式定义:
运用共享技术有效地支持大量细粒度对象。
二、模式解说
也就是说在一个系统中如果有多个相同的对象，那么只共享一份就可以了，不必每个都去实例化一个对象。在Flyweight模式中，由于要产生各种各样的对象，所以在Flyweight(享元)模式中常出现Factory模式。Flyweight的内部状态是用来共享的,Flyweight factory负责维护一个对象存储池（Flyweight Pool）来存放内部状态的对象。Flyweight模式是一个提高程序效率和性能的模式,会大大加快程序的运行速度。

对于 multi-index container 没有什么可评论的. 内存里怎么搞都行.

需要解决的问题方面, 数万每秒写入, 几千随机读都不是什么大问题. 不用 B-Tree 是第一步?

Direct IO 有人喜欢有人烦. 偶属于不喜欢也不排斥 Direct IO 的那种.
个人认为只有碰到 Double Caching 的情况再用.

关于用 Tokyo Tyrant 存 user-server 的做法, 越看越像 riak’s bitcask.

留一个算法复杂度分析当作业好了, 当然这里要考虑磁盘输出和 IOPS 的问题. 上面都说了一半了.

微博架构.

首先是 Push / Pull 的问题.
偶考虑到的是,
1 在线用户数量?
2 是否应该为非注册用户提供这么多实时服务?
3 用户分组带来了哪些影响?
4 服务利用率? 能否利用运营/用户监控数据? —那些不活跃的用户就不用…

要是偶会做两步.
1 hover 到推送 item 上的时候返回一个 beacon 回服务器. 分析这些结果.
2 偶要从应用上做监控, 看究竟有多少人真正得到了推送数据. 这个利用率如何. 比较哪种方式开销小.

关于 memcached 分组/库的问题没什么意见.
但 memcached 内存利用率低是众所周知的? 浪费一点也是浪费, 对吧.
这里有一个平衡问题(要容量还是要吞吐量). 还要注意前面提到的五分钟法则. 这是对普通场景来说的.
但这种 Cache 使用方式决定, 法则不适用于这种场景.
新浪这种发展模式本身注定就是自找事, 偶说把僵尸用户处理一下(加个 flag 不考虑对它们的推送), 问题说不准就可以再推迟上半年.

以下摘自 关于新浪离职

这中间有个问题是，确定需求的人基本不关心技术架构，都是在需求确定之后，讨论实现方案。

hotkey & mutex. 加一层 proxy 是可以了.
用 gearman + uniq 的方法看起来像 RPC. 那这个事情就应当作为 RPC 来看.
直说来还是技术上有问题. 对同一个请求你敢让多少台机器帮着处理? 数据的缺漏对这个应用来说并不关键.

回到 memcached 的话题. 如果都这么穿透到 db 的话, 是不是对 db 的保护不够呢?
还要加 db proxy layer 吗? 还是干脆只允许专门的机器处理数据库访问?

ps:
更尖锐一点说, 为什么数据库那么脆弱 ?

ps2:
“明白运作原理是部署应用的前提” 这句话对吗?

0.99.9 这个版本接近于这个 Code Base 下偶能做到的极限.
仍然有几个小问题做的并不够好. 不过这些问题完全不影响使用就是了. 最近也没有修掉这些问题的计划.

1 第一次超时, 第二次 (Range) 请求成功问题
如果这个文件并没有超过文件大小的限制, Range 反而是多了一步.
而且 Range 的处理也不够恰当.

如果未来能做重构的话, 偶直接会去掉 urlfetch limit 方面的判断.
把 Range 请求和普通请求用同一种方法解决.

此外要说, 偶虽然会用 Python, 但仍然没有用到语言独有的特点.

2 Range = 下载软件?
这种事情偶只遇上过一次. 就是明明写着 0-1023 却返回了 1023 bytes.
代码中有专门的判断以修复这个问题. 代码倒是很烂的感觉.
判断应来多少 bytes, 实际来了多少 bytes, 本次来了多少 bytes.
就别管它是否是 206 了.

3 加密与提交问题
WallProxy 用了一种简单的异或加密法. 还自己写了一个类似 urlencode 一样的函数.
偶觉得这种方法实在太朴素, 太奇怪.

首先如果要符合正常的 http 模式的话, 大号 POST 请求肯定要用 multipart/form-data.
直接的 POST 是 application/octet-stream 类型, 但从来没有浏览器会直接用这种 Mine Type 提交.
稍微注意一点的就会发现这个请求有问题, 完全不是浏览器发出的.

最初, 在原版 GAppProxy 基础上用了 Base64 以避免 encoding 的问题, 但要损失 1/4 的上传限制.
后来有了这种方法:
request = cgi.parse_qs(self.request.body) for k in request: request[k] = request[k][-1]
(thanks to @hexieshe)

最终还是用 multipart 解决了这个问题.

关于异或加密的问题. 偶说, 按照 block 来做几次循环移位或者是交换, 然后再用一次 xor 效果都比现在这种好的多.
当然确实是因为条件所限无法在这一层上用强加密.

真的要加密, 那就 SSL. 这没什么可争的. 只是验证 SSL 证书的任务只能靠自己.
当然 GAE Python SDK 上传的时候有验证证书, 这块代码可以考虑拿来.

既然说到这里, 不生成自签名证书的原因也就清楚了. 还有一个 CNNIC ROOT / SSL 的问题, 这里不提.

—

GAppProxy2 的推荐用法.

Google 系列服务, 靠 hosts + HTTPS 绝对没问题.
无论是 ipv4 还是 ipv6 都是这样的, 没有 https 支持的, 再用, 偶不反对.
前两天有人说 encrypted.google.com 不行了. 你出去看一看, 它的 SSL 证书的主机名是 *.google.com.
只要再找一个同样的出来, 这事情就解决了.

如果你有留心的话, 会注意到 proxy 可以设置成 google 主站, 甚至是 ipv6.google.com.
同样的方法… 加上 pac 文件, 也算是一种可以用的方法.

Facebook 有 ipv6 了, 好不好使是另一回事, 偶暂时不管.
上篇文章写了一种用 ipv6 上 twitter 的方法. 这里不重提了. 原有的 ipv6 文章也更新过了, 可以去看.
dabr 什么的也不是不能用. 所以这个事情没必要说太多.

最后一篇. 预定是 4 篇就能结束的.
只是因为突然发现自己 2008 年就写了一篇很有意思的文章(搜索搜到自己了… ), 于是决定继续写.

—

网站分析师(前端技术方向), 培养方法是极其简单的.
Noscript 会用不? 会导出黑名单列表不? (这一步会卡住一些人)
导出列表之后去找一个又一个 js 文件, 分析. 分析 30 个就没有任何问题了.
(前提: 不能是同一个统计平台, 必须包括几个功能强劲的大号产品, 要知道 mousetracking 这类玩意是怎么实做的).

—

统计系统本身也存在一些细节上的问题.
2008 年年中的时候就写过这样的文章, 现在看只有偶自己做了这一点.
当时写这篇文章是为了只用统计代码实现日志分析的功能.

简单说, 偶用两条一样长的腿走路.
也就是统计代码的实力和日志分析的能力比较接近. 虽然这种比较本来就没什么意义.
过期文章解密: fcicq 的不满, 统计

偶虽然不能把自己统计系统整个拿出来,
不过, 偶可以把偶走过的路简单的总结出来. 整个流程对有基础的同学来说是很快的.
1 用 GA 和 国内的 51.la. (重点: 要像小站长一样看用户访问的页面.)
2 用 GA 学 Action Tracking 和前端技术.
3 用 51.la 学习从页面/关键词级别理解用户, 理解国内的复杂网络环境.
—可以用看 Raw Log 代替, 可是这太枯燥了…
4 写自己的统计代码, 不断修正优化统计代码, 增加(有用的)功能. (参见上面的培养方法)
—服务器端可以暂时用文本文件收集, 可以考虑用修正服务器端的方法提高用户分辨精度(见第一部分).
5 用 awk 分析文本文件 (文本文件的格式?). 生成文本报告.
—这一步就会出现指标问题了.
—既然能生成 CSV, 做图还难吗?
6 改写 awk 代码为 MapReduce. 实际上用什么都可以…
—什么 MR, 这是一般人用的东西吗… (画外音: 用 awk 模拟模拟行不 … )
7 分析报告(对产品)产生实质性影响.
—A/B Test? 转化率分析? 别忘了还有行为统计的问题.
8 增加高级数据挖掘和统计算法. 实现网站日志与统计代码的协同分析.
—许多人会挖关键词, 如果做到这里不愿意做统计了, 可以转做 Adwords, 当然 SEO 也可以…
—可以继续做其它的方向, 比如商业智能, 运维(安全, 性能优化, 监控…).
—就说商业智能吧. 把 uri 映射成具体产品(无关的扔掉), 这个肯定比真实的业务数据库还要大上一两个的数量级. 先不看推荐的效果, 就这个经验你要还是不要?

—

这一个系列综合了许多方面的内容. 意思上基本上都表达出来了.
使用偶的描述加上一些其它统计的经验, 就能够复制一个出来.
偶不知道有多少人在看. 不过从 2008 年那篇文章没有引起任何重视来看, 偶还是可以继续在前面找个椅子坐坐歇歇.

最后一句话结束: 白送你的数据仓库, 你要不要?

ps:
这话是什么意思呢?
1 数据是白送的.
2 练习的机会是白送的.
3 它既然是数据仓库, 就值得用专业级工具.
(但没鼓励你去烧钱. 你能复制 SPSS 也不错. 有些人靠一个算法的实现就能打天下)
4 如何利用数据仓库? 这个问题留给你自己吧.

小剧场:
仓库里躲着的都是用户, 一个一个揪出来, 给发糖吃 … 有不要的吗…

—

Web Analytics 浅谈系列文章列表:
Web Analytics 浅谈 (1)
Web Analytics 浅谈 (2)
Web Analytics 浅谈 (3)
Web Analytics 浅谈 (4)
Web Analytics 浅谈 (5) – 最终回

关于分析指标的定义.
偶当然知道有介绍相关知识的 blog.
有会日语的同学请看:
アクセス解析の集計と用語定義ガイドライン
(粗译: 网站分析统计用语定义指南. 有想翻译的须要联系原作者.)

但这个问题偶并不这么看.
既然有 MapReduce, 有 Pig 语言, 这事还有什么难的?

有几个指标偶不是太喜欢, 做了一些修改 (但如果你的程序改不了, 你就别照做了 ).
1 Page View.
综合判断为非 Bot 的访客访问的动态页面数. 另外参见下面的 Visit.
(注1: 静态页面分离, 白名单制. 注2: 访客的判定与页面统计代码有关.
注3: 页面统计代码触发数量与日志记录数在统计上方差不大于特定数值.
注4: 会专门处理非名单上的地址列表, 供产品和运营/安全分析)

2 Visit.
Visit 的问题在第一篇里就说过了.
所以对偶来说的 Daily User PV = “本日来的 visitor 总共贡献了多少 PV”.
甚至是本日新来的 Visitor … 当然这个指标不如这个有用: “从某地(这属于 Campaign Tracking)来的新用户, 今天贡献了多少 PV”.
都能长期监控一个订单的起源是谁的推荐, 这个, 不难.

偶说的这个 Daily User PV 指标在 0:00 的时候是无法得到精确结果的. 但你多做几天就大致能够得到与真实日志的比例.
从这个描述就可以看出, 这个 Visit 没有跨日问题. 但 PV 跨日了.
旧有的指标又不是求不出来, 对照看看就可以了.

3 Bounce Rate
这个不根据日志不行. 想提高正确率就要这么干.
已经见过非常多的案例说第一页统计没记录到, 第二页带着第一页的 Referer 当作新 Visit 了. 解法就是使用日志修正统计.
这个定义和实际情况有关: 以日志中记录为准, 判定为非 Bot 用户产生的 Bounce 算 Bounce. 这样就可以算 Bounce Rate 了.

—

DNS 服务器日志别扔了. 有用. 可以分析从 DNS Response 到 HTTP Request 之间的时间. 这个数值有什么用那就自己想了.
这种分析需要考虑阻塞问题, 预抓取问题, DNS 中转(及地域)等问题.

思考题: 如果给你较长的时间(考虑到延时), 但只允许在 A 记录中返回 k (k 肯定大于等于 2 ) 个 IP 中的其中一个, 你能否定位一个具体用户使用的是哪个 DNS 服务器? 假定用户每小时访问该站一次, 并在访问时用 (本地的) DNS 解析域名.

—

关于技术细节.
图片里也能传数据. 参见 网页统计与 35 Bytes GIF
简单说就是图片的长宽可以做很多事. 也有人喜欢用 HTTP 204 返回一个空文件.
如何使自己的统计图片躲过 Adblock? Privoxy 也有一定的防监控功能.
这个问题自己研究, 篇幅所限, 不写了.

不过具体是否需要这种 hacks 要看情况的. 有些人就会匹配 1×1 .
不传数据的话就不需要太重视这个方法.

未完待续. Part 5 为最终回. 预计发布日期未定.

非常不幸, 因为 btrfs 上出现了一个坏块 (这还是 SSD 呢), 文件系统被部分破坏以至于不能修复.
备份了 /etc 和 debfoster keepers 就开始重装了. 2 h 不到就重新回到了正常的工作状态.
系统也升级成了白鼠专用的 Ubuntu 10.10 Alpha. 内核是 2.6.35-6-generic.
安装使用了 netinst iso (提取安装用的内核和 initrd 即可).
debian installer 暂不支持 ipv6 安装, 看起来也没有要支持的样子.

—

一定要准备另外的启动盘.
默认安装的是 grub. 升级到 grub2 可能会有意想不到的问题.
/etc/default/grub 应该是需要修改的.

如果使用 netinst 安装, 要把 /etc/network/interfaces 中关于 eth0 的部分去掉, 以使用 network-manager.

把 /proc/cmdline 的一部分写上, 以免再丢.
acpi_osi=Linux force-hpet pciehp.pciehp_force=1 pciehp.pciehp_poll_mode=1 usbcore.autosuspend=1

—

在 en_US.UTF-8 环境下启用 ibus (不要用 root 权限!)
im-switch -z all_ALL -s ibus

DHCP 获取地址时启用 dnsmasq. (dhcp3-client, a.k.a dhclient)
sudo sed 's/#prepend/prepend/' /etc/dhcp3/dhclient.conf --in-place

Aria2 多线程 ipv6 下载 (重点是 async-dns 参数). 可以考虑 alias 一下.
aria2c --check-certificate=false --async-dns=false FILE
Aria2 下 Torrent. 上传限速 50k. 监听端口最好改一改.
aria2c --listen-port=6881 --dht-listen-port=6882 -u 50K TORRENTFILE

省几个 Request 这不是命令.
APT::Acquire::Translation "none"; (/etc/apt/apt.conf.d/99translation)

使 OpenSSH Server 不做反向解析. 注意 tee 的参数.
echo "UseDNS no" | sudo tee -a /etc/ssh/sshd_config
(话说实际上偶喜欢用 sudo sh -c 一套. 只是害怕漏掉参数)

命令行添加 ppa. (需要 python-software-properties)
add-apt-repository ppa:user/repository

/etc/ntp.conf 设置服务器 server time.buptnet.edu.cn
选择它的原因有两个. v4/v6 双栈, 单 IP, 不会造成大的负担 (从 Wireshark 看重试次数少).
大规模应用还是应该部署自己的 NTP 服务器, 很容易的. 替代品可以选择 ntp.sixxs.org.

用 pavuk 抓站. 相当于多线程的 wget -m -np URI
pavuk URI -progress -dont_ave_dir -nthreads 10

整理 Firefox SQLite 数据库.
ls ~/.mozilla/firefox/*/*.sqlite | xargs -n1 -iabc sqlite3 abc "VACUUM;"

走到哪里 MAC 换到哪里. (需要安装 macchanger)
sudo sh -c "echo IyEvYmluL2Jhc2gKbWFjY2hhbmdlciAtYSBldGgwCg== | base64 -d > /etc/network/if-pre-up.d/eth0-macchanger"
sudo chmod +x /etc/network/if-pre-up.d/eth0-macchanger

关于前端技术.
要想把 DNS lookup 和文件请求数都降下来, 首先要把文件拿到自己的网站上, 甚至和自己的 js 文件合并. 这个地方偶觉得某些人还是太信任大厂了.
是, 他们能把 uptime 优化的很好, 网络方面 BGP 互联的链路也有好多条. 前面都说了有 DNS 和请求数的问题, 所以这一条还是有必要专门提出来的.

偶跑会题玩, 大家不要介意, 看不明白请跳过.
现在 IPv4 的情况实在是太混乱. 省级 ISP 都有 AS 号码了吗? 偶印象中好像不是 100% 都有.
就算有, 那又是谁在管理广播这类的事情呢? 要没人管的话有也没用.
IPv4 还一年多就用完了, IPv6 这方面基础做的还是不错的. 日后 IPv6 时代想做双线 BGP 机房偶想也会比以前容易的多.
电信和网通的距离不就是两个核心 AS 的距离嘛. 他们不想直接相连那就慢.
(更多牢骚请见 ps, 错过会后悔的 )

不跑题了. 有些网站加了不只一个统计代码. 甚至不开 js 就不允许访问具体内容页面. 你要只是一个小网站加着玩偶倒不反对.
新浪是一个非常坏的典型. 偶倒要等着看新浪多数页面的 yslow 评分到哪一年才能提到 65 分.
偶就说, 这么大的网站搞优化确实不易, 但需要注意的是, 体验和口碑又值多少钱呢?
别以为你不是 Amazon, 卖的不是具体产品就可以不考虑这些问题.

许多人招聘的时候要求前端不容忍页面上像素的偏差, 偶的看法不一样.
字体, 间距, 像素图这样的东西差 1px 区别挺大, 但分栏上错 1px 偶倒不觉得会有什么问题, 虽然说现在有各种 Grids, 想搞错也难了.

闲话打住. GA 的异步新代码出来有一段时间了, 这个代码的特点是 _gaq.push().
在统计代码加载之前它就是普通的 array (如已加载则保持不变). 加载之后它处理 queue 中的项目, 并接管 _gaq.
测试自己的代码的方法, 就是放马去溜. 嫌慢不出结果的可以自己多模拟模拟.
IE Tester 不错, 但偶好久没用过了. 这方面真前端更有发言权, 偶是个冒牌货.

关于数据采集.
IP, 网址, 来路(Referer), User-Agent 什么的就不说了.
访问深度这个概念偶不知道是什么时候提出来的. 这个指标是根据短时记录在 cookies 中的来路和网址做综合的判断得到的. clicki 的代码可以作为参考. 人均 PV 数很容易求, 不提.

国外的分析喜欢用 Visits, 国内则用 IP. 偶更倾向于 IP 的判断, 但如果能够合并跨两个 IP 的 Visit, 偶倒也愿意.
偶认为, 面向用户群的不同是产生统计区别的原因.
面向新用户的网站更倾向 IP. 更注重回头客的网站喜欢用 Visits. 这两种实际上是不矛盾的.

屏幕颜色深度, 分辨率之类的拿了也就拿了. Java 和 Flash 支持的问题偶觉得没有必要占据大量的代码空间. 语言时区还算比较必要.
接入商值得花时间去分析. GA 用的是 Whois 记录. 国内则喜欢用 IP 库, 确实用 IP 库能分析出不少东西来.

行为统计是一个热点. 可是你的统计系统是否有能力得到这样的数据?
例如有行为 A 的用户也进行了行为 B. 这类用户特征 C 的比例较平均要高 (特征即来路, 地域等指标).
从商品上做协同推荐偶想很多人都能做. 从这个层面呢?

未完待续 (不过下篇写什么还没想好, 时间跨度也许会长一些).

ps:
偶选择托管商的方法是非常简单而又有效的 (因为偶没钱). 如果能够接触到目标服务器的话可以用直接统计法.
从后台统计分析出访问分布来, 取几个排名靠前的 ISP 网络并在其中取几个间隔较大的 C 段 IP 作为样本.
收集一些 traceroute 数据分析一下 (如果只是直接看的话推荐 mtr, 反正这个怎么搞都可以).
使用 (traceroute) 节点间平均速度 (后一个减前一个) 构建(最小?)生成树. 最后算权重就可以了.
—此时生成树应该包括大量的中间路由器, 目标节点, 用户节点 (不一定要是真实用户, 离用户还有一两跳就可以认为是用户了)
如果你会点统计知识的话可以把方差也考虑上. 这里还有一个权值的问题 (用户分布不均匀).
这种方法只需要一台机器, 不需要找用户去 ping (为什么?). 精确度虽然比 ping 要差一些, 但对于这种用途偶想也够了.

不知道这种方法能省多少钱和乱跑的精力. 这种方法就送到你面前了.

ps2:
当初偶说豆瓣很原始, 鼓动用户去 ping 服务器测速.
参见 纯属道听途说的笔记

贴子名字是 “请帮忙ping一下两个地址”.

关于移动设备.
先插句或许无关的嘴. 不管怎么搞这都是个整体工程. 运维不提供日志的话一切白搭.
移动设备的 SEO 方面可以部分忽略掉(你说为什么?). 但页面的加载速度仍然是非常关键的一个指标. 既然内容仍然是大头, 所以怎么搞都差不多.
闲话完了, 说 uri rewrite.
举个例子好了. 论坛的 uri 里有分页(thread-(ID)-1-(PAGE).html).
这个 page 是用来记录版面列表分页的, 中间的才是帖子内的分页.
那么为什么不能搞 t1234p1.htm 这样的 uri, p1 仅作统计用.
(p1 = position 1, 重写之后变成类似 page.php?t=1234, 以便后端缓存)
如果要考虑(正常页面的) SEO 的问题, 可以用 link rel=canonical 什么的, 这个略过.

刚说完 uri rewrite 问题, 偶说个场景你考虑一下.
如何使用统计在后台模拟 digg 的算法, 然后把数据反馈到前台链接排列中去?
偶给一个提示好了. 如果一个排名为 k 的文章的 CTR (Click-through rate) 在统计上不满足该名次的分布(差 p 个标准差), 那么就把它拿到 k+1 或者 k-1 名上.
这里没有考虑旧文要往下拿和新文往上推的问题, 细节你要自己考虑.
感觉这就和在做广告系统一样, 对吧. 事实上统计就应该按照广告的要求来做.

更高级的可以考虑这样的要求, 偶对一篇文章的标题做了修改(注意背景还是移动设备, 没有 Javascript 支持).
修改的生效时间不知道(但可以假设有足够的访问量), 需要你从统计数据中尽力读出这个修改的效果.
(实际上这是没有统计代码参与的变相 AB Test, 你要怎样做?)
而且还涉及另一个问题, 如果你从统计上读到了变化, 却不知道具体做了什么修改, 那又要怎样获取相关信息呢?
话说回来, 运维喜欢定时监控, 而对统计分析这块又有什么启示呢?

未完待续.

ps:
Amazon 能够做到你浏览几页之后就自动给你做相关推荐, 这当然是实时的.
偶当然知道做这种东西成本很高, 考虑到推荐同样也是提高转化率的利器 (就算是推荐了相关率低的商品, 也有一定的收集数据的作用), 你自己可以考虑这种东西是否值得一做.

这个 Blog 上之前部署过好几种统计代码. 这次就谈谈网站分析这个问题.
这篇文章也是为了填一个去年就挖出来的天坑. 原来的主题是 聊聊网页统计.

—

另类统计方法.
最需要说明的是, 不依赖 Cookies 也能做分析. (原题是关于 Cookies, 这句就不改了).
CSS :visited 选择器, 甚至可以批量探测用户可能上过的网站. 最近一些浏览器开始对这个选择器下手了, 把这类问题从源头上堵住.
User-agent, 各类 HTTP Headers (Accept, Accept-Language) 都可以做为浏览器指纹(可以参考 Panopticlick).
If-Modified-Since, 这个方法可以用在图片或者 js 上, 具体应该怎样用别问偶. 这个效果也不错. 重点是要后端有条件提供详细日志(一般日志不行). 这绝对是杀手级的, 只是部署与分析难度大了点.
phpbb 等一些论坛, sessionid 是挂在链接上的. 当然这相当于 cookies 了.
(不过是把数据存在了服务器上, 由服务器控制记录的时间.)
Yahoo 系(日本?)的网站在链接设计上下了不少功夫, 分析和应用连在一起无法分离.
(delicious 也是这样的, 但 javascript 的启用情况也会影响分析的方式. 关闭 js 使用的是 uri 方法, 开启 js 使用的是 js + 图片分析.)

关于数据存储.
网站有名气了就树大招风, 连 cookies 的过期时间都有人管. 当然偶觉得这个问题不是很重要.
重要的就一个 unique userid, 在数据库里把一切都对应起来好了.
如果有能力的话可以把上面提到的一些分析方法在应用中实现.
偶是觉得 http headers 用一些办法计算指纹是挺容易的. 就看你愿不愿意实现之.

不愿意在分析技术上投钱就罢了. 连最起码的全日志存储都做不到, 就等于… 人家把钱给你了, 你收下一部分然后把另一部分扔了. 也许这个比喻还是不够恰当
有些人就纠缠在 Visit, PV, unique visitors 什么的概念上. 所有的日志都在手里, 爱怎么定义怎么定义.
偶承认跨日访问是个难题, 那为什么不能做从本日来的 visitor 总共贡献了多少 PV(这个可以跨日)? 收集几天数据自己就能得到一个大致的 PV 推算关系.
总是想着 0 点出上一天的报表, 是这个问题的来源之一.
都说 Realtime 是趋势, Twitter 什么的都是实时的, 统计为什么不是?

time on site. 这个问题需要说明确吗? mousetracking 都能做.
如果考虑服务器负载问题, 那就用存储法, 在访问下一个页面的时候把上一个页面的情况传回去如何?
这个统计不准确的问题, 应该是有很多方法解决的. 就看你愿不愿意做了.

未完待续.