工作了一两年的 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 官方技术博客发布。想阅读更多技术文章,可以点击这里!