推荐《构建可扩展的Web站点》- 基于监控的系统调优

在前一期 山寨交流会 上： 桂 新 说他会将良好的构架和一套完整的监控系统作为两个非常重要的基础来抓，良好的架构一步到位这点很难做到（对于发展速度并不确定的小公司来说，架 构过大也是一个成本上的风险），但对于后者：一套完整监控系统我是非常认同的。对于目前普遍缺乏测试的Web应用开发过程来说，监控几乎就是测试很重要的 一部分；而系统监控本身，也可以帮助及时发现很多问题并量化优化的效果。而系统的扩展和调优的大部分技巧都可以从《构建可扩展的Web站点》(作者是 Flickr的开发者)一书中看到。为了减少不必要的调优（盲目的调优是危害很大的），建议从这2章开始看起： 第8章《瓶颈》发现和第10章《统计数据，检测和报警》；有了这些瓶颈检查结果和统计监测/报警系统后，再有针对性的看其他章节做系统调优。

以下是我在 博客大巴 开 发中的一些实践小结：

1 数据库相关

1.1 系统应用层面出问题我一般都习惯性的先去看数据库群的连接数统计：大部分应用最后的瓶颈都在于单表数据量过大后，数据存取慢导致的并发连接数过多的问题，

1.2 解决这个问题目前的主要策略就是分片( share nothing)，单个数据库连接数超过100，就想办法拆分并用多个daemon提供服务，数据的拆分也降低了单表的数据量；

1.3 对于需要全局访问的数据，通过另外冗余存储一份专门用于全局对比的操作用（会增加数据一致性开发量）；

1.4 slowquery一般是遇到问题才去看的，其实 binlog转换成文本格式后，也可以用 mysqldumpslow 统 计的，slowquery就是执行时间超过一定阈值（缺省是1秒）的binlog，更全面查询统计，则需要打开数据库的query log，binlog其实就是没有只读操作的querylog；

2 日志相关

2.1 对于应用来说：容忍过多的非致命错误容易让错误日志变得非常难读，从而对发现很多致命错误造成麻烦；在各种系统开发间隙，统计各种错误日志也是我非常乐于 去做的一件事儿，从warning faital级的PHP错误信息到404错误日志；报警后的急救车固然重要，日常的体检及时发现潜在风险较高的漏洞或缺陷并修正都会在系统真正发生报警的 时候为成功抢修节约大量时间；

2.2 经常出问题的环节要有错误日志，并且格式设计的比较 便于sort和grep 也 是很重要的一方面；

3 需求削减：

3.1 并非所有用户都需要被满足： 发现spammer 和 盗链者，并设法降低资源 流失的速度；

3.2 通过日志统计发现用户使用较少但对系统负载很高的功能；

此外：一个管理方面问题： 开发过程本身是日志是最少的，怎么解决？

而最近开发人员总很流行的2本书： 《高性能 网站建设指南》 和 《构建可扩展的Web站点》 都 是 博文视点 从O’Reilly引进出版的， O’Reilly 经常请业内专家（指的是有大规模成功实际应用案例的而不 仅仅是科研成果）写书并随系统发展一版再版，博文视点近期也在积极和IT业内很多设计师在联系写书出版的事宜：会看到更多适合目前国内环境特点的开发类书 籍出现；

本文出自： http://www.chedong.com/blog/archives/001422.html

• 系统架构