歡迎來到Linux教程網
Linux教程網
Linux教程網
Linux教程網
Linux教程網 >> Linux基礎 >> Linux教程 >> PHP APM對比評測:OneAPM, New Relic, 聽雲

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

日期:2017/2/27 15:53:55   编辑:Linux教程

上次寫過一篇OneAPM的評測:http://www.linuxeye.com/Linux/2358.html

響應時間圖表的對比

看了斯人的試用報告,發現聽雲的產品可以監測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概要

聽雲應用過程追蹤摘要

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

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

聽雲的追蹤詳情

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值,其他的選項只能在配置文件中修改,配置文件中說明比較詳細,但是同樣的問題是修改完需要重啟服務,實用性略顯不足。

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

原文:http://my.oschina.net/phpfans15/blog/394888

Copyright © Linux教程網 All Rights Reserved