[不懂就問]關(guān)于webman和workerman swoole的幾個(gè)問題

MarkGo 更新于2022-02-22

背景：
傳統(tǒng)PHP-FPM已經(jīng)無法應(yīng)付當(dāng)前數(shù)據(jù)量特別大的今天了。
流量一大，經(jīng)常遇到PHP-FPM CPU100%的情況，即使堆機(jī)器也不是長久解決辦法。

準(zhǔn)備轉(zhuǎn)型的時(shí)候，收集了一下相關(guān)資料。
1、轉(zhuǎn)GO
2、基于常駐型的框架
3、PHP8 JIT

1、忽略了，并不是不想轉(zhuǎn)型GO，而是從0開始自己玩玩之類的沒問題，但公司基本都是PHP開發(fā)的，轉(zhuǎn)GO后大家都沒經(jīng)驗(yàn)遇到BUG也不好解決，而且初識(shí)GO，發(fā)現(xiàn)packege基本依賴github，國內(nèi)形勢......
2、常駐型
SWOOLE 是一開始的首選框架，通過1周時(shí)間熟悉了SWOOLE，但是也發(fā)現(xiàn)相關(guān)的問題（手冊過于簡陋、后續(xù)測試發(fā)現(xiàn)QPS沒達(dá)到理想數(shù)值，某些場景甚至比不上PHP-FPM，最新版。NGINX -> SWOOLE），當(dāng)然并非引戰(zhàn)，也有可能是自己才疏學(xué)淺的原因。
webman 次選方案，用了1天時(shí)間開發(fā)，開發(fā)后也進(jìn)行了測試，發(fā)現(xiàn)webman各個(gè)方面都超越SWOOLE，甚至說已經(jīng)超越了當(dāng)初的理想數(shù)值。
！重申一遍，不是引戰(zhàn)，業(yè)務(wù)場合是API接口開發(fā)，基本功能涉及鑒權(quán)->路由->redis->數(shù)據(jù)庫。由于這里不是框架比較，所以詳細(xì)的不說太多。如果覺得是1周時(shí)間學(xué)習(xí)swoole不夠，那1天學(xué)習(xí)webman真的也不多?？赡苣承﹫鼍癝WOOLE會(huì)超過webman，但我需求的場景，確實(shí)是webman高出swoole很多很多倍。

[背景信息扯談完了]
想咨詢一下，個(gè)人理解，workman針對(duì)大型應(yīng)用各個(gè)不同場合都能兼顧到，而webman主要側(cè)重于API的場合，這樣理解有錯(cuò)嗎？如果是準(zhǔn)備轉(zhuǎn)型webman/workman，請問兩者的區(qū)別是僅僅特定場合不一致嗎？性能是差不多的吧？

針對(duì)PHP各版本，WEBMAN/WORKMAN是否有相關(guān)測試性能？還是說版本對(duì)于性能影響是相當(dāng)??？
比如PHP8開啟了JIT，但實(shí)際上webman/workman屬于常駐型，JIT意義并不大，我可以這樣理解嗎？

另外想問問，是否能把workman/webman 托管給systemctl？
如生產(chǎn)環(huán)境直接用 -d 啟用，是否會(huì)有守護(hù)進(jìn)程？

 17886  2 2

2個(gè)回答

weijer 2021-02-01

1、go packege 可以走 https://goproxy.io 跟php composer走代理一樣！
2、對(duì)于成熟的業(yè)務(wù)不建議全部重構(gòu)，可以把瓶頸服務(wù)拆出來。php 結(jié)合 go 做服務(wù)很適合，可以走h(yuǎn)ttp協(xié)議、也可以走rpc協(xié)議。
3、至于workerman和swoole性能上基本上是一個(gè)數(shù)量級(jí)對(duì)手，swoole多了協(xié)程實(shí)現(xiàn)。

MarkGo 2021-02-01

