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

感谢 @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 值，其他的选项只能在配置文件中修改，配置文件中说明比较详细，但是同样的问题是修改完需要重启服务，实用性略显不足。

听云的应用设置项，可以修改的参数和阈值最多最全，同时提供配置文件和线上设置的功能，设置项有很详细的说明和解释，线上设置无需重启服务即可生效，可以随时调整，易用性非常好。