Heim >Backend-Entwicklung >PHP-Tutorial >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功能会对非常慢的事务访问保留详细的诊断数据,包括代码段的耗时情况、代码段执行的详细步骤和调用堆栈,相关的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日志的分析类似于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服务性能的分析,听云提供了包括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一级
对于不通过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值,其他的选项只能在配置文件中修改,配置文件中说明比较详细,但是同样的问题是修改完需要重启服务,实用性略显不足。
听云的应用设置项,可以修改的参数和阈值最多最全,同时提供配置文件和线上设置的功能,设置项有很详细的说明和解释,线上设置无需重启服务即可生效,可以随时调整,易用性非常好。
原创文章,转载请标明出处!