性能分析本身会影响系统性能

性能分析和常规的监控都会增加系统开销。问题是，它们会增加多少开销，以及由此获得的收益是否值得这种开销。

大多数用户在设计和搭建高性能应用时，认为应该测试所有能够测试的内容，但只接受这种只会增加系统部分开销观点。即便用户难以认同，在应用系统中配置一些永久性的轻量级的性能分析功能，也是非常值得的。如果仅仅因为搭建的系统不能捕捉每天的性能变化，而产生性能瓶颈，就非常让人不快了。同样，如果想要发现性能问题，历史数据的作用就是无价的。另外，性能分析数据也可以有助于硬件采购配置资源、预测峰值时间、峰值季节负载。

什么是所谓的“轻量级”性能分析？为所有SQL查询计时，附加上测量脚本的总体执行时间，在系统开销上并不昂贵，并且不必为所有页面的浏览做如此设置。如果确保拥有足够的流量值，只在应用设置文件（Setup File）中允许性能分析功能，就可以对一个随机样本进行性能分析。

<?php$profiling_enabled = rand(0, 100) > 99;?>

只对页面的1%浏览量进行性能分析，就可以有助于发现最严重的问题。

在运行基准测试时，要确保日志记录、性能分析和性能测量所占的开销被分别评估，否则它会影响基准测试结果的准确性。

如何判断性能瓶颈是否来自未进行性能分析的系统的某个部分？有一个很简单的办法——检查“丢失时间（Lost Time）”。一般来说，挂钟时间（Wtime）是用户时间（User Time）、系统时间（System Time）、SQL查询时间，其他可测量的时间，加上”丢失时间“的总和，”丢失时间“是无法测量的。当然，这里时间分类有些重叠，比如PHP代码处理SQL查询战胜的CPU时间，但这通常是可忽略的。

理想状态下，”丢失时间“越小越好。如果挂钟时间减去的有被测量的时间，还有很大的剩余，那么这种剩余可能是脚本执行增加的时间，也可能是产生页面增加的时间，或者是某个步骤产生的时延（假定Web服务器能缓冲结果，这样脚本就会自动结束，发送到客户端所消耗的时间也不会被计算）。

有两种类型等待：在队列中等待获得CPU处理时间，或者等待某些资源。一个进程运行前会在队列中等待，便可能所有CPU都在忙。通常来说，不太可能诸邮一个进程在CPU等待队列要花多长时间，便这不是个问题。更多的发问是可能在处理外部资源调用，而无法进行性能分析。

如果性能分析是非常完整的，应该很容易发现性能瓶颈的在。一般来说这非常直观：如果脚本执行时间大多是CPU战胜时间，那么可能需要检查和优化PHP代码。不过有时某些测量值也会影响其他测量值。

例如，表面看CPU战胜率非常高，但在某种bug，如缓存（Cache）系统效率低下，而导致应用必须做更多的SQL查询，耗费了很多CPU时间。