记一次 PHP 并发性能调优实战 -- 性能提升 104%

适合阅读人群

文中的调优思路无论是 php, java, 还是其他任何语言都是用. 如果你有 php 使用经验, 那肯定就更好了

业务背景

框架及相应环境

1. laravel5.7, mysql5.7, redis5, nginx1.15

2. centos 7.5 bbr

3. docker, docker-compose

4. 阿里云 4C和8G

问题背景

php 已经开启 opcache, laravel 也运行了 optimize 命令进行优化, composer 也进行过 dump-autoload 命令.

首先需要声明的是, 系统的环境中是一定有小问题的(没有问题也不可能能够提升如此大的性能), 但是这些问题, 如果不通过使用合适的工具, 可能一辈子也发现不出来.

本文关注的就是如何发现这些问题, 以及发现问题的思路.

我们首先找到系统中一个合适的API或函数, 用来放大问题.

这个 api 设计之初是给 nginx 负载均衡做健康检查的. 使用ab -n 100000 -c 1000 进行压测, 发现 qps 只能到 140 个每秒.

我们知道 Laravel 的性能是出了名的不好, 但是也不至于到这个程度, 从 api 的编写来看不应该这么低. 所以决定一探究竟.

 public function getActivateStatus()
    {
        try {
            $result = \DB::select('select 1');
            $key = 1;
            if ($result[0]->$key !== 1) {
                throw new \Exception("mysql 检查失败");
            }
        } catch (\Exception $exception) {
            \Log::critical("数据库连接失败: {$exception->getMessage()}", $exception->getTrace());
            return \response(null, 500);
        }
        try {
            Cache::getRedis()->connection()->exists("1");
        } catch (\Exception $exception) {
            \Log::critical("缓存连接失败: {$exception->getMessage()}", $exception->getTrace());
            return \response(null, 500);
        }
        return \response(null, 204);
    }

问题表现以及排查思路

# top

top 命令发现系统 CPU 占用 100% 其中用户态占 80%, 内核态占 20%, 看起来没什么大问题. 有一个地方看起来很奇怪, top 命令的运行结果

就是有一部分 php-fpm 进程处在 Sleep 状态, 但 CPU 占用还是达到了近 30%. 当一个进程处于 Sleep 状态的时候, 任然占用了不少 CPU, 先不要怀疑是不是进程的问题, 我们看一下 Ttop 命令的 man page.

%CPU -- CPU usage
The task's share of the elapsed CPU time since the last screen update, expressed as a percentage of total CPU time.

大致意思是这个占用是最后一次屏幕刷新的时候, 进程 CPU 的占用. 由于 top 命令收集信息的时候, 可能 linux 把这个进程强制调度了 ( 比如用于 top 收集进程信息 ), 所以在这一瞬间(屏幕刷新的这一瞬间)某些 php-fpm 进程处于 sleep 状态, 可以理解, 所以应该不是 php-fpm 的问题.

pidstat

首先选出一个 php-fpm 进程, 然后使用 pidstat 查看进程详细的运行情况过程中也没发现什么异样, 并且和top命令的运行结果也基本一致.

vmstat

保持压测压力, 运行 vmstate 查看, 除了 context switch (上下文切换)有点高之外, 并没有看到太多异常. 由于我们使用的 docker, redis, mysql 都运行在同一台机器上, 7000 左右的 CS 还是一个合理的范围, 但是这个 IN(中断)就有点太高了, 达到了 1.4 万左右. 一定有什么东西触发了中断.我们知道中断有硬中断和软中断, 硬中断是由网卡, 鼠标等硬件发出中断信号, cpu 马上停下在做的事情, 处理中断信号. 软中断是由操作系统发出的, 常用于进程的强制调度.

不管是 vmstat 还是 pidstat 都只是新能探测工具, 我们无法看到具体的中断是由谁发出的. 我们通过 /proc/interrupts 这个只读文件中读取系统的中断信息, 获取到底是什么导致的中断升高. 通过 watch -d 命令, 判断变化最频繁的中断.

watch -d cat /proc/interrupts

我们发现其中 Rescheduling interrupts 变化的最快, 这个是重调度中断（RES），这个中断类型表示，唤醒空闲状态的 CPU 来调度新的任务运行。这是多处理器系统（SMP）中，调度器用来分散任务到不同 CPU的机制，通常也被称为处理器间中断（Inter-Processor Interrupts，IPI）。结合 vmstat 中的命令, 我们可以确定造成 qps 不高的原因之一是过多的进程争抢 CPU 导致的, 我们现在还不能确定具体是什么, 所以还需要进一步的排查.

strace

strace 可以查看系统调用, 我们知道, 当使用系统调用的时候, 系统陷入内核态, 这个过程是会产生软中断的, 通过查看 php-fpm 的系统调用, 验证我们的猜想果然, 发现大量的 stat 系统调用, 我们猜想, 是 opcache 在检查文件是否过期导致的. 我们通过修改 opcache 的配置, 让 opcache 更少的检查文件 timestamp, 减少这种系统调用

    opcache.validate_timestamps="60"
    opcache.revalidate_freq="0"

再次执行 ab 命令进行压测果然 qps 直接涨到了 205, 提升非常明显, 有接近 46% 的提升

perf

现在任然不满足这个性能, 希望在更多地方找到突破口. 通过

perf record -g
perf report -g

看到系统的分析报告我们看到, 好像这里面有太多 tcp 建立相关的系统调用(具体是不是我还不清楚, 请大神指正, 但是看到 send, ip, tcp 啥的我就怀疑可能是 tcp/ip 相关的问题). 我们怀疑两种情况

1. 与 mysql, redis 重复大量的建立 TCP 连接, 消耗资源

2. 大量请求带来的 tcp 连接

先说第一个, 经过检查, 发现数据库连接使用了 php-fpm 的连接池, 但是 redis 连接没有, redis 用的 predis, 这个是一个纯 PHP 实现, 性能不高, 换成了 phpredis:

打开 laravel 的 config/database.php 文件, 修改 redis 的 driver 为 phpredis, 确保本机已安装 php 的 redis 扩展. 另外由于 Laravel 自己封装了一个 Redis 门面, 而恰好 redis 扩展带来的对象名也叫 Redis. 所以需要修改 Laravel 的 Redis 门面为其他名字, 如 RedisL5.

再次进行压测

达到了喜人的 286qps, 虽然和其他主打高性能的框架或者原生 php 比, 还有很高的提升空间(比如 Swoole), 但是最终达到了 104% 的提升, 还是很有意义的

总结

我们通过 top, 发现系统 CPU 占用高, 且发现确实是 php-fpm 进程占用了 CPU资源, 判断系统瓶颈来自于 PHP.

接着我们通过 pidstat, vmstat 发现压测过程中, 出现了大量的系统中断, 并通过 watch -d cat /proc/interrupts 发现主要的中断来自于重调度中断（RES)

通过 strace 查看具体的系统调用, 发现大量的系统调用来自于 stat, 猜测可能是opcache 频繁的检查时间戳, 判断文件修改. 通过修改配置项, 达到了 46% 的性能提升

最后再通过 perf, 查看函数调用栈, 分析得到, 可能是大量的与 redis 的 TCP 连接带来不必要的资源消耗. 通过安装 redis 扩展, 以及使用 phpredis 来驱动 Laravel的 redis 缓存, 提升性能, 达到了又一次近 50% 的性能提升.

最终我们完成了我们的性能提升 104% 的目标