如何使用工具進行線上 PHP 性能追蹤及分析？

工做了一兩年的 PHPer 大概都多多少少知道一些性能分析的工具，好比 Xdebug、xhprof、New Relic 、OneAPM。使用基於 Xdebug 進行 PHP 的性能分析，對於本地開發環境來講是夠用了，但若是是線上環境的話，xdebug 消耗較大，配置也不夠靈活。相比 Xdebug ，xhprof 性能消耗較小，可是 xhprof 注入代碼後咱們還須要實現保存 xhprof 數據以及展現數據的 UI，聽起來彷佛又是一大堆工做。

不少人都知道，New Relic 和 OneAPM 是兩款相似的性能分析工具，經過簡單的安裝以後，就有現成的圖表和分析數據可用。前一段時間嘗試過線上使用 New Relic ，估計是由於牆的緣由，形成了 php-fpm 進程阻塞，具體表現爲 netstat 中 php-fpm 開啓的端口始終不回收，牆內環境使用牆外服務器很難保證服務的穩定性，因此今天主要介紹一下國內這款 OneAPM PHP性能分析產品。

##PHP Agent 的安裝與簡易用法 註冊帳戶後， OneAPM 會提供一個 License Key，下載 PHP Agent 以後，執行安裝腳本：

####1. 解壓 Agent 安裝包

tar -xzf OneAPM_php_Agent_latest.tar.gz

2.定位至「安裝包所在路徑」

cd oneapm-php5-linux-install-script

3. 執行安裝腳本

sudo ./oneapm-install install --license=BQ4NSVlMX399eAhNWUdfVE790d1

若是提示未找到 PHP 路徑或安裝失敗，執行下面這條一鍵安裝命令：

sudo ./oneapm-install install --php-path=/usr/local/php5/bin --php-ini-file=/usr/local/php5/etc/php.ini --license=BQ4NSVlMX399eAhNWUdfVE790d1

根據服務器 PHP 環境修改上面命令中 PHP 路徑、php.ini 路徑和受權碼，修改後執行這一鍵安裝命令。

等待安裝腳本執行。若出現如下信息，則安裝成功。

OneAPM is now installed on your system. Congratulations! Restart your web server or servers. Any question join qq group:321095806 or contact http://support.oneapm.com

安裝完成以後，重啓 Apache 或 php-fpm。而後，稍等片刻，等待 OneAPM 接收 Agent 發送的數據。

PHP 性能追蹤及分析

總覽

Dashboard 中查看到具體某個時間段整個系統的穩定程度，咱們在圖上看到了一個異常波峯，時間在早上6點左右，經過列表篩選器移除 WEB External 後看圖。其餘業務都很正常，執行到最後 PHP 層，平均時間也只用了 10ms 左右。回到上圖點擊波峯的指示器能夠看到具體明細。

應用吞吐量：是指應用程序每分鐘被調用的次數（cpm，即 Calls Per Minute），吞吐量能夠反映應用系統對於用戶請求的響應能力。

響應時間圖主要由 4 部分組成：

• Web 事務：應用中 Web 事務的響 應時間;
• Database：應用中 SQL 語句的響應時間;
• WEB External ：HTTP 請求第三方服務調用;
• 後臺任務：表明應用中 後臺任務的執行時間;

外部服務 WEB External

WEB External 外部服務，是指應用在運行時所調用的其餘外部應用提供的服務，一般由第三方經過 API 提供，使調用者可使用第三方提供的相應服務。

剛纔咱們在總覽頁面發現 WEB External 耗時不少，當打開詳情時能夠明顯看到，原來是微信的接口在6點鐘抽了。一樣該頁面還能夠監控到第三方服務調用的響應狀況。好比 217ms 的 api.hitokoto.us 服務。

SQL 緩慢的監控

OneAPM 數據庫功能能夠選擇數據庫類型，包括「All、Database、選擇 Database，則展現數據庫的相關信息，同時會增長展現「增、 刪、改、查」4 類 SQL 語句的響應時間和吞吐量圖;Database、MongoDB、Redis、Memcache(d)」5 項。SQL 語句欄能夠按照「總響應時間從長到短」、「平均響應時間從長到短」、「吞吐量從高到低」來進行排序。

舉例：經過 Web 事務的響應時間佔比查看到一個腳本執行時間相對過長，經過下圖能夠看到數據庫查詢佔了579ms。經過切換到詳情頁面，能夠看到整個腳本的調用過程，最終發現是程序 mysqli.php:88 行執行的查詢佔用了過長的時間。

以上只是經過 OneAPM 持續檢查程序穩定性的一個基本方法。

程序在平常運行中因爲受到的訪問量不一樣，頗有可能在某個時間點上出現大面積的延遲，好比並發忽然增高或訪問某一部分接口的比例忽然太高，而平時 Apdex 指標卻看起來很是漂亮，那麼這個時候經過 OneAPM 就很容易發現程序中影響性能的部分，從而繼續改進或優化代碼。

##性能實戰：Wordpress 怎麼分析性能瓶頸？

原由是這樣子的，朋友有個國外的網站(針對外國人)，最近網站掛掉了，就幫忙各類修復了。 可是我本地測試了下網頁訪問很是慢，其實在我給搞以前也一直如此。。

以下圖，第一個請求異常的慢。這個是 contact-us 頁面的訪問，不涉及太多 sql 查詢，也沒啥圖片。 我點了幾個頁面都是第一個請求異常的慢 (>10s).

內存，各類都正常，MySQL 慢查詢也看了沒問題。。

後來終於經過 OneAPM 發現，主要緣由在於： wp 使用的主題有個會檢查主題最新更新事件，判斷依據就是，$now-$last 若是大於 6 個小時，就去主題官網檢查下更新，而 $last 打印出來竟然是 2014 的，主題已經 N 久沒更新了。。。因此每次請求都會有檢查，好像他們主題網站已經跪掉了，因此每次檢查須要 10 秒鐘。。。

去掉以後，第一個請求時間瞬間從十幾秒二十秒降到 1 秒了，除了首頁，其餘頁面算是秒開了~~

有圖爲證：

本文已經徵得原做者贊成，受權在 OneAPM 官方技術博客發佈。想閱讀更多技術文章，能夠點擊這裏！ 本文轉自 OneAPM 官方博客