DBA notes

自从 FeedBurner 被阻尼了之后，离线 RSS 阅读工具就不能用了。基本上只用在线的，Google Reader 。可是仍然有很多 FeedBurner 烧录的 Feed 地址需要订阅，比如很多英文 Blogger 的 RSS。还有就是国内很多 Blogger 仍然异常"顽固"，仍然不换国产 RSS 阅读工具，最糟糕的是很多用户用了 "点击统计" （Item views） 的功能，阅读器里看到的不是源 URL 地址，而是 FeedBurner 烧录地址跳转，偏偏有的帖子还是没有全文输出或者格式不好，有的时候要看原文章不得不用代理，很影响我个人阅读体验。

对于 Firefox ，我用了一个可能比较土的解决办法。首先是安装 Vidalia （cross-platform controller GUI for Tor，至于 Tor 是干啥的，你可以问 Google)， 借着安装 Firefox 插件 Torbutton，安装这一个后，基本上你可以访问你感兴趣的那些被阻尼的技术文章或者站点了。但是这东西一是总要切换来切换去的(不切换的话又会影响正常页面的访问速度)，所以最好还是再安装一个插件 FoxProxy 。安装完重新启动后会问你具体的设置，点击几次 Yes 之后有个定制页面。如下图设置即可：

然后重启动 Firefox ，在 Google Reader 里面点击那些 FeedBurner 转发的 URL 就会自动处理了。在 Twitter 上有朋友推荐 Gladder，我没有测试，谁用过不妨交流一下。

另外，建议 FeedBurner 用户关掉那个 "点击统计" （Item views） 功能。如下图所示:

--EOF--

Posted by Fenng at 11:36 PM | Permalink | Comments (6)

一晚失眠，好不容易要睡着，报警短信狂响，爬起来，登录上去，检查半天，暂时不能定位到问题。兄弟们住的都比较远，干脆我自己跑到公司吧...

这半年来，我还真的很少这么早走在马路上，街上好像刚洒过水，真冷。公司楼下的 KTV 那边走过来一群人，估计刚唱完歌，年轻人真有精力...

到公司仔细检查了一下，还算顺利。定位到问题，基本上能控制住影响。又等了一会儿，厂商工程师赶到(大家都不容易)，对坏的模块重新换了一个端口。我这头检查主机，状态也正常了，才算放下心来。

这就回家睡觉去，这日子过的!

--EOF--

Posted by Fenng at 7:37 AM | Permalink | Comments (8)

采取 Windows 技术路线的 Web 2.0 站点并不多，除了 MySpace ，另外就是这个 PlentyOfFish。这个站点提供 "Online Dating” 服务。一个令人津津乐道的、惊人的数据是这个只有一个人(创建人Markus Frind）的站点价值 10 亿，估计要让很多人眼热，更何况 Markus Frind 每天只用两个小时打理网站--可操作性很强嘛。

之所以选择 Windows .NET 的技术路线是因为 Markus Frind 不懂 LAMP 那一套东西，会啥用啥。就这样，也能支撑 超过 3000 万的日点击率(从这个数字也能看出来人类对自然天性的渴望是多迫切)。Todd Hoff 收集了很多关于 PlentyOfFish 架构的细节。记录一下感兴趣的部分。

带宽与CPU

PlentyOfFish 比较特殊的一个地方是 几乎不需要 Cache，因为数据变化过快，很快就过期。我不知道这是因为 ASP.NET 的特点带来的架构特点，还是业务就是这个样子的。至于图片，则是通过 CDN 支撑的。对于动态出站(outbound)的数据进行压缩，这耗费了 30% 的 CPU 能力，但节省了带宽资源。我最近才知道，欧美的带宽开销也不便宜。

负载均衡

微软 Windows 网络负载均衡(Network Load Balancing) 的一个缺陷是不能保持 Session 状态(我没有用过这玩意儿，不能确认)，价格也不便宜，而且复杂；网络负载均衡对 Windows 架构的站点又是必须--IIS 的总连接数是有限制的。PlentyOfFish 用的是 ServerIron (Conf Refer)，ServerIron 使用简单，而且功能比 NLB 更丰富。

数据库

一共三台 SQL Server，一台作为主库，另外两台只读数据库支撑查询。数据库性能监控用的是“Windows 任务管理器"。因为 Cache没啥用，所以要花大力气优化 DB。每个页面上调用 DB 次数越少越好，越简单越好，这是常识，不过不是每个人都体会那么深而已。

微软好不容易找到了一个宣传案例，所以在 Channel 9 上有一个 PlentyOfFish 的访谈。

PlentyOfFish 取自天涯何处无芳草(Plenty of fish in the sea)的意思，还挺有文化的。从这一点上看，比国内那些拉皮条的网站好一些。

--EOF--

Posted by Fenng at 7:34 PM | Permalink | Comments (3)

与国内的 Web 2.0 Startup 技术人员相比，国外技术人员更乐于分享。分享也是一种更好的宣传手段，如果不是看到了这篇 Scaling an early stage startup， 或许我就不会知道这位 Mark Maunder (他还有个中文名字：马孟德) 以及他的 FeedJet。

一般来说，一个刚刚发布的 Web 应用，因为用户量并不多，性能问题可能并不是很明显。可一旦宣传展开，用户增长或许不是线性的而是暴增(从几十个到几万个，相比之下怎不是暴增?)，这时候如果遇到性能问题，毫无疑问会影响初期用户的信任。

Maunder 文档中列举了一个扩展过程，相信这些例子也是他实际遇到的。毕竟 Startup 都是一两个人打通关，不可能所有技术都面面俱到的精通。下面记录一点。

错误的设置

数据库服务器的参数配置问题：导致 MySQL 消耗了大量资源。Apache Keepalive 的设置为不合理，修改为 off。我想这个前提应该还是要选择自己最擅长的技术路线。如果错误的选择另一条不熟悉的技术路线，那么遇到技术时解决问题的速度怕是更让用户恼火。对于 Apache 还应该知道 Httpd.Worker 比 Prefork 消耗更多内存 (httperf 来进行 Benchmark) ，内存也是蛮贵的。

尽可能的缓存动态内容

尽可能的利用数据库的 Cache，利用其他 Cache 工具，如 MemCacheD，来减轻对磁盘的 IO 压力。为了节省成本，很多站点都是用的低速大容量的磁盘，所以，充分利用 Cache 是一个网站成功的必然条件。这样的软件BerkeleyDB 的最高事务处理记录是 90000 事务/秒。

剥离图片与CSS 到单独的服务器

说白了，也是为了减轻磁盘的压力。现在很多 Web 2.0 站点都把图片放到 Amazon S3 上，省心了不少。当然，国内还没这样的服务。

阻止内容引用"窃贼"

现在连那些大站点都在阻止图片被第三方引用，小站点更要提防被大站引用，很容易耗光网站的容量。另外一个要注意的是网络爬虫的频率。

在线观看这篇 Scaling an early stage startup。顺便说一下，最近在 Scribd 上看到了不少有意思的文档。

--EOF--

Posted by Fenng at 8:48 PM | Permalink | Comments (4)