InfoQ上面的一篇文章《构建的可伸缩性和达到的性能：一个虚拟座谈会》
http://www.infoq.com/cn/articles/scalability-panel
这篇文章很好，给了你很多做可伸缩性的线索，记录下这些点滴。推荐感兴趣的人去InfoQ阅读原文。
- ab & httperf: 它给我们提供了一些自动化的负载测试，因此对比于我们从firebug中获得页面级的计时，使用这个工具可以获得会话级的计时。
- firebug:
- Ganglia是非常优秀的。同时Nagios或Zabbix（举个例子）将告诉你何时资料遭到破坏，使用少量加工你就能够让ganglia给你提供任何东西。
- 对于MySQL，Innotop + slow query log 帮了大忙
- GDB和DTrace是用于C++的基础架构。core或 pstack是个颇有价值的工具
- 我们使用各种工具来重现问题并调试它们（包括栈的问题）——Visual Studio、 Eclipse、WinDbg、cdb、Purify、Fortify、dtrace以及许多定制的东西，为我们的架构所构建的东西
- 从某点上讲，伸缩性已经从领域问题（即，如果你不使用内存缓存或者一个等价的分布式哈希表和基于内存的缓存）转移了，而你仍然处于“领域”范围
- 当今静态内容的可伸缩性已不那么重要了，那只是花钱的问题并需要公司有好的社会组织的问题
- 不要试图在部署之前就捕获性能问题。你不可能重建真实环境中的条件，因此你不可能得到真实可靠的测量结果
- 监测。非常仔细的监测
- 墨菲法则（一种幽默的规则，它认为任何可能出错的事终将出错）确保了你没有严密跟踪的衡量标准就是那个对你不利的标准！
- 除非你知道当时正在执行什么业务功能，否则一个CPU测量是无意义的
- 你只能通过使用软件实现伸缩性。“语言是不能伸缩的。框架是不能伸缩的。而架构是可以伸缩的。”