2021年3月30日 星期二

JMeter 的 QPS 上不去

紀錄一下最近用 JMeter 做效能測試時遇到的小問題。

之前本來在測試效能時,因為會在測試環境進行,測試環境一般規模會比較小,所以相對地效能測試時打的流量也會比較少,大概都是打個 100~200 QPS 而已。不過這次遇到比較不一樣的狀況,我們需要在線上環境做測試,而且流量想要打高一點,結果就遇到 QPS 沒辦法往上拉的問題。

首先,測試的 script 裡設定的 Thread Group 是 1,000 個 thread,並且會用 Throughput Shaping Timer 來調整實際打出去的流量。script 跑在 AWS 上,使用的 VM 規格是 m5a.2xlarge。在 QPS ~300 左右時都還沒什麼問題,不過一往上拉到 350 QPS 以上時,就會開始出現 JMeter 顯示 response time 大幅地增加,但從 API 端觀察則看不出存在門檻,而且實際上我們日常的流量超過 350 QPS 很多…。

由於這個反應不太合理,畢竟我們平常實際運行的流量都高於 350 QPS,沒道理跑 350 QPS 的測試會卡住,更何況從 API monitoring 那邊觀察起來,API 的 response time 也很正常,並沒有如 JMeter 顯示的突然上升超過 20 倍,因此這時就開始懷疑有可能問題是出在 JMeter 這邊,像是來不及處理 response 之類的問題了。

接連做了幾個實驗、並且同時觀察 CPU 使用率後,發現一旦 QPS 超過 350 時,CPU 使用率會停留在大約 70% 左右的位置,這時多半 response time 會開始顯著地上升。因此初步認為有可能是 CPU 造成效能卡住了,而結果也確實是如此。在我把 VM 規格改為 CPU-intensive 的 c5a.2xlarge 之後,問題解決了,QPS 可以繼續往上增加,撞到了下一個門檻是大概 QPS 550…。

QPS 550 的這個門檻,觀察 CPU 使用率約莫是落在 50%~60%,看起來不太像是問題所在,因此又開始朝別的方向思考。CPU 不對的話,下一個可能就是記憶體了。此時觀察 top 顯示的整體記憶體使用率只有 2GB 出頭,但我的 c5a.2xlarge 應該有 16GB 可以使用才對,同時查到 JMeter 文件顯示預設的 heap size 是 1GB….。嗯~那就來調整 heap size 看看吧。

在 JMeter 資料夾中的 bin/jmeter 檔案裡,搜尋 HEAP 可以找到下面這一段描述:

# This is the base heap size -- you may increase or decrease it to fit your
# system's memory availability:
: "${HEAP:="-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m"}"

這裡顯示預設的 -Xms 和 -Xmx 都是 1GB,把它調大成想要的樣子,例如最少 8GB、最多 15GB,如下所示:

# This is the base heap size -- you may increase or decrease it to fit your
# system's memory availability:
: "${HEAP:="-Xms8g -Xmx15g -XX:MaxMetaspaceSize=256m"}"

然後~門檻就消失了,後續就順利地繼續把 QPS 往上拉到 1K 以上了。