PHPer都应该关注的服务端性能问题

很早就在用国外的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的成熟水平 但是基本已经可以使用了。这两天抽时间总结了一下测试的过程和使用感受。针对的PHP APM产品的测试 我主要关心的是功能、性能和稳定性 所以一共做了3个方面的测试：

• 1.功能测试主要是测试系统报表的功能以及支持的框架及后端服务

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

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

一、功能测试

这个阶段的测试主要是测试Server的PHP探针都提供了哪些功能模块 以及对PHP应用及其后端架构的支持程度。

测试环境：

为了比较全面地测试Server APM产品的功能 专门搭建了一个比较典型的PHP应用WordPress 并安装了一些第三方插件和后端服务来模拟我在生产环境中用到的一些其他服务。测试环境的应用架构拓扑图和组件列表如下：

测试环境中 应用服务器和MySQL数据库服务安装在同一台服务上 其他三个NoSQL服务分别安装在内网测试环境的其他机器上。使用单独的一台Linux服务器来模拟客户端访问网站和应用 在后续的性能测试中 为了减少网络环境和其他服务对数据准确性的影响 在应用服务器和测试机上单独加了两块网卡并使用网线直连 使用独立的IP地址段192.168.4.x。

测试流程：

1、在应用服务器上安装了Server PHP探针 从客户端测试机上使用wget爬虫模式对整个网站进行模拟用户的点击访问 客户端保持访问1个小时后 从各自的报表平台中对比数据和功能。

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

3、由于第一个测试是做功能性的测试 不考虑网络性能的影响 因此使用的是192.168.2.x网段地址来进行模拟访问。测试中 为了模拟应用出现的性能问题 还对MySQL数据库做了一些人为的处理 来增加其查询的时间 从而降低应用性能。

测试结果输出：

1.功能模块

Server提供的报表功能模块与New Relic的APM比较类似 对于New Relic的老用户来说 非常容易上手。

2.性能指标

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

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

3.应用性能分解

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

4.拓扑图功能

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

5.事务性能分析功能

对应用中每个事务的性能分析来看 Server提供了事务列表和一系列性能图表。

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请求信息和请求参数等等 在国内应该是做的最好的。

8.参数设置

关于监测探针的设置 例如前面提到的ApdexT值的设置 Server提供了比较完善的功能 包括ApdexT值、各种追踪动作的阈值、采集参数选项、参数和SQL语句混淆等多个设置项。并且所有的设置项都可以在线设置完成并自动在指定的应用探针上生效 无需重启应用服务器。

参数和SQL语句的混淆功能非常重要 而SQL语句和页面表单中的一些敏感字段 例如用户名和密码等等 都是必须进行混淆才能传出去的 否则会对应用的安全带来比较大的隐患。而对trace数据（例如慢SQL查询 慢事务）的采集 可以设置当查询多慢之后再做trace数据的采集 以避免采集过多的trace数据。

Server提供了比较完善的配置文件设置和线上参数设置功能 特别是线上修改参数设置无需重启应用服务器的功能 还是非常有用的。

二、性能测试

对于APM产品特别是这种探针模式的APM产品是否成熟 除了功能之外 我最关心的就是对性能的影响。因为引入应用探针本来就是为了解决应用的性能问题 如果因为探针而导致应用性能下降太厉害 那就得不偿失了。早期有一些传统的APM产品 就是由于性能下降太厉害只能在测试环境中使用而无法在线上生产环境中使用。所以针对这个问题我专门设计了一个测试 来测试应用安装和未安装探针时的响应速度 从而评估探针对应用性能的影响程度。

测试流程：

测试同样是在客户端测试机上模拟用户的请求来看应用的响应速度 本次测试是对文章二（即只有MySQL访问的文章）进行模拟访问的测试。并且 为了减少网络对测试结果的影响 这次测试使用了直连网口IP来进行测试 并且进行大样本量大访问测试来得到更精确的统计结果。测试工具使用简单但是功能强大的ab（Apache Benchmark）来完成 两次测试分别是在不安装探针、安装探针的应用环境下完成的 每次测试都使用ab对测试目标URL进行1万次访问 并发数为10。每次测试前都重启被测试的应用服务器。使用以下命令进行测试：

测试结果：

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

性能测试结果汇总：

从测试结果来看 Server的探针会带来105毫秒的性能下降。对应用性能的影响在可接受的范围之内。

三、稳定性测试

稳定性应该是APM产品最基本的要求了 首先不能因为安装了应用探针影响应用的稳定性 其次对产品本身包括探针和报表必须稳定 可以不间断提供持续的服务。稳定性的测试需要长时间复杂的应用环境来进行测试 由于没有这么多时间来折腾 我只使用测试一的功能测试方法做了一天的连续测试。测试结果如下：Server的产品在测试期间始终正常采集并展示数据

从测试的结果来看 Server的探针和报表都比较稳定 在一天的持续测试中 始终正常工作并且在报表上数据展示也是连续的。

四、结论

尝试在生产环境中找几个应用节点部署试试