大家好，我是码农先森。
一次偶然看到了国外某机构针对 PHP 周边生态框架及扩展的性能测试排行榜，看到 Workerman 竟遥遥领先 Swoole。在我们 PHP 程序员现有的认知里，Swoole 作为一个基于 C/C++ 语言编写的扩展程序，性能居然落后了。第一眼看到这个结果的时候，我的心情久久不能平复，脑子里不经的浮现着「难道 C/C++ 比 PHP 的性能还差了？」。
说到 Workerman 和 Swoole，就想起了那不争气的 PHP-FPM。这么多年以来，但凡 PHP-FPM 在异步通信领域能有所建树，也就没有 Workerman 和 Swoole 什么事了。Workerman 在测试排行榜上能达到 Top1 想必有其过人之处，那我来说说具体的原因。说 Workerman 之前，先介绍一下目前 PHP-FPM 的现状。
PHP-FPM 是基于多进程模型的 PHP 进程管理器，每个进程在处理请求时都是单线程的，一次只能处理一个请求，无法充分利用多核 CPU 并发处理。并且进程模型还是 IO 同步阻塞的形式，遇到 IO 操作还得苦苦等待。PHP 作为一种解释性语言，每次请求都需要初始化环境、调用各个扩展模块的 MINIT、解析编译代码以及数据库资源的连接，在请求处理完毕后再释放资源、销毁所有定义的类、实例、符号表等，然后按顺序调用各个扩展模块的 RSHUTDOWN。最后将请求生成的结果返回给代理服务，比如 Nginx、Apache 等。PHP-FPM 的这种运行模式，频繁的创建和销毁资源，会导致高的内存使用和低的执行效率，在系统处于高并发、高负载的情况下将会带来致命的后果。
看完 PHP-FPM 的现状不时感叹 Workerman 真是相见恨晚啊，PHP 程序员已经苦 PHP-FPM 久矣。很多人都说 Workerman 高性能，且官方还宣称在 AB 压力测试下 QPS 还超过单独的 Nginx。但有多少人知道为什么高性能呢？它比 PHP-FPM 又好在哪呢？可能大家一时半会也说不清，这里我来做个解释，不过在解释之前我们要先了解一下 IO 多路复用技术。
多路复用
IO 多路复用是通过一种机制实现同时监控多个 IO 流的技术，它的核心思想是通过一个单一的系统调用来同时监控多个 IO 操作。具体来说，IO 多路复用允许一个进程同时监视多个文件描述符，比如 Socket 套接字，并且只在至少一个文件描述符就绪可读、可写或异常等事件情况下才进行真正的 IO 操作。IO 多路复用技术可以让程序在遇到类似 MySQL 读写、Redis 操作、网络请求、文件读取等 IO 操作时，不会阻塞整个进程的执行，达到 IO 操作非阻塞的效果。大家耳熟能详的 Redis、Nginx、Go 也都采用了这种模型。
如果大家对 IO 多路复用技术理解的云里雾里，建议在网上看看其他相关的资料。现在我们只要知道这个技术很「牛逼」就行了，但凡只要涉及到高性能的程序或软件必定会用到 IO 多路复用技术。没错 Workerman 正是将 IO 多路复用技术应用在自己的底层架构里，站在了巨人的肩膀上造就了 Workerman，这便是 Workerman 高性能的根本原因。其次还有一些影响因素，比如常驻进程模式、无需重复加载文件等资源到内存、全局变量只需初始化一次等。Workerman 加持了这些技术，则在性能上远远赶超了 PHP-FPM，但是回到我们刚开始时提到的在某机构性能测试上「Workerman 竟遥遥领先 Swoole」这又是什么原因呢？且听我娓娓道来！
Workerman 采用了 IO 多路复用技术，难道 Swoole 就不知道应用吗？既然 Swoole 官方也同样宣称自己是高性能异步通信框架，那必然也使用了 IO 多路复用技术。Swoole 不仅仅只是简单的使用该技术，而是将该技术在 Swoole 上体现的淋漓尽致贯穿始终，连 Swoole 中引以为傲的协程都是基于事件循环「EventLoop」机制实现的。既然采用了该技术按理来说 Swoole 的性能应该不会差啊！从两者的本质差异上来分析 Workerman 利用的是 pcntl、posix 扩展实现了进程管理的功能，实际上还是基于 PHP 实现。而 Swoole 是基于 C/C++ 语言实现的扩展程序，是以扩展模块的形式在 PHP 中体现，在进程管理方面也完全采用 C/C++ 语言实现。
原因分析
从某机构的测试结果上来看，Workerman 比 Swoole 性能更强的原因，我认为有以下几点。一是：从 Workerman 和 Swoole 实现架构的源代码上来看，Workerman 的架构更简洁代码量更少，反观 Swoole 的 C/C++ 代码量更大内部的处理逻辑更加复杂，Workerman 本质上利用的是 PHP 基本扩展 pcntl、posix 扩展，而 Swoole 本身就是自行实现的扩展模块，从实际的情况上来看往往基本扩展模块比第三方的扩展模块在资源管理方面更加稳定可靠。二是：在单进程模式下，Swoole 没有办法利用多核 CPU 资源，那么 Swoole 中的利器「协程」便发挥不出实际的作用，因此在这种情况下 Swoole 的性能会略逊色于 Workerman。三是：从两者所提供的功能上来看，Workerman 没有类似 Swoole 的并发管理、协程管理、通道管理、通道通信、进程间的通信等底层功能，这些繁冗的功能在程序的运行过程中也存在着一定的系统开销，当程序的复杂度提升，也会显而易见的影响到整个服务的性能和效率。
在某些特定条件的相较之下 Workerman 性能突出，但这也并不妨碍 Swoole 依旧是 PHP 异步通信领域的优秀扩展。Swoole 所提供的功能更丰富，比如可以手动使用协程让程序异步化、可以自行创建数据库连接池提高连接资源的复用、可以利用协程进程间的通信共享内存资源等等。简单的说就是各有千秋，我们在实际的技术选项过程中更应该结合当下的业务场景来做出正确的抉择。
结语
最后，再谈一点个人的看法，Workerman 更适合 PHP 初学者接触网络通信领域，没有那么多类似协程、进程、事件循环、异步阻塞非阻塞等难以理解的概念，直接拿来即用「上手快」。反观 Swoole 很多人都止步于了扩展的安装上，扩展安装环境部署都搞的个半死，更别谈使用了。Swoole 更适合长期在 Linux 环境下编程，并且对操作系统、网络编程、网络协议有一定基础的人。有些人打心底里就看不起 PHP 就自认为基于 C/C++ 语言的 Swoole 就更高级，要学就学最「牛逼」的，往往这种还没有学会走就想要跑的心态，结果都是摔得最惨的。透过这篇文章来看基于 PHP 本身实现的 Workerman 也不是很差嘛，所以大家量力而行，鞋子合不合适只有穿在自己脚上才知道，别把名牌的鞋子硬生生的套在自己脚上，最终的结果反而不尽如人意得不偿失。
感谢阅读，希望对大家能有所启发。
欢迎关注、分享、点赞、收藏、在看，我是微信公众号「码农先森」作者。
