[TOC] ### 性能优化简介 #### 性能优化 1. CPU利用率不要时很好的可度量单位 2. 性能是响应时间 3. 先需要精确的测量，而不是直接去修改一些东西 4. 测出的时间花在哪里，知道为什么花在那里 5. 合适的测量范围 6. 不合适的测量 ``` 在错误的时间启动和停止测量 测量的是聚合后的信息，而不是目标活动本身 ``` 完成一项任务所需要的时间： * 执行时间 * 等待时间 #### 通过性能剖析进行优化 一旦掌握并实践面向相应时间的优化方法，就会发现需要不断的对系统进行性能剖析 1. 测量任务所花费的时间 2. 对结果进行统计和排序，将重要的任务放在前面 性能剖析工具的工作方式基本相同 ``` 在任务开始时启动计时器，在任务结束时停止计时器,然后用结束时间减去启动时间得到响应时间。 ``` #### 两种类型的性能分析 基于执行时间的分析 基于等待的时间分析 ##### Performance Schema MySQL5.5第一次提供来Performance Schema，其中有一些基于时间的测量点。 Percona Server5.0 慢查询日志揭露来一些性能地下的原因： ``` 磁盘I/O等待 行级锁等待 ``` #### 理解性能剖析 * 值得优化的查询 ``` 性能剖析不会自动给出哪些查询值得花时间去优化。 1. 一些只总响应时间比重很小的查询是不值得优化的，根据阿姆达尔定律，对一个占总响应时间不超过5%的查询进行优化，无论如何努力，收益也不会超过5%。 2. 如果花费1000美元去优化一个任务，但业务但收入没有任何增加，那么可以说反而导致业务被逆优化来1000美元。如果优化但成本大雨收益，就应该停止优化。 ``` * 异常情况 * 被掩藏的细节 ``` 性能剖析无法显示所有响应时间的分布，只相信平均值是非常危险的。 医院所有病人的平均体温没有任何价值。 ``` ### 对应用程序进行性能剖析 #### 工具`New Relic` #### 测量php应用程序 1. xhprof 2. IfP ``` requeire_once('Instrumentation.php') Instrumentation::get_instance() ```