實(shí)際業(yè)務(wù)場(chǎng)景，發(fā)現(xiàn)連接池這個(gè)東西還是需要的
webman本身很省連接，一個(gè)進(jìn)程一個(gè)連接，也看過(guò)老大對(duì)連接池解釋的帖子，但是最近遇到一個(gè)場(chǎng)景，感覺(jué)業(yè)務(wù)量如果再加大，沒(méi)有連接池是不行了
業(yè)務(wù)場(chǎng)景如下:
原本開(kāi)了4倍進(jìn)程，32*4，Mysql500個(gè)開(kāi)連接，webman+fpm程序總共用不到200個(gè)連接，活躍連接1-3
最近新加了一個(gè)功能，我司用到一個(gè)第三方付費(fèi)接口，該接口在我司客戶端產(chǎn)品調(diào)用，但是該接口只有一個(gè)固定秘鑰字符串，沒(méi)有生成簽名之類的。
為了防止該付費(fèi)接口被客戶端抓包非法調(diào)用，并且要對(duì)該API加價(jià)計(jì)費(fèi)，于是寫(xiě)了一個(gè)接口，中轉(zhuǎn)調(diào)用第三方付費(fèi)接口，調(diào)用成功之后扣除用戶在我方平臺(tái)的余額。該接口是實(shí)時(shí)代理采集淘寶、拼多多等電商平臺(tái)數(shù)據(jù)，所以返回較慢，很多需要800-1200ms才能返回接口，這導(dǎo)致我原來(lái)的4倍進(jìn)程不夠用，大量后續(xù)請(qǐng)求阻塞。
于是我把進(jìn)程一直上調(diào)到CPU核*12倍=382個(gè)進(jìn)程，才實(shí)現(xiàn)了不堵塞，雖然進(jìn)程多了，但是實(shí)際CPU和內(nèi)存負(fù)載還是很多，估計(jì)開(kāi)30倍都沒(méi)問(wèn)題。但是過(guò)來(lái)一會(huì)兒出現(xiàn)了另外的問(wèn)題，原來(lái)的fpm老項(xiàng)目也連了這個(gè)數(shù)據(jù)庫(kù)，因?yàn)镸ysql連接數(shù)限制的500，這時(shí)候就出現(xiàn)了進(jìn)FPM連接數(shù)不夠用的問(wèn)題，fpm項(xiàng)目出現(xiàn)502，最后將Mysql最大連接數(shù)改1000解決
長(zhǎng)遠(yuǎn)思考，如果我的業(yè)務(wù)量放大到10臺(tái)服務(wù)器，業(yè)務(wù)相近，就需要10臺(tái)32核心12 = 3820個(gè)進(jìn)程，Mysql就要4000+個(gè)連接數(shù)才能夠用，這種場(chǎng)景下沒(méi)有連接池是不行了
9個(gè)回答
同問(wèn)，配置的時(shí)候 應(yīng)該乘以多少合理，或者說(shuō)該怎樣判斷，我現(xiàn)在是*6，我感覺(jué)還能加大，提升并發(fā)能力
-
gddd 2022-08-17
http://wtbis.cn/doc/workerman/faq/processes-count.html 現(xiàn)在我的是8核16 是6，按照文檔來(lái)就算一個(gè)經(jīng)常50m，我也可以設(shè)置10，文檔說(shuō)*2都可以，感覺(jué)好浪費(fèi)
你這個(gè)業(yè)務(wù)和連接池沒(méi)關(guān)系，是業(yè)務(wù)設(shè)計(jì)的問(wèn)題；
業(yè)務(wù)設(shè)計(jì)建議使用異步的思路，把阻塞等待的時(shí)間用于接收請(qǐng)求，其實(shí)這個(gè)過(guò)程就是消息隊(duì)列的過(guò)程；可以使用比如webhook、消息隊(duì)列、分布式事務(wù)等達(dá)到這個(gè)效果；
連接池需要線程，PHP沒(méi)有線程；連接池?cái)?shù)量也有上限，一旦達(dá)到上限，一樣會(huì)阻塞；
你說(shuō)的這個(gè)問(wèn)題，歸根結(jié)底和TCP的隊(duì)頭阻塞原理是一樣的。
- 暫無(wú)評(píng)論
如果每個(gè)php進(jìn)程都開(kāi)一個(gè)連接池，感覺(jué)占用的mysql連接更多。本來(lái)一個(gè)進(jìn)程一個(gè)mysql連接，php內(nèi)部開(kāi)了連接池導(dǎo)致每個(gè)進(jìn)程建立N個(gè)數(shù)據(jù)庫(kù)連接。假設(shè)每個(gè)進(jìn)程的連接池開(kāi)10個(gè)mysql連接，100個(gè)進(jìn)程本來(lái)需要100個(gè)mysql連接，現(xiàn)在需要1000個(gè)mysql連接了。連接數(shù)就更多了。
除非你用那種統(tǒng)一的連接池服務(wù)，類似一個(gè)獨(dú)立的mysql代理服務(wù)。webman連接代理服務(wù)，代理服務(wù)連接mysql。代理服務(wù)控制自己與mysql的總連接數(shù)，這樣webman和代理服務(wù)之間的連接數(shù)不限制。
我覺(jué)得最好用隊(duì)列來(lái)處理這些慢業(yè)務(wù)。如果無(wú)法用隊(duì)列，可以開(kāi)一些進(jìn)程專門(mén)做這些慢業(yè)務(wù)的接口。
- 暫無(wú)評(píng)論
你這個(gè)問(wèn)題是在請(qǐng)求第三方接口太耗時(shí)了（800~1200ms），問(wèn)題不是在MySQL吧。如果是golang就很好辦
-
-
-
ontheway 2022-08-19
好像沒(méi)什么好的辦法，只能多開(kāi)進(jìn)程，或者看可不可以把接口搞成異步的
你這個(gè)業(yè)務(wù)不耗cpu，時(shí)間都耗在了等待網(wǎng)絡(luò)接口請(qǐng)求返回上了，cpu不需要這么多，這個(gè)業(yè)務(wù)體現(xiàn)不出workerman的優(yōu)勢(shì)，還不如用php-fpm，多開(kāi)點(diǎn)進(jìn)程，用php-fmp的好處是，用了mysql馬上就釋放掉了，你在請(qǐng)求第三方接口的時(shí)候就不會(huì)占用mysql連接了
多線程+同步模型處理低CPU開(kāi)銷+高IO延遲的場(chǎng)景，什么時(shí)候掛取決于worker線程的最大數(shù)量，因?yàn)樗械木€程最終都會(huì)占用掉，然后資源不足gg。和語(yǔ)言的關(guān)系反而不大了，你換最慢的python也一樣
這個(gè)場(chǎng)景下,FPM反而會(huì)比Webman好,畢竟請(qǐng)求結(jié)束資源就釋放了...[嘆氣]
兄弟直接用golang吧，golang的協(xié)程很好的解決了這個(gè)問(wèn)題。
比如，你使用golang的gin框架，因?yàn)間in把每個(gè)連接都丟給了一個(gè)協(xié)程去處理，cpu不會(huì)消耗在等待網(wǎng)絡(luò)請(qǐng)求上，很好的解決了你的這個(gè)問(wèn)題，既不耗cpu，也不耗內(nèi)存，一個(gè)2核4G的服務(wù)器就可以滿足要求。
-
-
happy321 2022-08-25go里面json解析 操作數(shù)據(jù)庫(kù) 是不是都要先定義 字段和類型的結(jié)構(gòu)體？這樣工作量會(huì)不會(huì)比較多？
-
ontheway 2022-08-26
是要定義結(jié)構(gòu)體，json解析比較簡(jiǎn)單，你把json數(shù)據(jù)復(fù)制到goland ide里面，然后選中，右鍵有菜單可以直接將json轉(zhuǎn)為結(jié)構(gòu)體，也有在線轉(zhuǎn)的工具，比如https://utils.fun/go-struct-json
goland里面有個(gè)插件，可以將json和sql轉(zhuǎn)化為結(jié)構(gòu)體
https://plugins.jetbrains.com/plugin/14409-convert-json-sql-to-go-struct -
-
打賞
這個(gè)不是連接池能解決的問(wèn)題，除非是單獨(dú)開(kāi)一個(gè)專門(mén)的連接池服務(wù)，否則每個(gè)進(jìn)程都開(kāi)個(gè)連接池，那么占用的連接數(shù)會(huì)更多。
這個(gè)解決方案有挺多，
方案一、最簡(jiǎn)單的讓php-fpm去處理這些慢請(qǐng)求。
方案二、webman開(kāi)一組自定義進(jìn)程，利用 workerman/http-client 去處理
方案三、webman1.4支持新開(kāi)http進(jìn)程，讓慢請(qǐng)求到專門(mén)的進(jìn)程里去處理，參考 http://wtbis.cn/q/9067
方案四、弄個(gè)中間件，每次執(zhí)行完關(guān)閉mysql連接
方案五、專門(mén)啟動(dòng)一個(gè)mysql代理服務(wù)，連接mysql改成連接mysql代理
-
fenger 2023-03-31workman/webman 如果除了固定進(jìn)程數(shù)，新增進(jìn)程數(shù)管理方式類似fpm【動(dòng)態(tài)進(jìn)程數(shù)】比如這樣可設(shè)置： max_children(最大進(jìn)程數(shù))、start_servers(起始進(jìn)程數(shù))、min_spare_servers(最小空閑進(jìn)程數(shù))、max_servers(最大空閑進(jìn)程數(shù))，會(huì)不會(huì)能解決題主的問(wèn)題呢？這樣會(huì)不會(huì)對(duì)性能影響大？
-
