杭州电信分公司真是一家垃圾企业，流氓企业，无赖企业！ 强行涨价，也就忍了；强行限速，也就忍了；劫持 DNS ，也就忍了；乱弹广告，也就忍了…
可是，我办理一个 ADSL 服务，20 天之前交的费用，承诺 24 小时联系，可实际上没有主动打过来一个电话。这么多天前后打了几十个客服电话，每次都是经过漫长的 “线路忙，请等待” 之后，有个活人的声音(其实要弄个机器人估计也成)，要你报上身份证，然后听到一句 “很抱歉，我们将尽快为您办理” 之类的不痛不痒敷衍的话。
什么时候能安装? 他们永远说不上来；你继续打电话，还是这样，什么时候能安装? “我们也不知道”‘；进行到什么状态? “我们也看不到”；我要投诉，找客服主管? “客服主管有，我找不来”。
你大爷的杭州电信! 这样的垃圾企业，如果不是仗着垄断，早该倒闭了！
–EOF–
到今天，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–
尤其要感谢从前我的女友–当然，现在已经是我的老婆–感谢她容忍我不陪她逛街或是摄影。
在前不久结束的 QCon 2008 上，MySpace 的首席架构师 Dan Farino 做了题为 Behind the Scenes at MySpace.com (PDF 下载)的技术演讲。
超过 4,500 台 Web 服务器，配置为 Windows 2003/IIS 6.0/ASP.NET ；超过 1200 台 Cache 服务器，64 位的 Windows 2003，超过 500 台的数据库服务器，配置为 64 位的 Windows 2003，数据库为 SQL Server 2005 。
之前曾有一篇 揭秘 MySpace 架构的文章，也有中文版本《亿万用户网站MySpace的成功秘密》，请 Google 之！
其实这个演讲我感觉主要讲的是这个数据收集模块 :) MySpace 的方案倒是让我们看到了在超大规模的 Windows 环境下如何进行数据收集的。
每个客户端通过一个 TCP 连接到收集上服务器。收集的信息包括：Windows 性能计数器 Performance Counters、 WMI 对象(定制后的 WMI 对象)、事件日志、 硬件数据等等。收集器服务(Agent) 用 C#实现的，完全的异步 I/O，用了微软的 Concurrency and Coordination Runtime 库。每台主机上一个 Agent。其实国内也有超大规模的 Windows 环境 — 比如盛大，数据采集和监控的机制倒是类似的。
数据协议用的 Google 的 Protocol buffers。这倒是看到 Google 的这玩意儿公开后第一家大站点在用。也是因为用 Protocol buffers 从而不用 XMPP+ejabberd 的消息处理方案。
QCon 是我非常心仪的技术会议。可惜今年因为客观原因没能组织同事去参加。期待 2009 年在伦敦的会议。
–EOF–
延伸阅读：InfoQ 对 DanFarino 的专访。
周末的时候看到这篇 Scaling memcached at Facebook，感觉挺有料。但似乎又没什么可写的。最多就是准翻译一下。
相比之前介绍过的数据( 5TB数据/400台服务器).，现在 Facebook 在 Memcached 上的内容已经超过 28TB，总服务器数量超过 800 台。可见硬件降价真是够快的，内存的确便宜得很。
Facebook 作出改进的第一个问题是 Apache (连接带来的)进程连接开销问题。实现了一个针对 TCP/UDP 的共享的进程连接缓冲池。共享的方式比针对单连接独占内存的方式节省不少内存资源。考虑到一共有 800 台乃至更多的服务器，总体节省的内存资源是惊人的。
第二个改进是 UDP 模式的效率问题。第三个改进是网络中断给 CPU 带来的影响，这个我觉得就是变相的实现了 Intel I/OAT 的某些功能。补充一句，网络中断的问题其实是给很多企图制造山寨存储的技术人员一个拦路虎。
最后一个问题是在 8 核芯片上发现的新瓶颈。这个问题我想对于在多核机器上跑 MySQL 也会有很大借鉴作用。CPU 不是越多越好。有些开源软件与硬件的配合上面应该的确稍微滞后(不是落后)一点。
四个大的改进的结果是从 50, 000 /s 的 UDP 请求到 300,000 /s 的 UDP 请求支撑能力，延迟只有 173 微秒。
Facebook 的技术还是挺开放的。这一点上比 Google 强多了。
–EOF–