swoole和workerman哪個更易開發？

02-04

對PHP了解不多，為了實現自己的小項目而已，性能不是最重要的，開發的難易度對我更重要，哪個框架更易開發呢？

性能上Swoole畢竟是C語言開發的，在某些地方如內存管理、數據結構、通信協議解析上肯定要比PHP開發的workerman高。

功能上swoole提供的高級特性很多，列舉幾個workerman沒有的吧，比如SSL/TLS隧道加密、http2.0、非同步mysql驅動、非同步redis驅動、非同步的http/websocket客戶端、process、lock、atomic、table。另外Swoole 2.0內置了PHP原生協程的支持，PHP代碼也可以使用類似於Go語言的協程來實現高並發的網路伺服器。

外部依賴上workerman需要依賴很多額外的第三方PHP擴展來實現，局限性比較大，這些擴展並非是PHP官方維護的，維護性方面良莠不齊，有些擴展連PHP7都不支持，數年沒人維護。而Swoole基本上無依賴，底層的代碼全部可控。

開發維護方面，Swoole的開發團隊目前有大概18人左右，開發者基本上都是來自騰訊、百度、阿里、滴滴、微博等國內一線互聯網企業，支持維護的團隊更穩定。

當然workerman的優勢是它完全使用PHP代碼實現，開發者可以直接看它的源碼。有特殊需求也可以直接改源碼來實現。如果換成swoole就不是那麼簡單了。workerman做的事情更多一些，即是框架又是工具和完整的解決方案，對於沒有太多後端編程功底的程序員也來說確實會容易很多。而swoole實際上只是一個底層庫，不是拿來可用的完整產品，基於swoole有很多PHP的框架和程序，比如tsf、zan php framework、hprose-swoole、zphp、swoole/framework、blink、dorarpc、SwooleDistributed等等，普通開發者可以直接基於這些項目進行開發。

Swoole是給高手用的，門檻比較高，需要使用者有深厚的功底。你這裡問的哪個更容易開發，這個沒辦法回答，這個要看你要開發什麼、團隊或個人的實際情況如何，合適的才是最好的。

如上面某位所說，swoole一定會成為PHPer的必備技能。

未來的應用會越來越多的使用交互，PHP已經很難跟上步伐了，但是PHP的低門檻、開發效率高的特色依然會留住大量應用。而swoole可以很好解決PHP的不足之處。

從自身發展以及項目後期的擴展和性能角度考慮，我覺得作為一個phper我覺得swoole是必備的技能，本公司大大小的業務中已經大量使用swoole，沒有任何不適。推薦swoole。

如果覺得直接使用 swoole 有些難，可以使用 hprose-swoole，這樣你就只需要關注業務實現就可以了，而且可以立即獲得跨語言跨平台的能力。

小項目又不要求性能,用平常PHP的運行方式就行,開發起來也最簡單.

基於AJAX長輪詢開發小規模的即時通訊服務,比如公司內部使用的只有幾百個客戶端並發的WebIM. 用PHP最原始的Apache MOD_PHP就能應付,因為AJAX長輪詢本質還是HTTP,還是請求響應. Apache event MPM 開4進程*64線程=256個線程,內存佔用大概是4進程*80=320MB. 也就是說,這時Apache+PHP可以hold住256個AJAX長輪詢請求,一個線程hold住一個連接,非常傳統的做法. 測試時,ab並發255,表示ab佔用了255個線程,Apache還剩下1個線程. 這時通過瀏覽器或curl訪問Apache,速度依然很快,因為還有1個空閑的線程可以處理請求,不需要排隊.

PHP里的邏輯,等待消息不需要while輪詢,直接用phpredis訂閱subscribe消息就會進入阻塞狀態. 超過default_socket_timeout(默認60秒)請求就會被PHP自動中斷,中斷時Redis連接被斷開,訂閱操作會自動被取消. 另外也可以在register_shutdown_function放一些請求結束時的邏輯. 上面這種方法適用於小規模(百級別的並發)通訊服務,好處是不用改變原來PHP的編程習慣,比較簡單. 當然了,要做C10K(萬級別的並發)的即時通訊服務,還是建議用非同步的Swoole和WorkerMan.

Apache event MPM 64 threads + libphp7.so + phpredis(pubsub/subscribe/unsubscribe/publish) &<=&> Redis(PubSub)

MaxRequestWorkers 256 開 4*64=256 個線程,佔用 4*80=320MB 內存. pstree httpd_pid httpd─┬─httpd └─4*[httpd───65*[{httpd}]] time ab -c255 -t60 -s60 http://www.a.com:8080/webim.php (測試腳本睡眠60秒:sleep(60)) sudo netstat -antp|grep 8080|wc -l 可見 (511-1)/2=255 個 ESTABLISHED 連接.

