常用商品查詢接口每個并發(fā)100后查詢速度下降

TM 2023-07-03

請問一下大佬們，對于常用的查詢商品接口，因為經(jīng)常改變數(shù)據(jù)沒存入緩存，并發(fā)100每個接口同時查詢，帶寬基本拉到3-4M左右目前是5M寬帶，CPU和內(nèi)存沒怎么變化，有什么辦法優(yōu)化速度嗎

 1212  5 2

5個回答

TM 2023-07-03

目前分類數(shù)據(jù)已經(jīng)存緩存了除了用戶的商品數(shù)據(jù)沒存

暫無評論

TM 2023-07-03

查看數(shù)據(jù)庫慢日志并沒有慢的，查看查詢速度基本都是20-50毫秒

暫無評論

six 2023-07-03

外網(wǎng)壓測網(wǎng)絡(luò)是瓶頸，5M帶寬壓不出什么的，太低了。

1、加大帶寬
2、加大并發(fā)，例如100并發(fā)改成500甚至更多
3、轉(zhuǎn)為內(nèi)網(wǎng)或本機壓測，排除帶寬問題

apipost本身有一些bug，有時候無法達到最大壓力，最好用ab或者其它專業(yè)的壓測軟件。

TM 2023-07-03

測試了服務(wù)器本地AD了，挺快的但是處理速度很快
TM 2023-07-03

像這種客戶訪問的帶寬一下子就滿了只能加帶寬嗎
walkor 2023-07-03

優(yōu)化業(yè)務(wù)減少返回數(shù)據(jù)的大小。nginx開啟gzip壓縮，減少帶寬消耗。以上都做了的話就只能加帶寬了
TM 2023-07-03

試了一下本地單個接口1W并發(fā)也沒啥問題，但是跑域名訪問就不太行跑域名訪問500個并發(fā)一半訪問量需要11秒才能響應(yīng)
TM 2023-07-03

業(yè)務(wù)數(shù)據(jù)已經(jīng)控制到需要什么才返回什么了，主要這個接口返回商品輪播圖，不過輪播圖已經(jīng)用cos流量了
walkor 2023-07-03

網(wǎng)絡(luò)或者帶寬是瓶頸
TM 2023-07-03

已經(jīng)開啟了gzip壓縮了跑別的接口還行，這個商品接口數(shù)據(jù)比較多難搞
walkor 2023-07-03

升級帶寬
TM 2023-07-03

算了不行只能加寬帶了，讓老板給錢
tanhongbin 2023-07-03

你這是前后端分離嘛？還是渲染的？要是渲染的更完蛋
TM 2023-07-03

嗯嗯前后端分離的
tanhongbin 2023-07-03

前端放在云上后端就一個接口返回數(shù)據(jù)不大，不應(yīng)該呀
TM 2023-07-03

前端放在另一個服務(wù)器上面了，現(xiàn)在直接域名壓測服務(wù)器拉不滿，CPU和內(nèi)存沒動多少，流量一直拉上去，看日志查詢速度都在幾十毫秒的，感覺很多請求都沒進來
tanhongbin 2023-07-03

非常明顯的帶寬問題了，只能壓縮試試了，我估計你前端靜態(tài)頁面都沒上去，所以不是后端的問題
TM 2023-07-03

先繼續(xù)用一下，現(xiàn)在能撐住，不行再加寬帶了
tanhongbin 2023-07-03

嗯嗯，最好把前端放在云上，他們帶寬比較猛，走流量就行1個T 8毛吧
TM 2023-07-03

ok 我上去喵喵
TM 2023-07-03

有推薦嗎
tanhongbin 2023-07-03

云就隨便了
TM 2023-07-03

好的

TM 2023-07-03

暫無評論

MarkGo 2023-07-03

我也是同樣場景問題，
產(chǎn)品詳情，由於包含了子商品數(shù)據(jù)和日曆價。
接口數(shù)據(jù)平均40kb大小，服務(wù)器5M帶寬，大概15個併發(fā)就滿了。

1、開啟gzip
壓縮后數(shù)據(jù)大概8kb左右，併發(fā)能達到60左右；

2、優(yōu)化前端場景
日曆價改為只加載當(dāng)月的，分離出日曆接口，改變?nèi)掌跁r候才加載其他月份的，數(shù)據(jù)量沒什麼變化，減輕了db壓力而已。

3、cdn
項目有部署CDN，接口之前沒走CDN，但是後來把接口也接入了CDN。
CDN進行回源配置，
list接口緩存3天。
detail接口緩存15天。
其餘接口不緩存。
另外項目後臺如果修改的話調(diào)用CDN的API刷新一次CDN數(shù)據(jù)。
暫時發(fā)現(xiàn)缺點是海外用戶含港澳臺的訪問，偶爾出現(xiàn)異常。