工作了一两年的 PHPer 大概都多多少少知道一些性能分析的工具，比如 Xdebug、xhprof、New Relic 、OneAPM。使用基于 Xdebug 进行 PHP 的性能分析，对于本地开发环境来说是够用了，但如果是线上环境的话，xdebug 消耗较大，配置也不够灵活。相比 Xdebug ，xhprof 性能消耗较小，但是 xhprof 注入代码后我们还需要实现保存 xhprof 数据以及展示数据的 UI，听起来似乎又是一大堆工作。
很多人都知道，New Relic 和 OneAPM 是两款类似的性能分析工具，通过简单的安装之后，就有现成的图表和分析数据可用。前一段时间尝试过线上使用 New Relic ，估计是因为墙的原因，造成了 php-fpm 进程阻塞，具体表现为 netstat 中 php-fpm 开启的端口始终不回收，墙内环境使用墙外服务器很难保证服务的稳定性，所以今天主要介绍一下国内这款 OneAPM PHP性能分析产品。
PHP Agent 的安装与简易用法
注册账户后， OneAPM 会提供一个 License Key，下载 PHP Agent 之后，执行安装脚本：
1. 解压 Agent 安装包
tar -xzf OneAPM_php_Agent_latest.tar.gz
2.定位至「安装包所在路径」
cd oneapm-php5-linux-install-script
3. 执行安装脚本
sudo ./oneapm-install install --license=BQ4NSVlMX399eAhNWUdfVE790d1
如果提示未找到 PHP 路径或安装失败，执行下面这条一键安装命令：
sudo ./oneapm-install install --php-path=/usr/local/php5/bin --php-ini-file=/usr/local/php5/etc/php.ini --license=BQ4NSVlMX399eAhNWUdfVE790d1
根据服务器 PHP 环境修改上面命令中 PHP 路径、php.ini 路径和授权码，修改后执行这一键安装命令。
等待安装脚本执行。若出现以下信息，则安装成功。
OneAPM is now installed on your system. Congratulations! Restart your web server or servers. Any question join qq group:321095806 or contact http://support.oneapm.com
安装完成之后，重启 Apache 或 php-fpm。然后，稍等片刻，等待 OneAPM 接收 Agent 发送的数据。
PHP 性能追踪及分析
总览
Dashboard 中查看到具体某个时间段整个系统的稳定程度，我们在图上看到了一个异常波峰，时间在早上6点左右，通过列表筛选器移除 WEB External 后看图。其他业务都很正常，执行到最后 PHP 层，平均时间也只用了 10ms 左右。回到上图点击波峰的指示器可以看到具体明细。
应用吞吐量：是指应用程序每分钟被调用的次数（cpm，即 Calls Per Minute），吞吐量可以反映应用系统对于用户请求的响应能力。
响应时间图主要由 4 部分组成：
- Web 事务：应用中 Web 事务的响 应时间;
- Database：应用中 SQL 语句的响应时间;
- WEB External ：HTTP 请求第三方服务调用;
- 后台任务：代表应用中 后台任务的执行时间;
外部服务 WEB External
WEB External 外部服务，是指应用在运行时所调用的其他外部应用提供的服务，通常由第三方通过 API 提供，使调用者可以使用第三方提供的相应服务。
刚才我们在总览页面发现 WEB External 耗时很多，当打开详情时可以明显看到，原来是微信的接口在6点钟抽了。同样该页面还可以监控到第三方服务调用的响应情况。比如 217ms 的 api.hitokoto.us 服务。
SQL 缓慢的监控
OneAPM 数据库功能可以选择数据库类型，包括“All、Database、选择 Database，则展示数据库的相关信息，同时会增加展示“增、 删、改、查”4 类 SQL 语句的响应时间和吞吐量图;Database、MongoDB、Redis、Memcache(d)”5 项。SQL 语句栏可以按照“总响应时间从长到短”、“平均响应时间从长到短”、“吞吐量从高到低”来进行排序。
举例：通过 Web 事务的响应时间占比查看到一个脚本执行时间相对过长，通过下图可以看到数据库查询占了579ms。通过切换到详情页面，可以看到整个脚本的调用过程，最终发现是程序 mysqli.php:88 行执行的查询占用了过长的时间。
以上只是通过 OneAPM 持续检查程序稳定性的一个基本方法。
程序在日常运行中由于受到的访问量不同，很有可能在某个时间点上出现大面积的延迟，比如并发突然增高或访问某一部分接口的比例突然过高，而平时 Apdex 指标却看起来非常漂亮，那么这个时候通过 OneAPM 就很容易发现程序中影响性能的部分，从而继续改进或优化代码。
性能实战：Wordpress 怎么分析性能瓶颈？
起因是这样子的，朋友有个国外的网站(针对外国人)，最近网站挂掉了，就帮忙各种修复了。
但是我本地测试了下网页访问非常慢，其实在我给搞之前也一直如此。。
如下图，第一个请求异常的慢。这个是 contact-us 页面的访问，不涉及太多 sql 查询，也没啥图片。
我点了几个页面都是第一个请求异常的慢 (>10s).
内存，各种都正常，MySQL 慢查询也看了没问题。。
后来终于通过 OneAPM 发现，主要原因在于： wp 使用的主题有个会检查主题最新更新事件，判断依据就是，$now-$last 如果大于 6 个小时，就去主题官网检查下更新，而 $last 打印出来居然是 2014 的，主题已经 N 久没更新了。。。所以每次请求都会有检查，好像他们主题网站已经跪掉了，所以每次检查需要 10 秒钟。。。
去掉之后，第一个请求时间瞬间从十几秒二十秒降到 1 秒了，除了首页，其他页面算是秒开了~~
有图为证：
本文已经征得原作者同意，授权在 OneAPM 官方技术博客发布。想阅读更多技术文章，可以点击这里！
本文转自 OneAPM 官方博客