工作了一兩年的 PHPer 大概都多多少少知道一些性能分析的工具，比如 Xdebug、xhprof、New Relic 、OneAPM。使用基于 Xdebug 進(jìn)行 PHP 的性能分析，對于本地開發(fā)環(huán)境來說是夠用了，但如果是線上環(huán)境的話，xdebug 消耗較大，配置也不夠靈活。相比 Xdebug ，xhprof 性能消耗較小，但是 xhprof 注入代碼后我們還需要實現(xiàn)保存 xhprof 數(shù)據(jù)以及展示數(shù)據(jù)的 UI，聽起來似乎又是一大堆工作。

很多人都知道，New Relic 和 OneAPM 是兩款類似的性能分析工具，通過簡單的安裝之后，就有現(xiàn)成的圖表和分析數(shù)據(jù)可用。前一段時間嘗試過線上使用 New Relic ，估計是因為墻的原因，造成了 php-fpm 進(jìn)程阻塞，具體表現(xiàn)為 netstat 中 php-fpm 開啟的端口始終不回收，墻內(nèi)環(huán)境使用墻外服務(wù)器很難保證服務(wù)的穩(wěn)定性，所以今天主要介紹一下國內(nèi)這款 OneAPM PHP性能分析產(chǎn)品。

PHP Agent 的安裝與簡易用法

注冊賬戶后， OneAPM 會提供一個 License Key，下載 PHP Agent 之后，執(zhí)行安裝腳本：

1. 解壓 Agent 安裝包

tar -xzf OneAPM_php_Agent_latest.tar.gz

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

cd oneapm-php5-linux-install-script

3. 執(zhí)行安裝腳本

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

如果提示未找到 PHP 路徑或安裝失敗，執(zhí)行下面這條一鍵安裝命令：

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

根據(jù)服務(wù)器 PHP 環(huán)境修改上面命令中 PHP 路徑、php.ini 路徑和授權(quán)碼，修改后執(zhí)行這一鍵安裝命令。

等待安裝腳本執(zhí)行。若出現(xiàn)以下信息，則安裝成功。

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 發(fā)送的數(shù)據(jù)。

php1

PHP 性能追蹤及分析

總覽

Dashboard 中查看到具體某個時間段整個系統(tǒng)的穩(wěn)定程度，我們在圖上看到了一個異常波峰，時間在早上6點左右，通過列表篩選器移除 WEB External 后看圖。其他業(yè)務(wù)都很正常，執(zhí)行到最后 PHP 層，平均時間也只用了 10ms 左右?；氐缴蠄D點擊波峰的指示器可以看到具體明細(xì)。

應(yīng)用吞吐量：是指應(yīng)用程序每分鐘被調(diào)用的次數(shù)（cpm，即 Calls Per Minute），吞吐量可以反映應(yīng)用系統(tǒng)對于用戶請求的響應(yīng)能力。

響應(yīng)時間圖主要由 4 部分組成：

• Web 事務(wù)：應(yīng)用中 Web 事務(wù)的響 應(yīng)時間;
• Database：應(yīng)用中 SQL 語句的響應(yīng)時間;
• WEB External ：HTTP 請求第三方服務(wù)調(diào)用;
• 后臺任務(wù)：代表應(yīng)用中 后臺任務(wù)的執(zhí)行時間;

php2

外部服務(wù) WEB External

WEB External 外部服務(wù)，是指應(yīng)用在運行時所調(diào)用的其他外部應(yīng)用提供的服務(wù)，通常由第三方通過 API 提供，使調(diào)用者可以使用第三方提供的相應(yīng)服務(wù)。

剛才我們在總覽頁面發(fā)現(xiàn) WEB External 耗時很多，當(dāng)打開詳情時可以明顯看到，原來是微信的接口在6點鐘抽了。同樣該頁面還可以監(jiān)控到第三方服務(wù)調(diào)用的響應(yīng)情況。比如 217ms 的 api.hitokoto.us 服務(wù)。

php3

SQL 緩慢的監(jiān)控

OneAPM 數(shù)據(jù)庫功能可以選擇數(shù)據(jù)庫類型，包括“All、Database、選擇 Database，則展示數(shù)據(jù)庫的相關(guān)信息，同時會增加展示“增、 刪、改、查”4 類 SQL 語句的響應(yīng)時間和吞吐量圖;Database、MongoDB、Redis、Memcache(d)”5 項。SQL 語句欄可以按照“總響應(yīng)時間從長到短”、“平均響應(yīng)時間從長到短”、“吞吐量從高到低”來進(jìn)行排序。

舉例：通過 Web 事務(wù)的響應(yīng)時間占比查看到一個腳本執(zhí)行時間相對過長，通過下圖可以看到數(shù)據(jù)庫查詢占了579ms。通過切換到詳情頁面，可以看到整個腳本的調(diào)用過程，最終發(fā)現(xiàn)是程序 mysqli.php:88 行執(zhí)行的查詢占用了過長的時間。

php4

php5

以上只是通過 OneAPM 持續(xù)檢查程序穩(wěn)定性的一個基本方法。

程序在日常運行中由于受到的訪問量不同，很有可能在某個時間點上出現(xiàn)大面積的延遲，比如并發(fā)突然增高或訪問某一部分接口的比例突然過高，而平時 Apdex 指標(biāo)卻看起來非常漂亮，那么這個時候通過 OneAPM 就很容易發(fā)現(xiàn)程序中影響性能的部分，從而繼續(xù)改進(jìn)或優(yōu)化代碼。

性能實戰(zhàn)：Wordpress 怎么分析性能瓶頸？

起因是這樣子的，朋友有個國外的網(wǎng)站(針對外國人)，最近網(wǎng)站掛掉了，就幫忙各種修復(fù)了。
但是我本地測試了下網(wǎng)頁訪問非常慢，其實在我給搞之前也一直如此。。

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

內(nèi)存，各種都正常，MySQL 慢查詢也看了沒問題。。

php6

后來終于通過 OneAPM 發(fā)現(xiàn)，主要原因在于： wp 使用的主題有個會檢查主題最新更新事件，判斷依據(jù)就是，$now-$last 如果大于 6 個小時，就去主題官網(wǎng)檢查下更新，而 $last 打印出來居然是 2014 的，主題已經(jīng) N 久沒更新了。。。所以每次請求都會有檢查，好像他們主題網(wǎng)站已經(jīng)跪掉了，所以每次檢查需要 10 秒鐘。。。

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

有圖為證：

php7

本文已經(jīng)征得原作者同意，授權(quán)在 OneAPM 官方技術(shù)博客發(fā)布。想閱讀更多技術(shù)文章，可以點擊這里！
本文轉(zhuǎn)自 OneAPM 官方博客