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