[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() ```