大家好，我是碼農(nóng)先森。

一次偶然看到了國外某機構針對 PHP 周邊生態(tài)框架及擴展的性能測試排行榜，看到 Workerman 竟遙遙領先 Swoole。在我們 PHP 程序員現(xiàn)有的認知里，Swoole 作為一個基于 C/C++ 語言編寫的擴展程序，性能居然落后了。第一眼看到這個結果的時候，我的心情久久不能平復，腦子里不經(jīng)的浮現(xiàn)著「難道 C/C++ 比 PHP 的性能還差了？」。

說到 Workerman 和 Swoole，就想起了那不爭氣的 PHP-FPM。這么多年以來，但凡 PHP-FPM 在異步通信領域能有所建樹，也就沒有 Workerman 和 Swoole 什么事了。Workerman 在測試排行榜上能達到 Top1 想必有其過人之處，那我來說說具體的原因。說 Workerman 之前，先介紹一下目前 PHP-FPM 的現(xiàn)狀。

PHP-FPM 是基于多進程模型的 PHP 進程管理器，每個進程在處理請求時都是單線程的，一次只能處理一個請求，無法充分利用多核 CPU 并發(fā)處理。并且進程模型還是 IO 同步阻塞的形式，遇到 IO 操作還得苦苦等待。PHP 作為一種解釋性語言，每次請求都需要初始化環(huán)境、調用各個擴展模塊的 MINIT、解析編譯代碼以及數(shù)據(jù)庫資源的連接，在請求處理完畢后再釋放資源、銷毀所有定義的類、實例、符號表等，然后按順序調用各個擴展模塊的 RSHUTDOWN。最后將請求生成的結果返回給代理服務，比如 Nginx、Apache 等。PHP-FPM 的這種運行模式，頻繁的創(chuàng)建和銷毀資源，會導致高的內(nèi)存使用和低的執(zhí)行效率，在系統(tǒng)處于高并發(fā)、高負載的情況下將會帶來致命的后果。

看完 PHP-FPM 的現(xiàn)狀不時感嘆 Workerman 真是相見恨晚啊，PHP 程序員已經(jīng)苦 PHP-FPM 久矣。很多人都說 Workerman 高性能，且官方還宣稱在 AB 壓力測試下 QPS 還超過單獨的 Nginx。但有多少人知道為什么高性能呢？它比 PHP-FPM 又好在哪呢？可能大家一時半會也說不清，這里我來做個解釋，不過在解釋之前我們要先了解一下 IO 多路復用技術。

多路復用

IO 多路復用是通過一種機制實現(xiàn)同時監(jiān)控多個 IO 流的技術，它的核心思想是通過一個單一的系統(tǒng)調用來同時監(jiān)控多個 IO 操作。具體來說，IO 多路復用允許一個進程同時監(jiān)視多個文件描述符，比如 Socket 套接字，并且只在至少一個文件描述符就緒可讀、可寫或異常等事件情況下才進行真正的 IO 操作。IO 多路復用技術可以讓程序在遇到類似 MySQL 讀寫、Redis 操作、網(wǎng)絡請求、文件讀取等 IO 操作時，不會阻塞整個進程的執(zhí)行，達到 IO 操作非阻塞的效果。大家耳熟能詳?shù)?Redis、Nginx、Go 也都采用了這種模型。

如果大家對 IO 多路復用技術理解的云里霧里，建議在網(wǎng)上看看其他相關的資料?，F(xiàn)在我們只要知道這個技術很「牛逼」就行了，但凡只要涉及到高性能的程序或軟件必定會用到 IO 多路復用技術。沒錯 Workerman 正是將 IO 多路復用技術應用在自己的底層架構里，站在了巨人的肩膀上造就了 Workerman，這便是 Workerman 高性能的根本原因。其次還有一些影響因素，比如常駐進程模式、無需重復加載文件等資源到內(nèi)存、全局變量只需初始化一次等。Workerman 加持了這些技術，則在性能上遠遠趕超了 PHP-FPM，但是回到我們剛開始時提到的在某機構性能測試上「Workerman 竟遙遙領先 Swoole」這又是什么原因呢？且聽我娓娓道來！

