PHPer都应该关注的服务端性能问题--听云Server试用笔记 推荐

很早就在用国外的NewRelic（http://www.newrelic.com/）的APM产品来监测自己网站的PHP应用性能了。无奈国外的服务从国内访问起来实在是太慢了，虽然New Relic已经上市了，但是这访问慢的问题却是一直没见好转，反而越来越严重。可能是GFW时不时抽风所致，有时候还得翻墙才能访问New Relic的报表。虽说翻墙是码农们必备的技能，但是为了看个报表查个故障都要翻墙的话实在太麻烦了。 最近非常意外地发现国内也有提供和New Relic类似服务的厂商了。听云（http://www.tingyun.com/），国内老牌的网络性能监测厂商基调网络提供的APM Saas服务，也是2014年底开始公测他们针对PHP的性能管理产品听云Server。非常幸运地拿到了听云Server的试用帐号，这周在自己的测试环境里测试了一下，感觉还不错，虽然暂时还达不到国外New Relic的成熟水平，但是基本已经可以使用了。这两天抽时间总结了一下测试的过程和使用感受。 另外在OSChina上看到听云Server的QQ交流群：332097173 ，闲话少说，我们开始。 针对听云的PHP APM产品的测试，我主要关心的是功能、性能和稳定性，所以一共做了3个方面的测试。
功能测试主要是测试系统报表的功能以及支持的框架及后端服务

性能测试主要关注的是部署和不部署APM探针时对应用性能的影响

稳定性主要看探针会不会给应用引入不稳定的因素和数据采集报表展现的可用性

一、功能测试 这个阶段的测试主要是测试听云Server的PHP 探针都提供了哪些功能模块，以及对PHP应用及其后端架构的支持程度。测试环境：为了比较全面地测试听云Server APM产品的功能，专门搭建了一个比较典型的PHP应用WordPress，并安装了一些第三方插件和后端服务来模拟我在生产环境中用到的一些其他服务。测试环境的应用架构拓扑图和组件列表如下：

组件类型	名称	版本	备注
操作系统	CentOS	6.5
PHP	PHP	5.3.3	安装了以下扩展： mongo 1.4.4 memcache 3.0.5 mysql 5.1.73 redis 2.2.5
Web服务器	Apache httpd	2.2.15	使用mod_php
主应用	WordPress	4.0.1中文版
WordPress插件	Disable Google Fonts	1.1	为了去掉被墙掉的google fonts的引用
WordPress插件	Exec-PHP	4.9	可以直接在页面和文章里写PHP代码
数据库	MySQL	5.1.73	WordPress主数据库
NoSQL	MongoDB	2.2.5
NoSQL	Memcached	1.4.6
NoSQL	Redis
文章一	普通文章：TEST Article	/?p=4	这个文章的内容存在数据库里，访问该文章页面只会产生MySQL的服务访问
文章二	MongoDB测试文章：MongoDB Test Article	/?p=18	该文章直接在文章内容中使用PHP代码从MongoDB中存取数据，访问该文章除了产生MySQL的服务访问之外还会访问MongoDB数据库。
文章三	Redis测试文章：Redis Test Article	/?p=22	该文章直接在文章内容中使用 PHP代码从Redis服务中存取数据，访问该文章除了产生MySQL的访问之外还会访问Redis服务。
文章四	Memcached测试文章：Memcached Test Article	/?p=20	该文章直接在文章内容中使用PHP代码调用SimplePie从外部网站订阅RSS，并将内容缓存在Memcached中c。因此访问该文章页面除了MySQL的访问之外，还会产生外部HTTP调用和Memcached访问。
APM探针	听云Server PHP探针	1.0.1	公开测试版本

测试环境配置表和拓扑图 测试环境中，应用服务器和MySQL数据库服务安装在同一台服务上，其他三个NoSQL服务分别安装在内网测试环境的其他机器上。使用单独的一台Linux服务器来模拟客户端访问网站和应用，在后续的性能测试中，为了减少网络环境和其他服务对数据准确性的影响，在应用服务器和测试机上单独加了两块网卡并使用网线直连，使用独立的IP地址段192.168.4.x。测试流程： 1、在应用服务器上安装了听云Server PHP探针，从客户端测试机上使用wget爬虫模式对整个网站进行模拟用户的点击访问，客户端保持访问1个小时后，从各自的报表平台中对比数据和功能。

2、安装完听云PHP探针后在测试之前完成数据库和httpd服务的重启。客户端测试机上运行以下脚本来进行模拟访问：

while true; do wget -r --spider http://192.168.2.30/; rm -rf 192.168.2.30; sleep 1; done

