这篇文章给大家分享的是有关PHP并发性能调优的实例的内容。小编觉得挺实用的,因此分享给大家做个参考。一起跟随小编过来看看吧。
<强>框架及相应环境强>
- <李>
laravel5.7, mysql5.7, redis5, nginx1.15
李> <李>centos 7.5 bbr
李> <李>码头工人,docker-compose
李> <李>阿里云4 c和8 g
李><强>问题背景强>
PHP已经开启opcache, laravel也运行了优化命令进行优化,作曲家也进行过dump-autoload命令。
首先需要声明的是,系统的环境中是一定有小问题的(没有问题也不可能能够提升如此大的性能),但是这些问题,如果不通过使用合适的工具,可能一辈子也发现不出来。
本文关注的就是如何发现这些问题,以及发现问题的思路。
我们首先找到系统中一个合适的API或函数,用来放大问题。
这个API设计之初是给nginx负载均衡做健康检查的。 使用ab - n 100000 - c 1000进行压测,发现每秒只能到140个每秒。
我们知道Laravel的性能是出了名的不好,但是也不至于到这个程度,从api的编写来看不应该这么低。所以决定一探究竟。
问题表现以及排查思路
顶部前命令发现系统CPU占用100% 其中用户态占80%,内核态占20%,看起来没什么大问题。有一个地方看起来很奇怪, 前命令的运行结果
就是有一部分php-fpm进程处在睡眠状态,但CPU占用还是达到了近30%。 当一个进程处于睡眠状态的时候,任然占用了不少CPU,先不要怀疑是不是进程的问题,我们看一下Ttop命令的手册页。
<强> pidstat 强>首先选出一个php-fpm进程,然后使用pidstat查看进程详细的运行情况
<强> vmstat 强>
保持压测压力,运行vmstate查看,除了上下文切换(上下文切换)有点高之外,并没有看到太多异常。 由于我们使用的码头工人,复述,mysql都运行在同一台机器上,7000年左右的CS还是一个合理的范围,但是这的个(中断)就有点太高了,达到1.4了万左右。一定有什么东西触发了中断。
我们知道中断有硬中断和软中断,硬中断是由网卡,鼠标等硬件发出中断信号,cpu马上停下在做的事情,处理中断信号。软中断是由操作系统发出的,常用于进程的强制调度。
不管是vmstat还是pidstat都只是新能探测工具,我们无法看到具体的中断是由谁发出的。 我们通过/proc/中断这个只读文件中读取系统的中断信息,获取到底是什么导致的中断升高。通过手表- d命令,判断变化最频繁的中断。
我们发现其中重新安排中断变化的最快,这个是重调度中断(RES),这个中断类型表示,唤醒空闲状态的CPU来调度新的任务运行。这是多处理器系统(SMP)中,调度器用来分散任务到不同CPU的机制,通常也被称为处理器间中断(处理器间的中断,IPI)。 结合vmstat中的命令,我们可以确定造成每秒不高的原因之一是过多的进程争抢CPU导致的,我们现在还不能确定具体是什么,所以还需要进一步的排查。
PHP并发性能调优的实例