对应用程序进行性能剖析
对任何需要消耗时间的任务都可以做性能剖析当然也包括应用程序实际上剖析应用程序一般比剖析数据库服务器容易而且回报更多虽然前面的演示例子都是针对MySQL 服务器的剖析但对系统进行性能剖析还是建议自上而下地进行这样可以追蹤自用户发起到服务器响应的整个流程虽然性能问题大多数情况下都和数据库有关但应用导致的性能问题也不少性能瓶颈可能有很多影响因素
外部资源比如调用了外部的Web 服务或者搜索引擎
应用需要处理大量的数据比如分析一个超大的XML 文件
在循环中执行昂贵的操作比如滥用正则表达式
使用了低效的算法比如使用暴力搜索算法（nave search algorithms）来查找列表中的项
幸运的是确定MySQL 的问题没有这么复杂只需要一款应用程序的剖析工具即可（作为回报一旦拥有这样的工具就可以从一开始就写出高效的代码）
建议在所有的新项目中都考虑包含性能剖析的代码往已有的项目中加入性能剖析代码也许很困难新项目就简单一些
性能剖析本身会导致服务器变慢吗？
说是的是因为性能剖析确实会导致应用慢一点说不是是因为性能剖析可以帮助应用运行得更快先别急下面就解释一下为什么这么说
性能剖析和定期检测都会带来额外开销问题在于这部分的开销有多少并且由此获得的收益是否能够抵消这些开销
大多数设计和构建过高性能应用程序的人相信应该尽可能地测量一切可以测量的地方并且接受这些测量带来的额外开销这些开销应该被当成应用程序的一部分Oracle 的性能优化大师Tom Kyte 曾被问到Oracle 中的测量点的开销他的回答是测量点至少为性能优化贡献了%对此我们深表赞同而且大多数应用并不需要每天都运行详细的性能测量所以实际贡献甚至要超过%即使不同意这个观点为应用构建一些可以永久使用的轻量级的性能剖析也是有意义的如果系统没有每天变化的性能统计则碰到无法提前预知的性能瓶颈就是一件头痛的事情发现问题的时候如果有历史数据则这些历史数据价值是无限的而且性能数据还可以帮助规划好硬件采购资源分配以及预测周期性的性能尖峰
那么何谓轻量级的性能剖析？比如可以为所有SQL 语句计时加上脚本总时间统计这样做的代价不高而且不需要在每次页面查看（page view）时都执行如果流量趋势比较稳定随机采样也可以随机采样可以通过在应用程序中设置实现
<?php
$profiling_enabled = rand（ ） > ;
?>
这样只有% 的会话会执行性能采样来帮助定位一些严重的问题这种策略在生产环境中尤其有用可以发现一些其他方法无法发现的问题
几年前在写作本书的第二版的时候流行的Web 编程语言和框架中还没有太多现成的性能剖析工具可以用于生产环境所以在书中展示了一段示例代码可以简单而有效地复制使用而到了今天已经有了很多好用的工具要做的只是打开工具箱就可以开始优化性能
首先这里要兜售的一个好工具是一款叫做New Relic 的软件即服务（softwareasaservice）产品声明一下我们不是托我们一般不会推荐某个特定公司或产品但这个工具真的非常棒建议大家都用它我们的客户借助这个工具在没有我们帮助的情况下解决了很多问题即使有时候找不到解决办法但依然能够帮助定位到问题New Relic 会插入到应用程序中进行性能剖析将收集到的数据发送到一个基于Web 的仪表盘使用仪表盘可以更容易利用面向响应时间的方法分析应用性能这样用户只需要考虑做那些正确的事情而不用考虑如何去做而且New Relic 测量了很多用户体验相关的点涵盖从Web 浏览器到应用代码再到数据库及其他外部调用
返回目录高性能MySQL
编辑推荐
ASP NET开发培训视频教程
数据仓库与数据挖掘培训视频教程
Oracle索引技术
