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