IO密集型業(yè)務(wù),webman框架配置

詩酒田園歸 2023-12-05

問題描述

項目需要調(diào)用外部查詢接口,此接口有概率會超時,由于項目處理的請求可能是持續(xù)不斷的,比如每秒受理10個請求,如果進程受理該請求后,調(diào)用外部查詢接口又超時了,那么這個進程可能會超時阻塞25秒(curl設(shè)置的超時時間是25秒)。此時系統(tǒng)可能就癱瘓了無法受理請求了需要等進程閑置才能恢復(fù)可訪問性

為此你搜索到了哪些方案及不適用的原因

通過在webman社區(qū)問答的搜索和學(xué)習(xí),我嘗試將進程數(shù)量設(shè)置得很大 4核心的服務(wù)器我設(shè)置了100個進程但是問題并沒有消失反而讓我摸不著頭腦因為系統(tǒng)進程阻塞的時候 100個進程里面可能就幾個癱瘓了其他的還是閑置的但是系統(tǒng)卻無法受理新的請求了甚至我ssh鏈接的終端也會很卡頓因為我對linux系統(tǒng)不是很了解這個問題我只能描述為： 1.webman有足夠大量的進程 2.服務(wù)器核心數(shù)不多(核心數(shù)量多要花錢舍不得) 3.少量幾個進程癱瘓后其他進程并沒有分擔(dān)壓力(活好像都派給那幾個進程了,分?jǐn)偛痪?這個是推測猜想，另top命令查看cpu占用不到20%。) 4.對此現(xiàn)象我推測問題要么是webman進程派遣的請求不均勻或者核心數(shù)量少而進程數(shù)量多導(dǎo)致的cpu上下文切換消耗極大？
5.請教一下大佬,不想過度升級服務(wù)器的前提下如何提高webman IO密集型請求的并發(fā)數(shù)量

 2538  1 17

1個回答

walkor 2023-12-05

打賞

升級workerman到v5 配合workerman/http-client 協(xié)程用法處理外部http請求

composer require workerman/workerman ^5.0.0-beta.7
composer require revolt/event-loop ^1.0.1
composer require workerman/http-client ^2.0.1

文檔 http://m.wtbis.cn/doc/workerman/components/workerman-http-client.html#%E5%8D%8F%E7%A8%8B%E7%94%A8%E6%B3%95

詩酒田園歸 2023-12-05

老大我有點不理解我現(xiàn)在的項目是webman框架您的意思是讓我把這塊業(yè)務(wù)獨立出來用workerman框架嗎
還是說可以直接在webman里面用這個協(xié)程http-client?
walkor 2023-12-05

webman里面用這個協(xié)程http-client
TM 2023-12-06

是在當(dāng)前線程開攜程處理curl請求嗎，愛了 windows環(huán)境可以測試嗎
walkor 2023-12-06

curl不行，要workerman/http-client 配合 workerman/workerman v5 revolt/event-loop
TM 2023-12-06

直接用http-client 請求即可是嗎好的好的
詩酒田園歸 2023-12-10

老大我還是有點不明白
worker進程是阻塞的分配到worker的請求也需要同步返回結(jié)果那么用了這個協(xié)程的http-client 就不會阻塞該進程了嗎
我實在沒搞懂有大佬能解答一下嗎
walkor 2023-12-11

worker進程本身是非阻塞的，但是開發(fā)者的業(yè)務(wù)代碼可能有阻塞調(diào)用，比如pdo，curl等，導(dǎo)致進程阻塞。
workerman/http-client 是非阻塞的庫，只調(diào)用它不會阻塞進程。
詩酒田園歸 2023-12-11

老大請問這個http-client 默認(rèn)示例里面的配置
Connection: keep-alive 是開啟的
我想問一下這個有必要開啟嗎
walkor 2023-12-11

開啟性能好
詩酒田園歸 2023-12-12

老大協(xié)程用法提升太大了之前cpu占用很低程序卻卡死了
現(xiàn)在測試超大并發(fā) 很快就處理完了并發(fā)時cpu占用率也很高說明協(xié)程的cpu利用率非常高

但是我遇到了一個新的問題

