php还行吗,PHP到底能不能搞定大并发

前言：

了解PHP的朋友都应该知道，性能一直是PHP被鄙视的地方，虽然PHP7.0以后，性能又上了一个台阶。但是还有很多只了解些皮毛就出来秀优越的朋友，说什么php不支持多线程。搞定不了大并发。小打小闹还行，大项目php胜任不了。今天我不谈论语言之间的优势劣势，只说说PHP到底能不能搞定大并发

php-fpm生命周期

php-fpm生命周期

首先用户请求到像Apache或者Nginx这样的Web Service。如果是请求非静态数据，比如动态页面，或者是数据接口。就会通过fastcgi来将请求转发到给php。这里fastcig是一种协议，它会将nginx请求中获得的数据处理成php能处理的格式，并且还会将数据放入php的全局变量中，比如$_GET,$_POST。(这里注意PHP模块不一定非要和nginx模块放在一个服务器上，nginx后面的php模块也不是只能有一个)

那标题中提到的php-fpm是什么东西？

PHP-FPM(FastCGI Process Manager) 从名字中可以看出，fpm是一款进程管理器。这个程序启动之后就会有个master进程，这个进程会去初始化php.ini的配置信息。然后master会启动多个worker进程等待从nginx转发的请求。当空闲时，master会销毁一些worker进程，来节省资源。当work进程不够用的时候，master会动态的启动更多的work。可以说php-fpm不仅仅是用来在nginx 和 php之间通信的fastCGI。同样还是php的进程池管理工具。

当php通过fpm接收到来请求，除了php内部本身的代码执行。可能还会有数据库的交互，缓存的交互，文件的IO。这里的操作当然是根据PHP脚本来控制的。当一切操作结束。php会将结果继续通过fastcgi来返回给nginx。nginx 也会将处理好的数据返回给用户。

通过上面的分析，其实我们知道了在nginx+php-fpm场景下php的单线程并不妨碍处理并发。当并发来了fpm会启动更多的worker去处理。并没有发生阻塞。

那为什么php会被诟病，处理不了大并发呢？原因在php-fpm是一个进程管理器。当一个请求进来会占用一个进程。十个请求进来就会占用十个进程。当遇到非常大的并发请求时，php会消耗掉cpu的所有进程数，导致服务不可用。同时创建进程，销毁进程的开销也比较大，性能上也造成了浪费

Swoole生命周期

当然php不是以前的php了。他自己也在不停的进化，来适应更多的开发需要。swoole就是很好的例子。swoole是由中国人开发的php扩展。已经被php官方收录。全世界的程序员都在使用。中国人为开源世界做贡献，让人挺感动的。PHP语言是一个短生命周期的Web编程语言，很多PHPer已经形成了fpm下编程的思维定势。实际上在Swoole出现之后，这种串行化编程的模式早已被打破。使用Swoole完全可以轻易实现更灵活的并发编程。

Swoole其实颠覆了以往PHP的编程模式，使得程序员的视野不再局限于一次请求的处理，不再局限于对于数据库CURD操作、接口调用。配合使用Swoole4提供的协程编程能力，就可以在内存空间内实现各种复杂的交互。

首先要说到的就是swoole的进程管理模式与php-fpm并没有本质上的区别。同样还是一个master多个worker进程。当时不同的是一个同步阻塞。一个异步非阻塞。下面用一幅图来对比下两者的不同

php-fpm在执行代码的时候遇到IO(数据库读写，缓存读写，文件读写)会同步阻塞。后面的任务必须等前面的任务执行完了之后才会接着执行。这种模式的性能是不如swoole的异步执行的。同时因为性能不足还引发了一个更重要的问题。当并发来的时候，进程数达到了最大限制，fpm就会进入等待。当一个进程释放之后才能继续执行代码。而swoole因为单个进程执行速度更快，就能更快的释放掉，也就比fpm更不容易等待进程。这样就能比fpm承载更大的QPS

结语

以上是官网做的压力测试。在同一台机器同样的进程数的限制下，swoole的性能一骑绝尘。侧面也反应出了，swoole+php的组合的确在性能上有了一次飞跃。相信未来也会有更多的开发会使用swoole来开发。