PHP APM對比評測：OneAPM, New Relic, 聽雲

感謝@penguinz 的推薦，又發現了一家提供應用效能管理服務的國內廠商：“聽雲”，看了斯人-吳帥寫的試用筆記，才瞭解到國外的應用效能管理廠商New Relic才是真正APM大牛，產品線覆蓋非常全面，功能也非常強大，不過確實像斯人所說的，訪問太慢了。粗看起來，發現從產品設計到介面上，這三家公司的產品都太像了，很明顯國內兩家公司的產品是在“學習”New Relic的產品，希望兩家國內廠商不只是簡單的拷貝國外的產品，而是能夠做出符合國內使用者需求的產品。

上次寫過一篇OneAPM的評測，關於聽雲的產品測試我就不再多寫了，斯人的部落格已經提供了非常詳細的試用報告，大家可以去看看。http://www.imsiren.com/archives/1192。正好春節之後有點時間，就把3個產品都裝了一遍，分別仔細用了一段時間，來說一下幾個產品的對比感受。

回應時間圖表的對比

看了斯人的試用報告，發現聽雲的產品可以監測NoSQL的訪問效能，因此這次測試在原有WordPress應用的基礎上，增加了幾個PHP指令碼，應用中除了MySQL資料庫之外，還引入了對MongoDB, Redis和Memcached的訪問。從回應時間的對比來看，聽雲支援效能指標是最多的，詳見下表：

響應效能指標	OneAPM	聽雲	New Relic
PHP代碼	支援	支援	支援
RDMS資料庫	支援	支援	支援
Memcache	不支援	支援	支援
外部服務	不支援	支援	支援
Redis	不支援	支援	不支援
MongoDB	不支援	支援	不支援
阻塞時間	不支援	支援	不支援

此外，後面還會說到聽雲針對這些常用的NoSQL資料庫還提供了更深層的分析，而其他兩家的產品只對RDMS關係型資料庫做了深層分析。

OneAPM的回應時間圖，只顯示Web事務和資料庫的效能分解

聽雲的回應時間圖，顯示了包括應用、資料庫、非關係型資料庫等多個組件的效能分解

New Relic回應時間圖，顯示了PHP，Database, Memcache, Web external 4種效能分解

拓撲邏輯圖對比

從拓撲邏輯圖上也可以看出來各家對各類應用後端服務支援的區別，聽雲和New Relic都支援NoSQL資料庫的展示，而OneAPM只有Database服務的展示。OneAPM的拓撲圖可以直接在圖上向下切入到Web事務和資料庫的分解報表，而聽雲和New Relic沒有提供切入功能，只提供了對應服務的響應曲線圖展示。

OneAPM拓撲圖，可拖拽和切入

聽雲拓撲邏輯圖，識別的服務最多，不可拖拽和切入

New Relic Map，識別出部分NoSQL，不可拖拽和切入

事務效能分析對比

OneAPM的事務列表

New Relic的事務列表

聽雲的事務列表

從事務列表中可以看出來，New Relic對WordPress的支援比其他兩家更好，可以根據WordPress收到的不同參數識別成不同的事務名稱來進行匯總統計，而其他兩家只能按URI的方式進行事務的識別和統計。

事務Trace對比

三個產品在事務效能的匯總分析上功能相差不大，主要的差別表現在對慢事務的Trace上。Trace功能會對非常慢的事務訪問保留詳細的診斷資料，包括程式碼片段的耗時情況、程式碼片段執行的詳細步驟和呼叫堆疊，相關的SQL語句等等資訊。對追蹤記錄列表的預設排序，聽雲使用的是回應時間的倒排序，而New Relic和OneAPM使用的都是採集時間戳記倒排序，相比較下來，聽雲的排序方式更加合理，我肯定最優先關注的是最慢的請求。

OneAPM Trace概要

聽雲應用過程追蹤摘要

New Relic Transaction Trace Summary