Apache在Windows上的winnt MPM也是一個線程化MPM,只不過不像Linux上的event MPM那樣支持多進程帶多線程.

Apache線程數那麼多,這時就不要開MySQL持久連接了,統一使用短連接,這也是我們最熟悉的開發方式.

Linux上,PHP運行在線程化的Apache里的穩定性不好,如果需要的話,可以考慮使用Facebook的HHVM,這也是有一個多線程的PHP運行時,穩定性更高,HHVM里用PHP實現的Redis客戶端Predis即可,因為HHVM內置的Redis客戶端不支持subscribe操作.

基於Swoole和WorkerMan開發的PHP服務本質都是PHP-CLI程序. PHP腳本里的量是常駐內存的,比如腳本里的全局變數不會在請求結束時被釋放. 因為全局變數是屬於當前PHP-CLI進程,該進程處理的所有請求都共享全局變數. 而在MOD_PHP或PHP-FPM這些CGI運行環境中,腳本里的全局變數在請求結束後就會被釋放. 除了全局變數,函數或類里的靜態變數也類似,在PHP-CLI下不會在請求結束後釋放. 同樣由於常駐內存,所以很難實現熱部署,釋放全局變數,修改PHP腳本,通常都需要重啟PHP-CLI進程. 還有就是,在Swoole和WorkerMan里,PHP腳本出錯(Fatal error),會導致PHP-CLI進程退出. 相比之下,Apache進程或線程,PHP-FPM進程,只是終止腳本執行,自身並不會退出.

用swoole吧。當作技術的提升。就像韓老大說的：Swoole是給高手用的。你難道不想成為高手嗎?還是你一直想去curd？

我當初也在糾結這兩個怎麼選？看著workerman官網的例子很酷炫。也下載玩了幾天。之後就不了了之了。

後來改為學習swoole。說實話，她能激勵我一直學習下去。。一個地方不懂，趕緊找官方wiki，沒有則google之。直到弄清楚為止。。

因為項目需要, 智能家居一類的, 本來準備用C做, 想想swoole和workerman很火很成熟, 不少穩定應用場景了, 想想為什麼不能用這倆試一下呢? 我C水平那麼爛, 用PHP能滿足需求多好?

所以今天大概了解了下swoole和workerman, 初步映象對swoole沒有想像中那麼好, 反而workerman讓我非常驚艷...

先說swoole:

swoole, 官網頂部手冊竟然打不開, 後來找半天找到一個手冊. 你們這麼多人為何不能把官網做的像樣一點呢? 需要很多工作量嗎? 至少把官網頂部那個手冊改為正確地址好不好?

swoole我在freebsd下安裝完畢, 例子程序start後出現如下錯誤:

[2017-09-17 19:53:51 @55879.0] ERROR swSocket_set_buffer_size(:387): setsockopt(4, SOL_SOCKET, SO_SNDBUF, 8388608) failed. Error: No buffer space available[55]. [2017-09-17 19:53:51 @55879.0] ERROR swSocket_set_buffer_size(:387): setsockopt(5, SOL_SOCKET, SO_SNDBUF, 8388608) failed. Error: No buffer space available[55]. [2017-09-17 19:53:51 @55879.0] ERROR swSocket_set_buffer_size(:387): setsockopt(6, SOL_SOCKET, SO_SNDBUF, 8388608) failed. Error: No buffer space available[55]. ... Swoole http server is started at http://127.0.0.1:9501

雖然不影響測試, 但找了一圈沒找到啥解決辦法. 發了issues, 論壇也發帖了, 沒啥反應...

或許只需要修改個配置就能搞定, 但是我不知道去哪裡找到這些資料.

再說workerman:

workerman例子很完善, 講解詳細, 比swoole好一些. 重要一點是用純PHP就能實現如此之高性能, php-cli在php5.3時代就已經成熟了, 一直沒時間在此基礎做大型項目, 老是感覺性能不行, workerman卻讓我驚艷.

workerman用到的pcntl, posix兩個擴展也是PHP自帶的擴展, 默認會編譯進去, streams系列函數是PHP自帶函數, 更沒有擴展之說. 所以韓老大說的太誇張了. 並不需要不成熟第三方擴展, 這兩個擴展是非常成熟的擴展, 穩定到進入PHP默認開啟的擴展, streams甚至進入PHP基本函數了. 如果為了像Nginx一樣開啟Kqueue和Epoll則需要安裝和swoole一樣的pecl擴展:pecl-event. 此擴展也非常穩定了. 這些都是基本擴展, 不會不穩定更不會PHP7不支持. streams, pcntl, posix, pecl-event其實對底層的淺封裝, 性能沒問題, 看你怎麼用, 會不會用, workerman就用的很好.

最後說一下:

我不同意 @韓天峰說的swoole需要比較高超水平, swoole給你封裝好, 拿來用就行.workerman也是封裝好, 拿來用就行. 但如果出現問題workerman需要比較高的水平去修改程序, 了解協議, 甚至修改封裝的代碼. swoole就沒法修改了, 至少你要會C語言才能去修改, 這是很多phper不擅長的.

我覺得用workerman需要你php代碼水平比較高, 用swoole反而沒有那麼多需要接觸修改的東西. 至於使用上覺得swoole難, 那韓老大就要反省下了, 是不是workerman封裝的比較友好? 使用上友好? 為啥workerman多做了一部分工作反而使用上更簡單呢?

我暫時決定用workerman了, 因為出現上述那種問題我可以自己修改workerman的PHP代碼解決, 而且streams, pcntl, posix, pecl-event都是非常穩定的函數和擴展, 穩定到進入PHP基本代碼里, 所以肯定大部分情況不會出問題.

而swoole是用C重新實現的, 很多坑要去完善, 而社區也不活躍, 沒人理睬, 而我沒精力去查C代碼找原因. 發現很多人也是試驗了swoole後發現還是workerman穩定些, 所以改用workerman了. 其實我還是希望swoole能快速發展的完善些.

我希望有一天workerman無法滿足我需求, swoole又非常完美了, 可能是明天, 可能是下個月, 可能是一年後, 到時候我很高興轉到swoole下. 因為接觸swoole比較淺, 觀點也比較淺層主觀, 所以初次這個啟動錯誤的映象讓我臨時棄用swoole, swoole很優秀, 但是希望未來瑕疵會少一些.

以上純屬個人觀點, 一切都是為了PHP能健康快速發展下去, 希望swoole越來越好...

【功能上swoole提供的高級特性很多，列舉幾個workerman沒有的吧，比如SSL/TLS隧道加密、http2.0、非同步mysql驅動、非同步redis驅動、非同步的http/websocket客戶端、process、lock、atomic、table。另外Swoole 2.0內置了PHP原生協程的支持，PHP代碼也可以使用類似於Go語言的協程來實現高並發的網路伺服器。

外部依賴上workerman需要依賴很多額外的第三方PHP擴展來實現，局限性比較大，這些擴展並非是PHP官方維護的，維護性方面良莠不齊，有些擴展連PHP7都不支持，數年沒人維護。而Swoole基本上無依賴，底層的代碼全部可控。】

這個回復代表對workerman沒有任何深入了解。。。

PHP是專門用來處理單個任務的，並且在這方面有非常好的穩定性，但是在處理並行，多任務，多線程的時候問題還是不少。

既然swoole和workman提供了這些方式，小範圍內的使用還是推薦的。

如果請求量較大，對每一次的請求需要較高的穩定性，還是建議使用其他方式。

比如：使用Java、go等語言直連php-fpm**最好不要用長鏈接**。

-------------------------------------這裡是分割線-------------------------------------

我們線上swoole版本對外提供微服務，swoole有0.4%的client主動關閉的問題，換了Java版後，0。

同時藉助了php/java的優勢。用著還是開心的，要是你也遷移到docker上那就更好了。

就開發難易度上說，推薦 nchan，nginx 的 pub/sub 模塊。

server2client 通訊用 pub/sub 模型即可，實際上 EventSource (SSE) 就夠用了。

client2server 直接用標準 http 就完了，沒必要用 websocket 之類的。

對於非同步處理，隨便採用一個 queue 服務的解決方案。

根據我10年的開發經歷,在我以往使用過的（BAT開發的）開源項目都有大量Bug,而且遇到問題，沒有人及時幫你解決問題(這也是為什麼說是高手用的)。

workerman是一個人開發且作者親自一直在維護,有問題作者一直回復,還免費的，文檔齊全,且容易上手，目前使用沒遇到任何問題。說真的那些拿BAT名頭參與的開源項目都是新手在干，所以大家不要被bat名字忽悠了，高手都來自山村野夫掃地僧。

workerman的文檔做的非常好，例子也豐富很多，我覺得workerman更容易上手，而且比swoole穩定很多。

個人意見。

更容易開發選"workerman"。

年初處理微信Html5頁面跟大屏幕互動的項目時，面對swoole和workerman，看文檔後選擇「workerman」，真的很容易開發！

快速上手就workman吧，深入點就swoole

workerman吧，你都說了性能不重要。

長期考慮 swoole吧。

經過小一年的驗證，回來該帖，確實swoole很好用，順便推薦下，如果你用習慣了類似tp那樣簡單好用的框架想上來就開干 easyswoole挺不錯，用其他框架整合swoole 你會有很多漫長的坑要踩放棄吧我試過了

分頁阅读： 1 2