对应用程序进行性能剖析

对任何需要消耗时间的任务都可以做性能剖析，也包括应用程序。实际上，剖析应用程序一般比剖析数据库服务器容易，而且回报更多。

虽然前面的演示例子都是针对 MySQL 服务器的剖析，单对系统进行性能剖析还是建议自上而下的进行，这样可以追踪自用户发起到服务器响应的整个流程。虽然性能问题大多数情况下都和数据库有关，但应用导致的性能问题也不少。性能瓶颈可能有很多影响因素：

• 外部资源，比如调用了外部的 web 服务或则搜索引擎
• 应用需要处理大量的数据，比如分析一个超大的 XML 文件
• 在循环中执行昂贵的操作，比如滥用正则表达式
• 使用了低效的算法，比如使用暴力搜索算法来查找列表中的项

幸运是，确定 MySQL 的问题没有这么复杂，只需要一款应用程序的剖析工具即可。

建议在所有的新项目中都考虑包含性能剖析的代码。 往已有的项目中加入性能剖析代码也许很困难，新项目就简单一些。

那么 性能剖析本身会导致服务器变慢吗？

• 回答是：是因为性能剖析的确会导致应用慢一点
• 回答不是：是因为性能剖析可以帮助应用运行得更快

性能剖析和定期检测都会带来 额外的开销。问题在于这部分的开销有多少，并且由此获得的 收益是否能够抵消这些开销。

大多数设计和构建过高性能应用程序的人相信，应该尽可能的测量一切可以测量的地方，并且接受这些测量带来的额外开销，这些开销应该被当成应用程序的一部分。

Oracle 的性能优化大师 Tom Kyte 曾经被问到 Oracle 中的测量点的开销，他的回答是：测量点至少为性能优化贡献了 10%。大多数应用并不需要每天都运行详细的性能测量，所以实际贡献甚至超过 10%。即使不同一这个观点，应该为应用构建一些可以永久使用的轻量级的性能剖析也是有意义的。如果系统没有每天变化的性能统计，则碰到无法提前预知的性能瓶颈就是一件头疼的事情。发现问题的时候，如果有历史数据，这些历史数据价值是无限的。而且性能数据还可以帮助规划好硬件采购、资源分配、以及预测周期性的性能尖峰。

何为轻量级的性能剖析？比如可以为所有 SQL 语句计时，加上脚本总时间统计，这样做的代价不高，而且不需要在每次页面查看（page view）时都执行。如果流量趋势比较稳定，随机采样也可以，随机采样可以通过在应用程序中设置实现，来帮助定位一些严重的问题。这种策略在生产环境中尤其有用，可以发现一些其他方法无法发现的问题。