簡單說我的業(yè)務(wù)流程
客戶端->worker->查詢?nèi)浇涌?>返回給客戶端
當(dāng)有大量客戶端請求時,我的項目就會卡住現(xiàn)在引入?yún)f(xié)程查詢外部接口已經(jīng)解決了這個問題
但是請求結(jié)果有點亂套比如客戶端a、b、c請求的結(jié)果應(yīng)該是 A B C
但是協(xié)程情況下客戶端a獲得的結(jié)果可能是 B
或者客戶端a 對應(yīng)的協(xié)程有獲取到結(jié)果A 但是卻分配給B了自己在webman的控制器流程里面結(jié)果卻是空

我修改了好幾遍希望把問題描述清楚但是好像還是有點繞老大幫忙看看吧
walkor 2023-12-12

你要發(fā)一個能證明結(jié)果錯亂的demo，并附上測試方法和結(jié)果
詩酒田園歸 2023-12-12

好的老大我糊涂了
詩酒田園歸 2023-12-13

這協(xié)程我真不知道咋調(diào)試了推測可能的原因是每次都會調(diào)用一個靜態(tài)類
之前一個請求對應(yīng)一個進程對應(yīng)一個靜態(tài)類對象
現(xiàn)在多個請求對應(yīng)一個進程對應(yīng)多個靜態(tài)類對象

而靜態(tài)類多個對象其實是和類掛鉤的所以一個變了別的對象都跟著變了這個是現(xiàn)在的推測我還在研究
meows 2023-12-13

你在這研究不如直接提交一個復(fù)現(xiàn)的例子給作者，他比你寫得更快，好幾十倍。
meows 2023-12-13

直接貼出你寫的代碼吧，你這么說根本不知道你在描述什么。說實在點，跟沒說沒啥區(qū)別。
詩酒田園歸 2023-12-14

問題已經(jīng)解決了是我的代碼問題就是我上面說的我的webman控制器調(diào)用了一個靜態(tài)類 http請求結(jié)果賦予給靜態(tài)類的某個靜態(tài)屬性了改成非靜態(tài)類實例化后就行了

另外我看論壇好多說協(xié)程沒啥用的我只能說就我遇到的問題服務(wù)器配置翻倍都沒啥效果進程開100多個也沒效果

現(xiàn)在老大出的這個協(xié)程請求太nb了針對io堵塞或者請求超時的情況改善的不是一點點
之前壓測系統(tǒng)直接卡死現(xiàn)在壓測不僅處理完成的時間少了一半而且管理后臺一點不卡 worker也不busy

感謝webman 感謝老大我頭也不疼了
Tinywan 2023-12-16

比吃藥還管用
nitron 2023-12-16

好像也沒人說協(xié)程沒啥用吧...
Tinywan 2023-12-16

目前還沒實際用到
kspade 2023-12-19

guzzle 行不行？
allenworker 2023-12-22

牛
kwokwah 2024-04-08

如果業(yè)務(wù)需要，必須在pdo事務(wù)中請求第三方接口（請求失敗回滾/成功提交）,這種情況下使用攜程用法處理HTTP請求，最終還是導(dǎo)致阻塞的吧？不知道有沒有優(yōu)化的方向呢。
qqxxr 2024-04-08

回滾這里可以交給消息隊列異步處理，但是發(fā)起請求這里，你是要等待結(jié)果的，只能阻塞吧
qqxxr 2024-04-08

感覺實在無法分離的阻塞業(yè)務(wù)，這里業(yè)務(wù)如果實在接受不鳥阻塞，干脆丟給fpm處理
kwokwah 2024-04-08

現(xiàn)在的業(yè)務(wù)類似webmanAI助手這個應(yīng)用。用戶使用服務(wù)需要調(diào)ChatGpt接口并且扣除余額（PDO事務(wù)），不知道怎么分離比較合適。
qqxxr 2024-04-08

如果你做推送的話，可以把整個事務(wù)丟給隊列（這里就已經(jīng)類似fpm了），隊列進程開多點，這是一個通用解決方案
qqxxr 2024-04-08

而且，隊列的服務(wù)本來也可以單獨部署
sinowealth 2024-04-08

隊列這種用法感覺像是Java的線程池，從Java的角度來說不建議自發(fā)自取，我之前也是這樣處理但是人家覺得不太行
qqxxr 2024-04-09

因為他的場景是必須等待結(jié)果的，異步隊列稍微好點吧
putyy 2024-04-09

等請求三方接口回來在進行事務(wù) 處理散