Trace的概要資訊展示裡，New Relic展示效能組件相對比較簡潔，並且含義明確，非常容易閱讀和粗略定位問題。聽雲的組件展示分解最細，但是由於分解太細的原因，反而不容易閱讀，也不夠簡介。而OneAPM的雖然組件展示得也比較少，但是分解比較亂，完全不知所云。

事務Trace的第二部分Trace詳情展示的是記錄的慢交易處理中代碼的完整執行過程，包括代碼的嵌套調用，代碼堆棧等等。聽雲和New Relic都提供了比較準確易讀的代碼調用詳情和代碼堆棧，OneAPM的詳情中的程式碼片段展示得有問題，有時候會出現非PHP的C代碼，並且沒有提供代碼堆棧的展示。

聽雲的追蹤詳情

New Relic的Trace Detail

OneAPM的Trace詳情

OneAPM的Trace資訊中比其他兩家多了使用者自訂參數部分，應該指的是請求中提交的表單參數吧。其他兩家都只有HTTP頭裡的部分參數資訊。

慢SQL日誌對比

慢SQL日誌的分析類似於MySQL裡的慢查詢日誌（MySQL slow query log），可以記錄查詢時間比較慢的SQL語句。從功能對比上來看，OneAPM只記錄了詳細的SQL語句和查詢時間，而New Relic和聽雲除了記錄查詢時間和SQL語句之外，還會記錄該SQL語句的執行計畫以及調用該SQL語句的應用代碼呼叫堆疊。此外，聽雲還展示了對應SQL語句查詢時間分布的散佈圖，對查看慢SQL記錄更加直觀易用。

聽雲的慢SQL追蹤資料最為詳細，包括散佈圖，SQL語句，查詢時間、執行計畫和代碼呼叫堆疊

New Relic的Slow query trace，包括查詢時間，SQL語句和代碼呼叫堆疊。

OneAPM的慢SQL記錄，只有查詢時間和SQL語句。

NoSQL效能對比

目前在三家的產品中，只有聽雲一家提供了對NoSQL服務效能的分析，聽雲提供了包括MongoDB, Redis和Memcached在內的三個NoSQL服務的分析，可以看到各類操作的回應時間和吞吐率，對MongoDB還可以按Collection查看不同操作的效能。雖然New Relic在前面的回應時間中有Memcached的效能資料，但是沒有單獨提供針對這種NoSQL服務更細緻的分析資料。而OneAPM目前還不支援任何一種NoSQL資料庫效能分析。

聽雲的NoSQL效能分析功能模組

聽雲的 MongoDB 分析

聽雲的 Redis 分析

聽雲的 Memcached 分析

外部服務對比

三家的產品都支援對外部服務（即應用通過Web Service方式調用的外部的API）的效能分析。New Relic和OneAPM的產品會展示各主機的平均響應效能，但是OneAPM的好像存在Bug，導致列表中同一個主機重複出現並且效能值不一致。聽雲的外部服務效能分析除了主機一級的資料之外，還可以向下按該主機下每個不同的URI來匯總效能資料，可以瞭解不同的API介面的效能差異，實用價值更高。

OneAPM的外部服務，展示到主機一級，存在Bug導致同一主機重複出現

New Relic的外部服務，展示到主機一級

聽雲的外部服務，展示到主機和具體的URI一級

背景工作（CLI模式PHP指令碼）效能對比

對於不通過Web方式訪問的PHP指令碼，即命令列模式（CLI）啟動並執行PHP程式，三個產品都是通過背景工作的方式來展示的。目前OneAPM的產品無法提供CLI模式的PHP應用監控，這部分資料是空的。New Relic和聽雲都可以對CLI啟動並執行PHP進行監控，並且都提供了效能分解的功能，可以查看背景工作的效能在程式碼片段的消耗比例。但是New Relic的效能分解有Bug，我啟動並執行指令碼明明是訪問Redis資料庫的，它分解出來卻是Memcache的訪問，如果是這樣，之前幾個圖表中的Memcache效能資料估計也是錯的了...

OneAPM的背景工作資料為空白，無法監測到CLI模式的PHP應用效能

New Relic的背景工作資料，以”Non-Web”的類型來展示CLI模式啟動並執行PHP應用效能

