感谢豆瓣独家提供的两年托管赞助费用！这几天利用空闲时间把 Blog 站点迁移到了 Linode.com 提供的 VPS 上。或许，可以在一段时间内缓解重建页面的性能问题，用户留言的速度也会好很多。

原来站点放在 Dreamhost 上，但是年初的时候频繁遇到 HTTP 500 错误，那段时间，我发布一篇文章都要反复 Build 多次才能成功，很影响积极性。可气的是，Dreamhost 还不断给我发他们的 PS (Private Server) 的折扣信息，一不小心上了贼船，发现上去后反而下不来--不让且回到原来的共享模式下，结果几个月下来花了不少银子。性能，其实也没好到什么地方去。

建议如果 Dreamhost 共享服务器够用，就别升级，也别切换了。毕竟，Dreamhost 的共享主机性价比还是不错的，迁移起来，其实也颇为费事。

我买的是 Linode 360 这个服务整年购买还能优惠 10%，也有优惠代码，不过现在都过期了。购买之后第一个决定是要选择 IDC ，都说旧金山的 Fremont 速度较快，相信大家的，没错。主机用了 Ubuntu ，然后登录进去用 APT (Advanced Packaging Tool) 安装软件或者更新系统，速度那叫一个快啊。早知道这样，再贵一点可能也要买 Linode。在 Dreamhost 上折腾来折腾去的浪费多少精力... 在 Linode 上，如果后续需要更大的内存，随时可以扩容，操作极其方便。 对于CPU 能力、硬盘空间和带宽开销，似乎也很难用到那么多，如果喜欢调试服务器，倒是可以看看怎样能更有效利用内存。对于技术爱好者来说，Linode 是个很好的操作系统玩具。

大家都喊着"云计算"，但是面向个人用户这一块的市场需求似乎没有人关注。随着硬件价格的下降，VPS 服务越来越值得个人用户使用，或许，明后年，个人用户也能用上 Amazon 的 AWS 服务了。技术的乐趣在于折腾。

接下来，可以静下心来好好写一阵东西了。

广告：

• Linode 的 Refer 代码：92405a6e282a712f7a1270e98d16eba13efb1b68 。用了这个代码注册，过几个月据说我可以得到一点好处，就当你做一回雷锋 :)
• 如果要使用 Dreamhost ，我以前設置的优惠代码：FENNG 依然有效。
• 另请参见 BlogKid 对 Linode 的介绍。

--EOF--

延伸阅读：选择美国主机的机房地理位置与网络分析 http://oncn.net/641228

到今天，DBA notes 五年了! 从当年记录的日志看，2003 年 12 月17 日，这个站点"对外正式提供访问"。

前几天浏览 Flickr 上的历史照片，过去的很多场景似乎一下子又跑了出来，今天翻看站点的历史信息，也有这种感觉，那些记忆并没完全消失在时间里，它们还在...

看看还存在旧首页，还有从最开始的那些尽量"符合 Web 标准"的 HTML 页面，站点成立之初完全是用刀耕火种似的手工方式进行更新，直到后来换到了 Movable Type 内容平台。这个过程也是摸索、学习、实践互联网相关技术与文化的过程。从今年开始，Twitter(有 1000 多个 Follower 了) 似乎成了发布微格式内容的一个更直接渠道，不过只需通过简单的集成即可把消息显示在 DBA notes 首页，独立站点仍然是主体，将来可能也不会变化。

一直觉得自己是个不善于坚持的人，从没想过会持续 5 年的时间做一件事情，并且还在不断尝试做一些改进。5 年，1800 多天，在这个站点上发布了 1200 多篇所谓的文章，从开始的 Oracle 数据库的一些小品文，到一些鸡毛蒜皮的个人事情，再到网络评论以及网站架构介绍.....有的时候自己会考虑迎合一下读者的口味，有的时候则完全由着性子写。自己其实不太清楚为什么会一路坚持写下去，可能仅仅像吃饭喝水那样，没有更深层的原因。

上次在广州参加网志年会的时候，居然遇到了一位 4 年前就是我的读者的朋友，多少有点惊讶。5 年，通过在站点上表达的这些东西，认识了很多新朋友，也收到过很多来自他们的反馈以及建议与意见 ... 5 年，已经无法计算究竟为此花费了多少业余时间，不过有一点：我相信付出的那些时间都是有价值的。我付出，也得到了应有的回报。分享知识的过程是最让人快乐的，即使分享的那些东西或许微不足道。

回想当初申请域名时，最头疼的就是关于域名购买的网上支付问题，这也使我在考虑加入支付宝的时候无形中投了一票。从北京到杭州，如今也已经将近 4 年，互联网的支付问题已不再是问题，这其中有自己的一份力。或许，人在做某些决定的时候也只是其他某个地方的蝴蝶扇动了一下翅膀。阿里巴巴五年以上的老员工叫做 "5 年陈"，会有一枚戒指作为纪念。Blog 五年有什么纪念?

