标签：
感谢@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性能分析功能模块
听云的 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值，其他的选项只能在配置文件中修改，配置文件中说明比较详细，但是同样的问题是修改完需要重启服务，实用性略显不足。
听云的应用设置项，可以修改的参数和阈值最多最全，同时提供配置文件和线上设置的功能，设置项有很详细的说明和解释，线上设置无需重启服务即可生效，可以随时调整，易用性非常好。
原创文章，转载请标明出处！
PHP APM对比评测：OneAPM, New Relic, 听云
标签：
原文地址：http://my.oschina.net/phpfans15/blog/394888
