PHP 高性能框架 Workerman 凭什么能硬刚 Swoole ？

大家好，我是码农先森。
一次偶然看到了国外某机构针对 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 也不是很差嘛，以是大家量力而行，鞋子合不符合只有穿在自己脚上才知道，别把名牌的鞋子硬生生的套在自己脚上，最终的结果反而不尽如人意得不偿失。
感谢阅读，希望对大家能有所开导。

接待关注、分享、点赞、收藏、在看，我是微信公众号「码农先森」作者。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。