感谢互联网，没有这个神奇的事物可能我不会学到如此多的知识，更不会成为一个技术人! 感谢车东，我在看他的网站的过程中萌生了自己建个站点的想法；感谢 SixApart 提供的 MT ! 当然也要感谢 Larry Wall，因为 MT 是用 Perl 实现的；感谢 Dreamhost 提供的物美价廉的空间! 感谢 鲜果，让我今年 Blog 订阅量暴增。 感谢通过 DBA notes 我所认识的朋友们!

我会继续的...

--EOF--

尤其要感谢从前我的女友--当然，现在已经是我的老婆--感谢她容忍我不陪她逛街或是摄影。

我算得上是 Movable Type 的忠实用户。这两年来，WordPress 快成为 独立 Blog 的标准配置了，MT 可以说每况愈下。自从升级到 MT4 之后，明显感觉 Blog 性能糟糕了很多，每一次发文章都要与 HTTP 500 错误战斗半天才能成功，读者留言也非常费劲，有段时间非常灰心丧气，都不想继续写下去了。如果说 MT 3 之前是与 SPAM 战斗，到了 MT 4 就完全是折腾性能问题了。虽然 MT 4 之后的每次小版本发布都宣称性能上有很大改进，实际表现总是欠佳。

一些常规的 MT 优化技巧 其实作用都不大，我还把 MT 用的数据库索引分析了一遍，删掉了好几个价值不大的索引，虽然不是无用功，但也解决不了问题，因为瓶颈根本不在 DB 这里。大多数 Movable Type 用户的应用场景是在 Dreamhost 上，在这个环境里要想找到应用的瓶颈还真的是个技术活。缺乏 Profiling 工具不说，如果调用某个命令消耗了资源稍微过份一点，立刻被系统 Kill 掉。

其实 MT 的设计思想还是很不错的，大部分页面都 Build 成静态页面，减少对数据库的压力。一般来说，这比 WordPress 频繁调用数据库的方式(当然 WP 是可以起用 Cache 的)，应该在性能上有更好的表现才是。问题是 Dreamhost 对每个用户提供的硬件资源其实是很差的，尤其是磁盘 I/O 。我的所有页面加起来也不过几千个，如果只是访问静态页面或是数据库其实问题都不大的，麻烦出现在构建页面或者是遇到留言行为的时候，MT 会调用若干个磁盘上的模版文件，加上 Perl 本身的系统开销，消耗的资源就到了 Dreamhost 的极限，然后进程就被无情的 Kill 掉了。估计是用户群抱怨太多，从 MTOS 4.1.1 版本开始总算有了一个性能框架 专门用以分析性能问题(并且号召用户提供性能数据以便协助解决性能问题)。启用了一段时间后，收集到的 Log 响应时间典型是这样的：

MT::Template::build[Comment Response]=0.60070
MT::App::Comments::run=28.24320
Total=28.85665

或许在 I/O 不错的系统上，表现会好吧。Dreamhost 上文件都是放置在 NFS 上的，而且众多用户共用一个系统，只能将就一下。

今天看到 4.15 的改进中，已经可以 Cache Template Module 了。甘愿作小白鼠，升级。盼望这次能有效解决特定应用场景的性能问题。不过开启了性能 Log 看了半天，效果并非很显著，

后记：

经验证的有效办法之一

通过Cache提升MT基于Tag搜索的速度，只在第一次构建需要的 Tag 时候会占用平时一样的系统资源。再次搜索时，开销大大降低。"抱怨的同时要有解决办法"。

--EOF--

估计有些访问我的 Blog 的朋友已经被本站留言时的糟糕表现烦透了。其实我何尝不烦? 每当发贴子的时候，总要忍受一堆 HTTP 500 错误后才能成功，要多不爽有多不爽。趁着 (mt) 这段时间搞活动，买了一年 Grid Service (lite)。期待迁移完毕后 Blog 稳定性表现能好点。

有朋友帮我买了一台 1U 的服务器，国内有什么好一点的托管商麽? 最好不要被随时拔网线的，拔网线倒也问题不大，最好不要把机器抬走就成。

其实这么折腾来折腾去的，只是希望能有个稳定一点的写字儿空间罢了.

另外，今天也把域名转移的相关资料准备了一下，打算把这个域名也迁移到国外的域名服务商那里。不为别的，在国内一直不太放心罢了，虽然我的 Blog 没啥犯忌讳的内容。原来域名是通过代理缴费的，在这方面我是菜鸟，被鄙视的不轻，不过他们的服务态度还是很好的。

--EOF--