Workerman 采用了 IO 多路復用技術，難道 Swoole 就不知道應用嗎？既然 Swoole 官方也同樣宣稱自己是高性能異步通信框架，那必然也使用了 IO 多路復用技術。Swoole 不僅僅只是簡單的使用該技術，而是將該技術在 Swoole 上體現(xiàn)的淋漓盡致貫穿始終，連 Swoole 中引以為傲的協(xié)程都是基于事件循環(huán)「EventLoop」機制實現(xiàn)的。既然采用了該技術按理來說 Swoole 的性能應該不會差啊！從兩者的本質差異上來分析 Workerman 利用的是 pcntl、posix 擴展實現(xiàn)了進程管理的功能，實際上還是基于 PHP 實現(xiàn)。而 Swoole 是基于 C/C++ 語言實現(xiàn)的擴展程序，是以擴展模塊的形式在 PHP 中體現(xiàn)，在進程管理方面也完全采用 C/C++ 語言實現(xiàn)。

原因分析

從某機構的測試結果上來看，Workerman 比 Swoole 性能更強的原因，我認為有以下幾點。一是：從 Workerman 和 Swoole 實現(xiàn)架構的源代碼上來看，Workerman 的架構更簡潔代碼量更少，反觀 Swoole 的 C/C++ 代碼量更大內(nèi)部的處理邏輯更加復雜，Workerman 本質上利用的是 PHP 基本擴展 pcntl、posix 擴展，而 Swoole 本身就是自行實現(xiàn)的擴展模塊，從實際的情況上來看往往基本擴展模塊比第三方的擴展模塊在資源管理方面更加穩(wěn)定可靠。二是：在單進程模式下，Swoole 沒有辦法利用多核 CPU 資源，那么 Swoole 中的利器「協(xié)程」便發(fā)揮不出實際的作用，因此在這種情況下 Swoole 的性能會略遜色于 Workerman。三是：從兩者所提供的功能上來看，Workerman 沒有類似 Swoole 的并發(fā)管理、協(xié)程管理、通道管理、通道通信、進程間的通信等底層功能，這些繁冗的功能在程序的運行過程中也存在著一定的系統(tǒng)開銷，當程序的復雜度提升，也會顯而易見的影響到整個服務的性能和效率。

在某些特定條件的相較之下 Workerman 性能突出，但這也并不妨礙 Swoole 依舊是 PHP 異步通信領域的優(yōu)秀擴展。Swoole 所提供的功能更豐富，比如可以手動使用協(xié)程讓程序異步化、可以自行創(chuàng)建數(shù)據(jù)庫連接池提高連接資源的復用、可以利用協(xié)程進程間的通信共享內(nèi)存資源等等。簡單的說就是各有千秋，我們在實際的技術選項過程中更應該結合當下的業(yè)務場景來做出正確的抉擇。

結語

最后，再談一點個人的看法，Workerman 更適合 PHP 初學者接觸網(wǎng)絡通信領域，沒有那么多類似協(xié)程、進程、事件循環(huán)、異步阻塞非阻塞等難以理解的概念，直接拿來即用「上手快」。反觀 Swoole 很多人都止步于了擴展的安裝上，擴展安裝環(huán)境部署都搞的個半死，更別談使用了。Swoole 更適合長期在 Linux 環(huán)境下編程，并且對操作系統(tǒng)、網(wǎng)絡編程、網(wǎng)絡協(xié)議有一定基礎的人。有些人打心底里就看不起 PHP 就自認為基于 C/C++ 語言的 Swoole 就更高級，要學就學最「牛逼」的，往往這種還沒有學會走就想要跑的心態(tài)，結果都是摔得最慘的。透過這篇文章來看基于 PHP 本身實現(xiàn)的 Workerman 也不是很差嘛，所以大家量力而行，鞋子合不合適只有穿在自己腳上才知道，別把名牌的鞋子硬生生的套在自己腳上，最終的結果反而不盡如人意得不償失。

感謝閱讀，希望對大家能有所啟發(fā)。

歡迎關注、分享、點贊、收藏、在看，我是微信公眾號「碼農(nóng)先森」作者。