3、由于第一个测试是做功能性的测试，不考虑网络性能的影响，因此使用的是192.168.2.x网段地址来进行模拟访问。测试中，为了模拟应用出现的性能问题，还对MySQL数据库做了一些人为的处理，来增加其查询的时间，从而降低应用性能。测试结果输出： 1.功能模块 听云Server提供的报表功能模块与New Relic的APM比较类似，对于New Relic的老用户来说，非常容易上手。

模块名称	听云
应用列表	概览-应用一览
关键事务	关键应用过程
应用概览	情报汇总
拓扑图	视图
事务	Web应用过程
数据库	数据库
后台任务	后台任务
外部服务	外部应用
错误分析	错误
环境	应用环境变量
设置	设置
报告

2.性能指标 听云报表提供的性能指标主要包括以下的项目：

性能指标	听云
应用响应时间	√
应用吞吐率（单位时间访问量）	√
错误率	√
Apdex	√
SQL性能	√
Memcached性能	√
Redis性能	√
MongoDB性能	√
外部服务性能	√

在性能指标中，听云提供了Apdex指数这个重要的性能指标，想了解这个指数的同学可以移步Apdex组织官网（http://apdex.org/）进行深入的了解。我们知道这个指数最重要的是T值的设置和指数数据展示时必须同时展示T值，从图表上来看，听云缺省的应用T值是0.5秒。


听云Apdex指数图表 3.应用性能分解听云在应用概览中使用了堆叠面积图对应用性能进行了分解展示，并且听云的响应时间分解相对比较完整，基本上覆盖了国外的New Relic APM能提供的所有项目：应用层时间、阻塞时间、数据库调用时间、Redis响应时间、Memcached响应时间、MongoDB响应时间和外部服务时间，一共7项性能指标的分解。


听云响应时间分解图表4.拓扑图功能 听云可以自动识别应用架构并绘制应用的逻辑拓扑图。但是听云Server不支持拖动和点击钻取。只能通过鼠标悬停的方式展示各服务节点的性能趋势图。不过在服务的识别和支持上做得相对比较全，包括Memcached, MongoDB, Redis, SQL数据库和外部服务的主机在内的多个服务节点都可以正常的识别和展示。不过在展示外部服务上有一个bug：外部服务主机名展示错误并且有乱码。


听云应用拓扑图 5.事务性能分析功能 对应用中每个事务的性能分析来看，听云Server提供了事务列表和一系列性能图表。


听云Server的Web应用过程性能分析报表听云Server的Web应用过程钻取性能分解上可以分解到数据库、代码模块、外部服务和NoSQL服务的性能耗时。


听云的Web应用过程分解可以看到代码段、数据库、NoSQL和外部服务调用 听云Server在Web事务分析上提供了trace功能，对特别慢的Web事务保留详细的trace数据，数据里会包括代码模块的耗时统计，代码运行的流程和耗时，HTTP参数和请求过程中调用的SQL语句等等。

听云Server的Web过程追踪分析展示的代码运行过程数据很详细。例如遇到对数据库访问的代码段性能慢的时候，会在对应的代码段上同时展示相关的SQL语句和详细到代码行的代码调用堆栈信息，不过追踪详情中暂时没有看到HTTP请求参数的展示。


听云Server的Web过程追踪详情可以展示慢的代码调用堆栈和SQL查询语句6.SQL性能分析功能在SQL性能的分析方面听云Server提供了SQL性能列表和一系列SQL性能、吞吐量的图表来展示SQL语句的性能问题。在列表的排序上，听云Server在提供按平均响应时间和吞吐量的排序的基础上增加了按总耗时和Web过程组合的排序。   对于特别慢的SQL查询，听云Server提供了慢SQL的记录功能。同时，听云Server的慢SQL追踪数据非常全面，除了慢查询详细的SQL语句（还对SQL语句提供了混淆的功能，在后面的参数设置对比中会提到）之外，还提供了慢查询的散点图，执行该SQL语句的应用实例名称，调用者PHP脚本，该语句的执行计划和详细到代码行的代码调用堆栈信息。其中慢SQL查询的散点图非常直观，可以一目了然地发现出现慢查询的时间段和样本的分布情况，而执行计划的分析也让运维人员不需要再去找DBA手工分析SQL语句了，调用堆栈可以让研发人员直接定位慢SQL查询所在的代码行。


