一晚失眠，好不容易要睡着，报警短信狂响，爬起来，登录上去，检查半天，暂时不能定位到问题。兄弟们住的都比较远，干脆我自己跑到公司吧…
这半年来，我还真的很少这么早走在马路上，街上好像刚洒过水，真冷。公司楼下的 KTV 那边走过来一群人，估计刚唱完歌，年轻人真有精力…
到公司仔细检查了一下，还算顺利。定位到问题，基本上能控制住影响。又等了一会儿，厂商工程师赶到(大家都不容易)，对坏的模块重新换了一个端口。我这头检查主机，状态也正常了，才算放下心来。
这就回家睡觉去，这日子过的!
–EOF–
作者文章: Fenng
PlentyOfFish 网站架构学习
采取 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–
性能扩展问题要趁早
与国内的 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–
游戏公司在招聘哪些 DBA ?
随着国内游戏公司不断上市，相关从业人员也是水涨船高。钱多、人傻、速来，以此为诱饵，猎头公司估计也大赚一票。作为控制用户数据的 DBA 肯定是颇为短缺的。
长夜漫漫，闲极无聊，收集了一下当前游戏公司都在招聘什么数据库的 DBA。未必完全准确，权做参考。
| 公司－ | 数据库 |
| 盛大－ | Oracle/MySQL/SQL Server |
| 金山－ | Oracle/MySQL/SQL Server |
| 网龙－ | MySQL |
| 九城－ | Oracle |
| 网易－ | Oracle |
基本能看出来，Oracle DBA 还是比较多，多数公司还是会把核心的数据或应用跑在 Oracle 上。而排在第二的就是 MySQL了。至于 SQL Server 排在最后的原因，可能还是因为有些小游戏跑在 SQL Server 上，而维护基本是开发人员搞定，专门的 DBA 就不需要了。至于 DB2 ，还真不知道哪家游戏公司用。
至于核心的技能，MySQL 在 Replication 与 Cluster 架构两个方面是必须的。而针对 Oracle 来说，优化、 Data Guard / 备份恢复则是必须要求的技能。
–EOF–