一次偶然看到了國外某機構針對 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 也不是很差嘛，所以大家量力而行，鞋子合不合適只有穿在自己腳上才知道，別把名牌的鞋子硬生生的套在自己腳上，最終的結果反而不盡如人意得不償失。
感謝閱讀，希望對大家能有所啟發。
歡迎關註、分享、點贊、收藏、在看，我是微信公眾號「碼農先森」作者。