听云Server提供的非常详细的慢SQL查询追踪数据7.错误追踪为了测试听云对错误分析的功能和准确性，我特地修改了WordPress上的一个页面，在PHP代码里人为引入了一个语法错误，并在一段时间内让应用的执行时间超过PHP应用的缺省最长执行时间（30s）。下图是听云提供的应用错误率的统计图表和错误日志列表。


听云Server的错误率图表和错误列表听云Server的错误分析还对错误类型进行了分类和排序，列出各种错误类型的占比情况。而且在错误日志的列表中，它也按错误类型将错误日志进行了汇总和排序。对于错误的定义，听云也避免了错误率图表里的错误看起来应该是只计算E_ERROR级别的错误，但是列表中给出的却包含了E_WARNING, E_NOTICE等警告级别的错误信息，造成了图表和列表错误数量的不一致的情况，而这些警告信息其实没那么重要，也是用户不需要太关心的。

听云的ErrorTrace数据中提供了直观的错误发生的散点图、错误URI、错误时间段、应用实例、次数、错误信息、详细到代码行的错误调用堆栈，HTTP请求信息和请求参数等等，在国内应该是做的最好的。


听云Server的错误追踪日志 8.参数设置
关于监测探针的设置，例如前面提到的ApdexT值的设置，听云Server提供了比较完善的功能，包括ApdexT值、各种追踪动作的阈值、采集参数选项、参数和SQL语句混淆等多个设置项。并且所有的设置项都可以在线设置完成并自动在指定的应用探针上生效，无需重启应用服务器。参数和SQL语句的混淆功能非常重要，而SQL语句和页面表单中的一些敏感字段，例如用户名和密码等等，都是必须进行混淆才能传出去的，否则会对应用的安全带来比较大的隐患。而对trace数据（例如慢SQL查询，慢事务）的采集，可以设置当查询多慢之后再做trace数据的采集，以避免采集过多的trace数据。听云Server提供了比较完善的配置文件设置和线上参数设置功能，特别是线上修改参数设置无需重启应用服务器的功能，还是非常有用的。

听云Server的应用设置二、性能测试对于APM产品特别是这种探针模式的APM产品是否成熟，除了功能之外，我最关心的就是对性能的影响。因为引入应用探针本来就是为了解决应用的性能问题，如果因为探针而导致应用性能下降太厉害，那就得不偿失了。早期有一些传统的APM产品，就是由于性能下降太厉害只能在测试环境中使用而无法在线上生产环境中使用。所以针对这个问题我专门设计了一个测试，来测试应用安装和未安装探针时的响应速度，从而评估探针对应用性能的影响程度。测试流程：测试同样是在客户端测试机上模拟用户的请求来看应用的响应速度，本次测试是对文章二（即只有MySQL访问的文章）进行模拟访问的测试。并且，为了减少网络对测试结果的影响，这次测试使用了直连网口IP来进行测试，并且进行大样本量大访问测试来得到更精确的统计结果。测试工具使用简单但是功能强大的ab（Apache Benchmark）来完成，两次测试分别是在不安装探针、安装听云探针的应用环境下完成的，每次测试都使用ab对测试目标URL进行1万次访问，并发数为10。每次测试前都重启被测试的应用服务器。使用以下命令进行测试：

ab -c 10 -n 10000 "http://192.168.4.2/?p=4"

测试结果：最终的测试结果如下，下面分别是不带探针、安装听云探针的测试结果拷屏：

不安装任何探针的测试结果

安装听云Server探针的测试结果性能测试结果汇总

测试环境	平均值 (ms)	影响(ms)	标准差(ms)	中位值(ms)	最小值(ms)	最大值(ms)
不安装探针	1244	-	66.4	1233	781	2531
安装听云探针	1349	105	72.4	1340	789	2813

从测试结果来看，听云Server的探针会带来105毫秒的性能下降。对应用性能的影响在可接受的范围之内。三、稳定性测试稳定性应该是APM产品最基本的要求了，首先不能因为安装了应用探针影响应用的稳定性，其次对产品本身包括探针和报表必须稳定，可以不间断提供持续的服务。稳定性的测试需要长时间复杂的应用环境来进行测试，由于没有这么多时间来折腾，我只使用测试一的功能测试方法做了一天的连续测试。测试结果如下：

听云Server的产品在测试期间始终正常采集并展示数据从测试的结果来看，听云Server的探针和报表都比较稳定，在一天的持续测试中，始终正常工作并且在报表上数据展示也是连续的。四、结论从这几天的测试结果来看，听云目前的产品还比较完善，除了个别小bug之外，基本可以达到在生产环境中使用的水平。后续会尝试在生产环境中找几个应用节点部署试试，听说听云Server已经公测了，大家可以去尝试。