webman-json-rpc

威爾 2024-03-26

問題描述

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

為此你搜索到了哪些方案

參考過大佬的
http://www.wtbis.cn/q/6057

 1137  3 0

3個回答

army 2024-03-26

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

威爾 2024-03-28

試過了，text協(xié)議會快一點點，但沒有udp快

suse 2024-03-27

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

威爾 2024-03-28

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

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

估計就是這樣，你可以把你壓測的命令分別貼出來的，可能就是壓測姿勢不對的
qqxxr 2024-03-28

估計就是這樣，你可以把你壓測的命令分別貼出來的
威爾 2024-03-28

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

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

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

肯定ip啊
qqxxr 2024-03-28

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

也可以說不走吧，正常是走的（用戶->nginx->服務(wù)器A->服務(wù)器B（rpc）），因為我是壓測，這里相當(dāng)于少了一步變（用戶->服務(wù)器A->服務(wù)器B（rpc））
nitron 2024-03-28

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

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

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

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

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

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

噢噢，好的

xiuwang 2024-03-28

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

威爾 2024-03-29

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