感謝回復(fù)
1、GO基本忽略了，原因除了國內(nèi)網(wǎng)絡(luò)外，最主要的是公司沒有使用GO的熟手，怕遇到問題后“無解”，這是公司自身原因，并非語言原因，另一點(diǎn)是看過多個(gè)評(píng)測，workman性能都追上GO了（沒具體測試）
2、其實(shí)現(xiàn)在觀察了下業(yè)務(wù)性能，基本瓶頸是在于MYSQL->流量壓力->fpm處理能力
MYSQL部分只能通過mysql語句優(yōu)化和嘗試釋放出mysql，早期項(xiàng)目大部分功能是通過SQL實(shí)現(xiàn)的，現(xiàn)在看能否通過業(yè)務(wù)層實(shí)現(xiàn)。
流量壓力其實(shí)也沒更好的解決方法，只能通過加大帶寬來避免。
fpm壓力，其實(shí)現(xiàn)在流量一大，fpm基本就100%，后續(xù)請求都直接500.
現(xiàn)在暫時(shí)能想到的方法就是把數(shù)據(jù)庫中賬號(hào)，匯率等變化頻率低的信息load到業(yè)務(wù)層中，減輕數(shù)據(jù)庫壓力。產(chǎn)品變動(dòng)價(jià)格變動(dòng)倉存變動(dòng)等通過丟進(jìn)rabbitMQ，在另一臺(tái)機(jī)進(jìn)行消費(fèi)，把同步改為異步，釋放主業(yè)務(wù)服務(wù)器壓力。
*現(xiàn)在其實(shí)最大瓶頸是在于當(dāng)初由于業(yè)務(wù)原因，要弄兩個(gè)功能一樣，數(shù)據(jù)隔離的系統(tǒng)。當(dāng)初做法就是整個(gè)數(shù)據(jù)庫復(fù)制一份，架構(gòu)同步，數(shù)據(jù)隔離。后期因?yàn)閮蓚€(gè)系統(tǒng)都需要對(duì)外提供服務(wù)和產(chǎn)品查詢，變成了現(xiàn)在前端接口特別是要分頁的那些，SQL語句根本無法優(yōu)化，必須兩邊全量查詢后才能分頁。暫時(shí)都是用redis來解決。
3、workerman和swoole性能是否接近估計(jì)看場景吧，而且就算接近，workman的社區(qū)和手冊比swoole的環(huán)境好很多。實(shí)話實(shí)說，swoole 4.4版本 + PHP 7.2，使用了swoole內(nèi)置的數(shù)據(jù)庫連接池，提供API服務(wù)；測試結(jié)果是QPS極低，唯一定位到的就是只要查詢mysql，qps就會(huì)降低，當(dāng)時(shí)嘗試直接使用PDO，開啟(全)協(xié)程，使用官方連接池，結(jié)果都一樣。后來換了webman，qps馬上就上來了；具體什么原因不清楚，也沒深究。

最后，我這個(gè)只是自己業(yè)務(wù)上測試結(jié)果，是否因?yàn)槟承┰驅(qū)е聅woole如此，不清楚，更加不能作為性能論證，我也沒有貶低swoole的意思，只是在我個(gè)人的業(yè)務(wù)場景上數(shù)值如此。不具備參考性。任何開源框架都值得尊重。
你好啊 2021-02-02

swoole與wk的性能應(yīng)該是差別不大，出現(xiàn)這個(gè)結(jié)果可能是你的測試姿勢不對(duì)。你的這個(gè)問題的原因有可能是數(shù)據(jù)庫鏈接池開的數(shù)量大了導(dǎo)致性能消耗而下降的，當(dāng)然這個(gè)只是猜測的原因。具體還要看你的測試邏輯

evilk 2021-02-02

1.我司大部分業(yè)務(wù)還是跑在php-fpm上
2.少數(shù)需要高性能,高并發(fā)的業(yè)務(wù),用的swoft(2.0.10) + swoole(4.6.2) + php(7.4)
3.對(duì)于用GO重構(gòu),根據(jù)目前情況來看,當(dāng)前的架構(gòu)還可以支撐很久,遠(yuǎn)遠(yuǎn)達(dá)不到換GO的程度

