webman-json-rpc

威爾 2024-03-26

問(wèn)題描述

各位大佬、前輩好，剛從tp轉(zhuǎn)wbeman，性能確實(shí)提升不少。但最近發(fā)現(xiàn)一個(gè)小問(wèn)題，有2臺(tái)服務(wù)器，服務(wù)器a是從服務(wù)器b拿數(shù)據(jù)，服務(wù)器b做rpc遠(yuǎn)程調(diào)用獲取數(shù)據(jù)。服務(wù)器b單機(jī)壓力測(cè)試用wrk壓測(cè)能到3w-4w，然后壓測(cè)服務(wù)器a從服務(wù)器b獲取數(shù)據(jù)，采用tcp傳輸大概8000左右，采用udp傳輸大概16000左右。距離原本的性能差距有點(diǎn)大?。▋?nèi)網(wǎng)帶寬是1.5g，跑了大概最多一半左右），性能大概只有一半左右，所以不知道是不是自己那里操作不對(duì)的，還是原本大概只能到這個(gè)瓶頸。所以才有http2、grpc（基于所以才有http2）這種

為此你搜索到了哪些方案

參考過(guò)大佬的
http://wtbis.cn/q/6057

 1125  3 0

3個(gè)回答

army 2024-03-26

肯定會(huì)有損耗的，改成text協(xié)議試試看

威爾 2024-03-28

試過(guò)了，text協(xié)議會(huì)快一點(diǎn)點(diǎn)，但沒(méi)有udp快

suse 2024-03-27

應(yīng)該是沒(méi)有復(fù)用tcp連接吧

威爾 2024-03-28

這個(gè)有想過(guò)，后面有復(fù)用的，用靜態(tài)變量去存在這個(gè)連接，然后判斷復(fù)用，會(huì)有所提升。但距離原本的性能還差40%左右。可能國(guó)內(nèi)用php做rpc比較少吧，以為有大神注意到這個(gè)問(wèn)題
威爾 2024-03-28

總結(jié)，假如想要接近原本的性能方法建議是用戶-> nginx（轉(zhuǎn)發(fā)）->rpc服務(wù)器（rpc服務(wù)器->nginx->用戶）這樣性能應(yīng)該高一點(diǎn)，rpc一般是用戶->nginx->服務(wù)器A->服務(wù)器B（rpc），服務(wù)器B（rpc）->服務(wù)器A->nginx->用戶，過(guò)長(zhǎng)長(zhǎng)了，可能損耗在這里了
qqxxr 2024-03-28

估計(jì)就是這樣，你可以把你壓測(cè)的命令分別貼出來(lái)的，可能就是壓測(cè)姿勢(shì)不對(duì)的
qqxxr 2024-03-28

估計(jì)就是這樣，你可以把你壓測(cè)的命令分別貼出來(lái)的
威爾 2024-03-28

壓測(cè)服務(wù)器B（rpc）ab -n 50000 -c 1000 -k http://xxx.xxx.xxx.xxx:9501/goods/information
壓測(cè)服務(wù)器B（rpc）wrk -c 1000 -d 10s http://xxx.xxx.xxx.xxx:9501/goods/information

壓測(cè)服務(wù)器A到服務(wù)器B獲取數(shù)據(jù) ab -n 50000 -c 1000 -k http://xxx.xxx.xxx.xxx:9501/goods/information
壓測(cè)服務(wù)器A到服務(wù)器B獲取數(shù)據(jù) wrk -c 1000 -d 10s http://xxx.xxx.xxx.xxx:9501/goods/information
qqxxr 2024-03-28

你壓測(cè)的本機(jī)的時(shí)候，用的是IP還是域名
威爾 2024-03-28

肯定ip啊
qqxxr 2024-03-28

IP就不走nginx
威爾 2024-03-28

也可以說(shuō)不走吧，正常是走的（用戶->nginx->服務(wù)器A->服務(wù)器B（rpc）），因?yàn)槲沂菈簻y(cè)，這里相當(dāng)于少了一步變（用戶->服務(wù)器A->服務(wù)器B（rpc））
nitron 2024-03-28

wrk B 直接client是B的性能
wrk A->B A要發(fā)送請(qǐng)求B,A接受B響應(yīng),A再響應(yīng)client,必定是有損耗的
威爾 2024-03-28

是的，知道必然會(huì)有損耗的，只是想了解有更好的方案可以降低損耗嗎
qqxxr 2024-03-28

那你自己都解答了呀，寶
qqxxr 2024-03-28

nginx調(diào)優(yōu)你沒(méi)弄吧，只要多一層這個(gè)，就必?fù)p耗。還有帶寬問(wèn)題
威爾 2024-03-28

發(fā)這個(gè)貼，主要想了解大家有木有更好的方案，能降低損耗……
nitron 2024-03-28

沒(méi)有,節(jié)點(diǎn)鏈路越長(zhǎng),損耗就越多,要么直連,要么換語(yǔ)言
跟網(wǎng)絡(luò)一樣,距離越遠(yuǎn),信號(hào)衰減越明顯
威爾 2024-03-28

噢噢，好的

xiuwang 2024-03-28

進(jìn)程數(shù)可能不夠，A B服務(wù)器進(jìn)程數(shù)都開成cpu核數(shù)的4-8倍試下。
B服務(wù)器肯定能支持3-4W，問(wèn)題是A服務(wù)器發(fā)起的請(qǐng)求量不夠，多加兩臺(tái)A服務(wù)器應(yīng)該會(huì)提升。
A服務(wù)器要響應(yīng)客戶端，又要請(qǐng)求B服務(wù)器，性能減半很正常，如果A短鏈接請(qǐng)求B性能會(huì)再次減少一半左右，也就是大概8000。

威爾 2024-03-29

試了一下，跟進(jìn)程數(shù)無(wú)關(guān)，開多了反而下降了，假如服務(wù)器性能比較高，增加A服務(wù)器發(fā)起的請(qǐng)求量確實(shí)會(huì)有所提升，假如服務(wù)器A帶寬100m，用戶->服務(wù)器A->服務(wù)器B，能有8000的話帶寬翻倍的話，大概能到16000QPS吧。這個(gè)是我19的時(shí)候遇到過(guò)的，不過(guò)這次不同的是請(qǐng)求rpc，以前是直接轉(zhuǎn)發(fā)到其他服務(wù)器