IO密集型業(yè)務(wù),webman框架配置
問題描述
項(xiàng)目需要調(diào)用外部查詢接口,此接口有概率會(huì)超時(shí),由于項(xiàng)目處理的請(qǐng)求可能是持續(xù)不斷的,比如每秒受理10個(gè)請(qǐng)求,如果進(jìn)程受理該請(qǐng)求后,調(diào)用外部查詢接口又超時(shí)了,那么這個(gè)進(jìn)程可能會(huì)超時(shí)阻塞25秒(curl設(shè)置的超時(shí)時(shí)間是25秒)。此時(shí)系統(tǒng)可能就癱瘓了 無法受理請(qǐng)求了 需要等進(jìn)程閑置才能恢復(fù)可訪問性
為此你搜索到了哪些方案及不適用的原因
通過在webman社區(qū)問答的搜索和學(xué)習(xí),我嘗試將進(jìn)程數(shù)量設(shè)置得很大 4核心的服務(wù)器 我設(shè)置了100個(gè)進(jìn)程 但是問題并沒有消失 反而讓我摸不著頭腦 因?yàn)橄到y(tǒng)進(jìn)程阻塞的時(shí)候 100個(gè)進(jìn)程里面可能就幾個(gè)癱瘓了 其他的還是閑置的 但是系統(tǒng)卻無法受理新的請(qǐng)求了 甚至我ssh鏈接的終端也會(huì)很卡頓 因?yàn)槲覍?duì)linux系統(tǒng)不是很了解 這個(gè)問題我只能描述為： 1.webman有足夠大量的進(jìn)程 2.服務(wù)器核心數(shù)不多(核心數(shù)量多要花錢 舍不得) 3.少量幾個(gè)進(jìn)程癱瘓后其他進(jìn)程并沒有分擔(dān)壓力(活好像都派給那幾個(gè)進(jìn)程了,分?jǐn)偛痪?這個(gè)是推測(cè)猜想，另top命令查看cpu占用不到20%。) 4.對(duì)此現(xiàn)象我推測(cè)問題要么是webman進(jìn)程派遣的請(qǐng)求不均勻或者核心數(shù)量少而進(jìn)程數(shù)量多導(dǎo)致的cpu上下文切換消耗極大？
5.請(qǐng)教一下大佬,不想過度升級(jí)服務(wù)器的前提下 如何提高webman IO密集型請(qǐng)求的并發(fā)數(shù)量
1個(gè)回答
打賞
升級(jí)workerman到v5 配合workerman/http-client 協(xié)程用法處理外部http請(qǐng)求
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-
詩酒田園歸 2023-12-05老大 我有點(diǎn)不理解 我現(xiàn)在的項(xiàng)目是webman框架 您的意思是讓我把這塊業(yè)務(wù)獨(dú)立出來 用workerman框架嗎
還是說 可以直接在webman里面用這個(gè)協(xié)程http-client? -
-
-
-
-
詩酒田園歸 2023-12-10
老大我還是有點(diǎn)不明白
worker進(jìn)程是阻塞的 分配到worker的請(qǐng)求也需要同步返回結(jié)果 那么用了這個(gè)協(xié)程的http-client 就不會(huì)阻塞該進(jìn)程了嗎
我實(shí)在沒搞懂 有大佬能解答一下嗎 -
walkor 2023-12-11
worker進(jìn)程本身是非阻塞的，但是開發(fā)者的業(yè)務(wù)代碼可能有阻塞調(diào)用，比如pdo，curl等，導(dǎo)致進(jìn)程阻塞。
workerman/http-client 是非阻塞的庫，只調(diào)用它不會(huì)阻塞進(jìn)程。 -
詩酒田園歸 2023-12-11
老大請(qǐng)問這個(gè)http-client 默認(rèn)示例里面的配置
Connection: keep-alive 是開啟的
我想問一下 這個(gè)有必要開啟嗎 -
-
詩酒田園歸 2023-12-12
老大 協(xié)程用法提升太大了 之前cpu占用很低 程序卻卡死了
現(xiàn)在測(cè)試超大并發(fā) 很快就處理完了 并發(fā)時(shí)cpu占用率也很高 說明協(xié)程的cpu利用率非常高但是我遇到了一個(gè)新的問題
簡單說我的業(yè)務(wù)流程
客戶端->worker->查詢?nèi)浇涌?>返回給客戶端
當(dāng)有大量客戶端請(qǐng)求時(shí),我的項(xiàng)目就會(huì)卡住 現(xiàn)在引入?yún)f(xié)程查詢外部接口 已經(jīng)解決了這個(gè)問題
但是請(qǐng)求結(jié)果有點(diǎn)亂套 比如客戶端a、b、c請(qǐng)求的結(jié)果應(yīng)該是 A B C
但是協(xié)程情況下 客戶端a獲得的結(jié)果可能是 B
或者 客戶端a 對(duì)應(yīng)的協(xié)程有獲取到結(jié)果A 但是卻分配給B了 自己在webman的控制器流程里面結(jié)果卻是空我修改了好幾遍 希望把問題描述清楚 但是好像還是有點(diǎn)繞 老大幫忙看看吧
-
-
-
詩酒田園歸 2023-12-13
這協(xié)程我真不知道咋調(diào)試了 推測(cè)可能的原因是每次都會(huì)調(diào)用一個(gè)靜態(tài)類
之前一個(gè)請(qǐng)求對(duì)應(yīng)一個(gè)進(jìn)程對(duì)應(yīng)一個(gè)靜態(tài)類對(duì)象
現(xiàn)在多個(gè)請(qǐng)求對(duì)應(yīng)一個(gè)進(jìn)程對(duì)應(yīng)多個(gè)靜態(tài)類對(duì)象而靜態(tài)類 多個(gè)對(duì)象其實(shí)是和類掛鉤的 所以一個(gè)變了 別的對(duì)象都跟著變了 這個(gè)是現(xiàn)在的推測(cè) 我還在研究
-
-
-
詩酒田園歸 2023-12-14
問題已經(jīng)解決了 是我的代碼問題 就是我上面說的 我的webman控制器調(diào)用了一個(gè)靜態(tài)類 http請(qǐng)求結(jié)果賦予給靜態(tài)類的某個(gè)靜態(tài)屬性了 改成非靜態(tài)類 實(shí)例化后 就行了
另外我看論壇好多說協(xié)程沒啥用的 我只能說 就我遇到的問題 服務(wù)器配置翻倍都沒啥效果 進(jìn)程開100多個(gè)也沒效果
現(xiàn)在老大出的這個(gè)協(xié)程請(qǐng)求太nb了 針對(duì)io堵塞 或者 請(qǐng)求超時(shí) 的情況 改善的不是一點(diǎn)點(diǎn)
之前壓測(cè)系統(tǒng)直接卡死 現(xiàn)在壓測(cè) 不僅處理完成的時(shí)間少了一半 而且管理后臺(tái)一點(diǎn)不卡 worker也不busy感謝webman 感謝老大 我頭也不疼了
-
-
-
-
-
-
kwokwah 2024-04-08如果業(yè)務(wù)需要，必須在pdo事務(wù)中請(qǐng)求第三方接口（請(qǐng)求失敗回滾/成功提交）,這種情況下使用攜程用法處理HTTP請(qǐng)求，最終還是導(dǎo)致阻塞的吧？不知道有沒有優(yōu)化的方向呢。
-
-
-
kwokwah 2024-04-08
現(xiàn)在的業(yè)務(wù)類似webmanAI助手這個(gè)應(yīng)用。用戶使用服務(wù)需要調(diào)ChatGpt接口并且扣除余額（PDO事務(wù)），不知道怎么分離比較合適。
-
qqxxr 2024-04-08
如果你做推送的話，可以把整個(gè)事務(wù)丟給隊(duì)列（這里就已經(jīng)類似fpm了），隊(duì)列進(jìn)程開多點(diǎn)，這是一個(gè)通用解決方案
-
-
-
-
