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值，其餘的選項只能在配置文件中修改，配置文件中說明比較詳細，可是一樣的問題是修改完須要重啓服務，實用性略顯不足。

聽雲的應用設置項，能夠修改的參數和閾值最多最全，同時提供配置文件和線上設置的功能，設置項有很詳細的說明和解釋，線上設置無需重啓服務便可生效，能夠隨時調整，易用性很是好。

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