php高并发的瓶颈到底在哪?

小天天天天    PHP    999+ 次    2022-11-29 21:39:54


先说结论:瓶颈在高并发下CPU的有效利用率不可思议的低,低于5%;而此时cpu使用率已经100%

再来解释原因:

发展到这个阶段了,所有成熟的语言一般都有manager和worker的细分工

你看下fpm的进程,也是有master(manager)和pool(worker)进程,一般会有多个worker进程。

fpm本身性能几乎是神一样的队友,但是因为php的简单性,没法做神级actor,actor是通过系统内核提供的事件模型来有效提升cpu有效利用率的机制。常见系统内核提供的高效率事件模型有 epoll kqueue evport iocp等等。

既然做不出了actor,又不能破坏php的简单,只能用多开进程,每个进程单线程。

以下原因导致cpu真实利用率在高并发下极低:

1,线程是操作系统调度的最小单位,这句对于理解低效原因很重要。

2,系统切换运行线程需要较大开销

3,web应用典型场景就是io多耗时较长,io就不解释了,能看到或者问到这个问题的,多少有点概念吧。

php因为本身没有actor,所以所有io都是去同步等待,然后问题来了:

高并发下,系统每切一个线程,发现每个线程都在等待io,什么事都做不了,系统只能花费95%的工作切fpm的worker线程玩,而5%的工作是真正处理worker内php代码。就是高并发+io等待下cpu空转。

那空闲的时候fpm是怎么做的呢?因为没有运行php脚本,所以空闲的时候,fpm- worker明确告诉操作系统:我目前不需要调度,性能很高。

如果fpm能做actor情况则会明显好转:

等待的worker线程,我直接告诉操作系统别去调度,只有非等待的进程才让操作系统去调度并分配cpu等资源,这样空转就不会发生。

问题在于,php脚本本身无法利用事件模型,无法告诉主管(fpm)自己是在摸鱼(等待io)还是在真实工作,而大老板(操作系统)也无法知道php是在摸鱼,只能挨个去检查;最后php说:我不是在摸鱼而是在努力等待等快递进行下一步工作。


如果你觉得本篇文章对您有帮助,请打赏作者

上一篇: 将python代码打包成系统可执行文件(Pyinstaller模块)

下一篇: FRP内网穿透实践教程

最新评论

暂无评论

热门文章

最新评论

网站数据

网站文章数:483

今日UV/PV/IP:6/6/6

昨日UV/PV/IP:10/24 /9

TOP