”听云“ 试用报告

摘要：

一直在寻找一款能线上监控并且提供一定性能优化数据支持的工具，搜索到国内较为出名的是“听云”和“OneApm”，这类工具都属于应用性能管理(Application Performance Management)。 本文将记录在部署测试‘听云’中的一些心得体会。

试用测试大纲：

• 功能测试（听云Server后台的显示和数据的收集功能 ）
• 性能测试（听云探针对探测应用和机器性能的影响）
• 兼容性测试（探针对各平台的支持）
• 稳定性测试（探针运行和数据收集的稳定性）

对于一款迁入式的工具，暂时想到的是要对上面4个大类进行测试，保证此工具的功能时也要注意对被探测应用的性能和稳定性影响如何进行测试。

应用测试环境：

操作系统	Linux
Web服务器	Nginx
数据库	MySQL
缓存数据库	Redis
应用服务器	Node.js

架构就是 Linux + Nginx（反向代理和处理静态文件）+ Node.js （应用服务器） + MySQL + Redis ，正好‘听云’ Node.js 的探针正在公测，和我搭建的服务相匹配。

1. 功能测试

探针的安装和部署官网已经较为清楚，不过个人感觉tingyun目录下的 README.md 更为清晰，截了部分图如下：

（配置项的配置文件是 <app root>/tingyun.json）

成功部署完成后，重启自己的应用，等待五分钟，有请求进来后就会有数据在后台显示了，查看了一下tingyun_agent.log，每分钟会向 https://dcs1.networkbench.com/upload 发送一个POST请求，后台的数据应该就是通过这个请求来传输了。

后台的情报汇总里，一共有7个图表，分别如下：

应用服务器响应时间表，显示的访问量和响应时间挺准确的，我用的测试方法是用Apache Jmeter(性能压测工具，这里不展开介绍)模拟访问此站点，Jmeter里的访问量和响应时间与此处基本一致。

Apdex指标表，可以看到 T值听云设置的是500ms，通过此表可以很直观的看到用户访问的情况

错误率、耗时表和吞吐率表如上图，吞吐率表中的rpm与平常说的QPS不一样，rpm的单位是分钟，QPS的单位是秒。

CPU和内存表格如上图所示。内存基本和真实情况一致，CPU的使用情况和在机器上top命令查看到的有差别，不知道问题是出在那儿。

2. 性能测试

与听云客服沟通，客服MM说大概会吃2%的机器性能，能不能信就要靠数据说话了，我准备用Apache Jmeter对站点分别在部署了听云探针和未部署的情况下进行10000次的访问，期间收集机器性能，进行数据对比。

续见下文