New Relic的背景工作效能分解，可以看到代碼時間和NoSQL服務的操作時間，不過把Redis識別成了Memcached

聽雲的背景工作分析

聽雲的背景工作效能分解，正確識別代碼執行時間和Redis各類操作的效能。

錯誤分析對比

錯誤分析記錄應用中拋出的異常資訊和PHP錯誤碼，計算整個應用的錯誤率。從本次測試結果來看，聽雲和其他兩家的差別比較大，New Relic和OneAPM都記錄了大量的錯誤資訊，大概百分之十幾的錯誤率，而聽雲卻一個錯誤資訊也沒有記錄。

後來仔細看了資料才發現，New Relic和OneAPM記錄的錯誤實際上都是警告層級（E_USER_WARNING）的不嚴重的錯誤，實際上我的測試應用一直正常訪問，並沒有出錯。而聽雲則只記錄錯誤基本的錯誤，所以一條警告層級的錯誤資訊都不會記錄。從實用角度來說，聽雲的的更加合理，因為這些警告層級的錯誤確實是我都不需要關心的，否則我的應用程式錯誤率有這麼高的話，使用者早投訴了。

不過如果可能的話，希望可以提供一個錯誤層級的設定選項，在需要的時候可以選擇採集哪個層級的錯誤記錄檔。

OneAPM的錯誤分析

New Relic的錯誤分析

報告對比

New Relic和OneAPM都提供報告功能，就是用一個匯總表格的形式展示一段時間之內Web事務和SQL效能的對比報告。從測試結果來看，New Relic可以正常提供報告資料，OneAPM的報告功能這次好像無法正常使用，表格式資料始終是空的，上次測試的時候是好的。而聽雲則沒有這個功能模組。

OneAPM的報告，最近好像無法正常使用，表格始終是空的。

New Relic的報告，顯示過去一段時間的效能資料對比

警示設定對比

三個產品都可以對監測的PHP應用進行效能和錯誤率的警報設定，在應用發生效能問題和錯誤率過高的時候發送警報通知使用者。

對比測試中發現OneAPM和New Relic都可以預先設定不同的警示策略，例如警示的閾值和觸發的時間等等策略，然後再把策略分配到需要警示的應用上面，通過策略可以設定比較靈活的警示規則並且容易複製到多個應用上，使用起來比較方便。

而聽雲的警示設定只能對每個應用單獨設定警示閾值，無法設定觸發時間等參數，並且由於沒有策略的分配，無法在多個應用上複製同樣的警示設定，易用性上較差。

OneAPM的警示原則設定可進行閾值和觸發時間等條件設定

New Relic的警示原則設定同樣可進行閾值和觸發時間設定

聽雲的警示設定只能進行閾值設定，並且沒有警報策略的概念

應用設定對比

有許多應用設定項，例如Trace閾值和ApdexT值的設定對監測結果資料影響較大，因此最好能給使用者提供自訂的設定功能。特別是ApdexT值，直接影響到Apdex分數的評估和警報的結果，非常需要可以隨時動態設定。從測試結果來看，聽雲的應用設定項最全最方便，並且可以線上修改並即時生效，不需要重啟應用伺服器。而OneAPM和New Relic在應用設定上功能就沒這麼完整了。

OneAPM的應用設定頁面，實際上沒有可設定的項目，只列出的幾個選項，可能是可以在設定檔中配置，不過沒有相應的說明和解釋。通過修改設定檔的設定項需要重啟應用伺服器才會生效，實用性較差。

New Relic的應用設定項，可以修改應用程式名稱和ApdexT值，其他的選項只能在設定檔中修改，設定檔中說明比較詳細，但是同樣的問題是修改完需要重啟服務，實用性略顯不足。

聽雲的應用設定項，可以修改的參數和閾值最多最全，同時提供設定檔和線上設定的功能，設定項有很詳細的說明和解釋，線上設定無需重啟服務即可生效，可以隨時調整，易用性非常好。

原創文章，轉載請標明出處！

