對應用程序進行性能剖析
對任何需要消耗時間的任務都可以做性能剖析當然也包括應用程序實際上剖析應用程序一般比剖析數據庫服務器容易而且回報更多雖然前面的演示例子都是針對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索引技術
From:http://tw.wingwit.com/Article/program/MySQL/201311/29718.html