個(gè)人認(rèn)為:
1.workerman系列和swoole系列,性能應(yīng)該是一個(gè)級(jí)別的,差距不會(huì)太大
2.workerman系列,本質(zhì)上講,還是屬于同步模型,一個(gè)worker接收了請求,遇到IO,則阻塞在那里,不能繼續(xù)處理下一個(gè)請求
3.swoole 4.x系列,主要?dú)w功于協(xié)程這個(gè)東西,遇到IO,不會(huì)阻塞
4.我有考慮,后面的項(xiàng)目用webman試試水,看看效果如何
5.swoole目前的問題是,每次版本更新都會(huì)新增功能,修復(fù)少數(shù)bug,感覺還是不太穩(wěn)定

MarkGo 2021-02-03

說實(shí)話，我是6年多前注意到workman的，
但是同期也發(fā)現(xiàn)了swoole，兩邊都沒太深入接觸，僅僅看了下而已。
到最近遇到瓶頸了，打算改變架構(gòu)，才開始深入了解這兩樣產(chǎn)品。
我一開始認(rèn)為swoole怎么也比workman強(qiáng),主要原因是因?yàn)閟woole是C++開發(fā)的擴(kuò)展。
但是實(shí)際情況，從各方面第三方壓測結(jié)果，workman是超越swoole。
但當(dāng)時(shí)我依然不相信，覺得評(píng)測有貓膩，
后續(xù)實(shí)際項(xiàng)目中，現(xiàn)在有一個(gè)服務(wù)（微信導(dǎo)購客服）是用swoole開發(fā)的，并且已經(jīng)穩(wěn)定運(yùn)行了1個(gè)多月，
現(xiàn)在要增加API接口，第一反應(yīng)就是swoole，
但開發(fā)完了權(quán)鑒，列表的接口后，用wrk進(jìn)行壓測，結(jié)果令我目瞪口呆，是比FPM還低下。
機(jī)器配置是（4C 8G 5M），在運(yùn)行的服務(wù)有rabbitMQ，nginx，php-fpm，swoole 導(dǎo)購，
新增這套的api流程是NGINX->SWOOLE，然后異地進(jìn)行wrk壓測。（當(dāng)時(shí)能試的都試過了，文檔翻閱無數(shù)遍，數(shù)據(jù)庫框架從原生PDO換swoole 數(shù)據(jù)庫池）結(jié)果差異不大，
我嘗試過取消所有DB操作，壓測結(jié)果會(huì)飆升，涉及到DB，結(jié)果狂降，
當(dāng)時(shí)嘗試過在mysql 里show process，但是數(shù)據(jù)庫基本沒壓力。倒是主機(jī)的CPU直接400%。
后來更換了workman，完成了鑒權(quán)和列表API后，壓測結(jié)果和CPU使用率對(duì)比swoole簡直是天地之壤。

這就是我換成workman主要原因，次要原因是swoole社區(qū)支持比較差，文檔也.....
當(dāng)然，我覺得應(yīng)該是我服務(wù)器上環(huán)境的原因?qū)е逻@個(gè)結(jié)果的，
但無論如何，我已經(jīng)放棄了swoole了。
不過怎么說，這兩個(gè)框架無疑都是最后的一道曙光。
swoole慢慢向商業(yè)演變，workman依然堅(jiān)持社區(qū)維護(hù)。而且回復(fù)都非常及時(shí)，這個(gè)是我當(dāng)時(shí)沒想到...
不說太多了，選擇哪個(gè)估計(jì)看自有業(yè)務(wù)吧，我也不是吹捧workman，畢竟沒必要在workman的論壇里吹捧workman。但workman作者的這份精神，真實(shí)十分難能可貴。
Tinywan 2021-07-15

作者的開源精神是大大的好啊
張一 2021-12-10

看到這篇文章，您的經(jīng)歷在我身上重演，你所表達(dá)的所有流程以及想法，跟我完全一樣。一樣的業(yè)務(wù)邏輯swoole/webma壓測后，webman完勝。哈哈哈我也沒有要黑swoole的意思（可能跟我對(duì)代碼水平有關(guān)）