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

是同步阻塞？还是nginx+fpm不断创建-销毁进程资源过度消耗？高并发到底是什么问题，是语言问题嘛，为什么说php不适合高并发？求大佬指点

从2009年后一直用lnmp，从5.2.17一直到现在的PHP7.4，做的项目无数个，大到日IP10W+、PV50W+的平台，小到日IP不到100的企业网站，也有瞬时并发很高的万人报名类项目，还有采集类从火车头等POST到后台上千万条数据的项目。我的经验是，PHP从来没拖过我后腿，日常拖后腿的要么是MySQL，要么是带宽。偶尔会遇到PHP吃资源的情况，检查自己的代码，看看有没有不合理的循环，基本都能解决。

在5.2 -5.4时期，也确实经常会遇到进程被K，加个定时器检测就行，5.6后面基本很难遇到，7.3后表现完美。

从我这十年的经验看，项目优化第一是架构（BGP、动静分离、CDN加速、负载均衡等），第二是数据库，SQL的优化永远在路上，第三日志分析，通过日志分析优化第一和第二。

别动不动搞个什么demo说什么语言强，我不知道大家都做的是些什么超级工程，大家直接放出项目来，日活多少，分、小时并发多少，并发特点是啥，什么用户群体，公司或者老板给了多少预算，放出来大家一起讨论。

再说一下我个人的一些项目经历。2011年接手了云南建筑业一个B2B网站，这个项目2010年某远科技报价10W，用java,干了半年，上线测试各种卡，后面我接手，花了一个月用齐博B2B，上线搞定，后面转到DESTOON，商家近9000家，日IP峰值4W。当时某远科技用的是dell的服务器，具体型号忘记了，2W多，托管在昆明牛街庄机房，电信5M，8000元一年。我接手后，初期直接上双线VPS,2000元一年。后面换到郑州BGP10M，I5 2310+4G+120G SSD+500GX2HDD 5000一年，三年送产权。老板连着两年年终发了2月的薪水（在昆明不容易，感恩）

2014年，又接手了一个茶叶B2B2C项目，原项目用.NET开发，开发的人是老板的朋友，时任昆明某汛科技的技术总监。原因也是速度太慢，功能太差，同样换到PHP，用了某B2B2C的开源程序，一个月上线。每年硬件费用也从8000降到了3000。

类似上面这样的例子我接手的还有很多，上面这两个例子原开发公司在昆明、云南、甚至西南地区都算大公司，一个主打JAVA，一个主打.NET，为什么我能用PHP轻易的替换？

一直没搞明白当一个人说高并发的时候究竟是指高并发请求数还是高qps，这两者有联系但本质上还是不同的。

一般一个web服务，只使用一个client去调用的时候，有一个基础耗时，此时单个client的qps就是耗时的倒数。由于一般请求都会涉及计算和IO等几个有序的环节，只使用一个client通常无法充分利用硬件能力，如果增加并发的client数量，通常接口耗时会增加，也就是单个client的qps可能会下降，但总qps会上升。继续增加并发的client数量到某一值之后，总qps不再上升，有些服务实现还会下降或者请求出错。此时随并发client数量的增加，请求的平均耗时明显增加。

如果在qps上升到最大值时，CPU使用率、带宽、磁盘IO之一达到了硬件允许的最大值，就说明当前qps限制是硬件限制导致的。如果均未达到最大值，一般是因为配置不合理，例如使用线程池实现的服务没有配足够多的线程数。一般来说，常见服务器在常见的硬件配置下，通过适当的设置都可以达到硬件限制，没有到达硬件限制都是因为配置不当。大体上来说，纯异步框架和同步线程/进程实现的框架相比，优势在于几乎不需要特别配置就可以达到硬件允许的最大值，而且一般随并发数提升qps基本不下降，相比起来，线程池实现的框架则需要根据应用不同和调用情况不同设置不同的线程数才能取得最好效果。

同样达到硬件限制，不同服务器能达到的qps也是不同的，取决于每个请求占用的资源数量。对于一般的web应用来说，限制一般都是CPU，也就是说要提高qps重点是降低每次请求的CPU使用，这又进一步分为操作系统使用、框架使用、应用使用几部分。异步框架在操作系统使用和框架（只包括基础IO如swoole，不算web框架如laravel）使用上略有优势，不过真实应用往往还是应用（含web框架）使用较多。

回到PHP上，如果要提升能同时接受的并发client数，使并发请求client数量多的情况下qps仍能稳定到最大值（但是平均响应时间会提升），可以使用更多进程数或者使用异步框架，并没有什么特别不可行的。

如果要提升最大qps，那就有一些需要说的了：

1. 最根本的，PHP本身还是运行得太慢，即使是最新版，虽然比CPython快多了，但是低于node和PyPy，而这两者跟真正的编译语言比也差得远。最终瓶颈一般还是在这里。虽说PHP应用通常也是以IO为主，但真实应用中的CPU占用还是会成为瓶颈。
2. php-fpm模式下每个请求都要重新加载代码并初始化，OpCache只能解决一部分问题 。使用常驻的框架如swoole能解决这个问题。另外数据库连接池等也有影响。
3. 和前两点相比，IO框架带来的性能提升不算很显著。Web框架使用C编写性能会好一些。
4. 实际上，应用本身的实现优劣也有很大影响。不必要的大array复制之类的问题会严重拖慢性能。使用ORM时，拼接SQL之类的操作也可能比想象中更加耗时。使用了不恰当的数据结构或算法也可能影响性能。