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的应用设置页面，实际上没有可设置的项目，只列出的几个选项，可能是可以在配置文件中配置，不过没有相应的说明和解释。通过修改配置文件的设置项需要重启应用服务器才能生效，实用性较差。