場(chǎng)景：調(diào)用的接口邏輯：根據(jù)用戶ID從緩存查詢一批數(shù)據(jù)id（每次30），然后拼裝數(shù)據(jù)返回這批數(shù)據(jù)。接口壓測(cè)目標(biāo)：模擬200個(gè)用戶并發(fā)去訪問這個(gè)接口（雖然是并發(fā)，但每個(gè)用戶取的都是從自己的緩存取數(shù)據(jù)）由于測(cè)試某種原因，無法真實(shí)模擬 200個(gè)用戶去訪問，所以換了一種方式：起200個(gè)線程，然后并發(fā)去訪問同一個(gè)用戶的接口（也就是200個(gè)用戶并發(fā)去取同一個(gè)用戶的緩存）結(jié)果：壓測(cè)出來，接口qps比較低問題：這種模擬合適嗎，redis緩存有并發(fā)瓶頸嗎？（正常壓測(cè)應(yīng)該 起200個(gè)線程，然后去并發(fā)訪問200個(gè)用戶的緩存（同一個(gè)接口），相當(dāng)于200個(gè)用戶同時(shí)去訪問自己的緩存）
2 回答
慕哥9229398
TA貢獻(xiàn)1877條經(jīng)驗(yàn) 獲得超6個(gè)贊
這個(gè)……我不是測(cè)試，所以也不知道怎樣分析。
但感覺200并發(fā)量并不大啊，只要機(jī)器性能不是太差（CPU、內(nèi)存、磁盤IO），而且又是緩存（根據(jù)你的場(chǎng)景，單次傳輸?shù)臄?shù)據(jù)量也不大），幾乎沒什么壓力可言。
慕無忌1623718
TA貢獻(xiàn)1744條經(jīng)驗(yàn) 獲得超4個(gè)贊
樓主的壓測(cè)方案?jìng)€(gè)人感覺沒有什么問題,正常的壓測(cè)應(yīng)該是隨機(jī)取不同用戶的
Id去訪問正常情況下
redis的QPS達(dá)到幾萬是沒有什么問題的,如果是redis集群的話,用同一個(gè)用戶Id測(cè)試就會(huì)落到同一臺(tái)機(jī)器上,而redis是單線程給的,所以在一定程度上會(huì)影響測(cè)試的性能按照道理來說,200并發(fā)如果返回的數(shù)據(jù)量小的話
QPS不會(huì)很低,建議從以下方面排查是否使用的
redis的線程池redis里面存儲(chǔ)的數(shù)據(jù)接口是是什么,考慮一下各種數(shù)據(jù)結(jié)構(gòu)的查詢復(fù)雜度統(tǒng)計(jì)各個(gè)步驟所需要的具體時(shí)間,比如說從本地到接口時(shí)間
T1,接口邏輯處理T2,接口請(qǐng)求redis得到數(shù)據(jù)T3,接口邏輯處理T4,接口返回本地T5,統(tǒng)計(jì)一下具體在哪一步耗時(shí)長可以減少并發(fā)線程數(shù)和增加線程數(shù),觀察一下
QPS的情況觀察服務(wù)器的線程情況(看看有沒有鎖競(jìng)爭(zhēng)),GC情況,CPU,網(wǎng)卡流量等等性能,觀察下硬件是否有瓶頸
- 2 回答
- 0 關(guān)注
- 2333 瀏覽
添加回答
舉報(bào)
0/150
提交
取消