據(jù)庫全指南：JDBC配置、參數(shù)化與并發(fā)實(shí)戰(zhàn))
1. 先想清楚壓數(shù)據(jù)庫和壓接口到底差在哪很多人用 JMeter 做接口測試、壓 Web 服務(wù)駕輕就熟。但一說到用 JMeter 直接壓數(shù)據(jù)庫不少人就懵了——數(shù)據(jù)庫也能用 JMeter 壓怎么連連上了能測啥先說結(jié)論不僅能壓而且非常好使。我在實(shí)際項(xiàng)目里既用 JMeter 壓過 MySQL、PostgreSQL也壓過 Oracle甚至給第三方數(shù)據(jù)中臺(tái)做過壓測靠的都是 JMeter 自帶的 JDBC 請求組件不需要裝任何額外插件。但有一個(gè)認(rèn)知必須先糾正用 JMeter 測數(shù)據(jù)庫不等于在數(shù)據(jù)庫客戶端里手動(dòng)執(zhí)行幾條 SQL 看返回時(shí)間。它做的是“模擬真實(shí)業(yè)務(wù)場景下大量并發(fā)請求同時(shí)打向數(shù)據(jù)庫”這件事——比如 100 個(gè)用戶同時(shí)登錄每個(gè)登錄動(dòng)作背后對應(yīng)著幾條 SQL這些 SQL 同時(shí)打到數(shù)據(jù)庫上數(shù)據(jù)庫扛不扛得住平均響應(yīng)時(shí)間多少有沒有慢查詢連接池會(huì)不會(huì)被打滿這才是壓數(shù)據(jù)庫的核心目的。所以這篇文章我不會(huì)只講“怎么連上數(shù)據(jù)庫”而是把 JMeter 測試數(shù)據(jù)庫的完整方法拆開揉碎環(huán)境準(zhǔn)備、JDBC 連接配置、JDBC Request 詳解、參數(shù)化傳值、斷言校驗(yàn)、并發(fā)場景搭建、常見問題排查一條龍講清楚。你照著做基本可以覆蓋日常工作中 90% 的數(shù)據(jù)庫壓測需求。適合誰看剛接觸 JMeter、想用它做數(shù)據(jù)庫壓測的測試新人被領(lǐng)導(dǎo)臨時(shí)派活、需要在兩天內(nèi)給出數(shù)據(jù)庫性能結(jié)論的測試工程師以及那些已經(jīng)會(huì)基本接口壓測、但沒系統(tǒng)搞過 JDBC 請求的老手?？赐昴阒辽倌塥?dú)立搭出一套帶參數(shù)化、帶斷言、帶并發(fā)模型的數(shù)據(jù)庫壓測腳本。2. 環(huán)境準(zhǔn)備驅(qū)動(dòng)、版本、連接方式一步都不能錯(cuò)2.1 先確認(rèn) JMeter 版本和 JDBC 驅(qū)動(dòng)開始之前先確認(rèn)你的 JMeter 版本。我這邊用的是 JMeter 5.xJDBC 請求相關(guān)的組件從 3.x 就有界面和配置項(xiàng)基本一致所以你用 4.x 或 5.x 都行不用太糾結(jié)版本。關(guān)鍵在于JDBC 驅(qū)動(dòng) Jar 包。JMeter 本身不自帶數(shù)據(jù)庫驅(qū)動(dòng)你必須手動(dòng)把對應(yīng)數(shù)據(jù)庫的驅(qū)動(dòng) Jar 包放到 JMeter 的lib目錄下然后重啟 JMeter 才能生效。常見數(shù)據(jù)庫對應(yīng)的驅(qū)動(dòng) Jar 包MySQLmysql-connector-java-8.0.x.jar如果你連的是 MySQL 5.x建議用 5.1.4x 版本MySQL 8.x 一定要用 8.0 版本的驅(qū)動(dòng)不然連接會(huì)報(bào)錯(cuò)。PostgreSQLpostgresql-42.x.x.jarOracleojdbc8.jar或ojdbc11.jar看你數(shù)據(jù)庫版本SQL Servermssql-jdbc-9.x.x.jar驅(qū)動(dòng)包放好之后重啟 JMeter然后用一個(gè)最簡單的 JDBC 請求驗(yàn)證一下能不能連上。別一上來就搞復(fù)雜場景連接都不通的話后面全是白搭。2.2 JDBC 驅(qū)動(dòng)類名和連接 URL別記混了很多新手死在第一步就是驅(qū)動(dòng)類名和 URL 寫錯(cuò)。這里直接給你一份對照表抄作業(yè)就行數(shù)據(jù)庫JDBC Driver ClassJDBC URL 格式MySQLcom.mysql.jdbc.Driver5.x/com.mysql.cj.jdbc.Driver8.xjdbc:mysql://127.0.0.1:3306/testdb?useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/ShanghaiPostgreSQLorg.postgresql.Driverjdbc:postgresql://127.0.0.1:5432/testdbOracleoracle.jdbc.OracleDriverjdbc:oracle:thin:127.0.0.1:1521/ORCLSQL Servercom.microsoft.sqlserver.jdbc.SQLServerDriverjdbc:sqlserver://127.0.0.1:1433;DatabaseNametestdb注意 MySQL 這里有兩個(gè)坑第一MySQL 5.x 和 8.x 的 Driver Class 不一樣。8.x 是com.mysql.cj.jdbc.Driver不是com.mysql.jdbc.Driver寫錯(cuò)直接報(bào)ClassNotFoundException。第二MySQL 8.x 連接 URL 里建議加上useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/Shanghai。不加 serverTimezone 會(huì)報(bào)時(shí)區(qū)錯(cuò)誤不加 allowPublicKeyRetrieval 會(huì)在某些認(rèn)證方式下報(bào)Public Key Retrieval is not allowed。這兩個(gè)參數(shù)我每次都會(huì)帶上省得排查半天。經(jīng)驗(yàn)我一般會(huì)在連接 URL 里額外加一個(gè)connectTimeout5000socketTimeout10000避免數(shù)據(jù)庫掛了之后線程一直卡在等待上壓測時(shí)能很快暴露連接超時(shí)問題。比如jdbc:mysql://127.0.0.1:3306/testdb?useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/ShanghaiconnectTimeout5000socketTimeout100002.3 環(huán)境驗(yàn)證用一個(gè)最簡單的查詢打通鏈路驅(qū)動(dòng)放好、配置想清楚了先做個(gè)連通性測試——在 JMeter 里建一個(gè)測試計(jì)劃加一個(gè) JDBC Connection Configuration再選一個(gè)庫建一個(gè)線程池跑一條SELECT 1如果返回正常鏈路就通了。這一步別看簡單它價(jià)值很大能一次性排除驅(qū)動(dòng)、URL、賬號(hào)密碼、網(wǎng)絡(luò)四個(gè)環(huán)節(jié)的問題。如果SELECT 1都跑不通那后面再復(fù)雜的腳本也跑不通不如先在這里把問題解決掉。3. JDBC Connection Configuration連接池配置才是壓測的關(guān)鍵3.1 配置項(xiàng)逐行拆解JDBC Connection Configuration 是 JDBC 請求的前置條件相當(dāng)于給所有 JDBC 請求提供數(shù)據(jù)庫連接池。它不是一個(gè)“填個(gè) URL 就行”的簡單配置每個(gè)選項(xiàng)背后都有講究。關(guān)鍵的幾個(gè)配置項(xiàng)Variable Name for created pool連接池變量名隨便起比如db_pool但你要記死它因?yàn)?JDBC Request 里要通過這個(gè)名字來引用這個(gè)連接池。一個(gè)測試計(jì)劃里可以配置多個(gè)連接池給不同庫用靠名字區(qū)分。Max Number of Connections最大連接數(shù)。這個(gè)值很關(guān)鍵它決定了 JMeter 能同時(shí)從池里拿多少個(gè)連接。如果你壓 100 個(gè)并發(fā)但最大連接數(shù)只有 10那 JMeter 的請求就會(huì)排隊(duì)等連接測出來的結(jié)果不是數(shù)據(jù)庫的真實(shí)瓶頸而是連接池的瓶頸。Max Wait最大等待時(shí)間單位毫秒。連接池沒空閑連接時(shí)請求最多等多久超時(shí)拋異常。一般設(shè) 10000。Time Between Eviction Runs清理線程運(yùn)行間隔。JMeter 會(huì)定期清理空閑過久的連接一般設(shè) 60000。Auto Commit自動(dòng)提交。只做查詢壓測時(shí)設(shè) True 就好涉及事務(wù)、插入、更新時(shí)按需改成 False。Transaction Isolation事務(wù)隔離級(jí)別默認(rèn) DEFAULT 即可不用特別改。Pool Validation Query連接有效性檢查 SQL。MySQL 下寫SELECT 1PostgreSQL 下寫SELECT 1Oracle 下寫SELECT 1 FROM DUAL。JMeter 每次從池里拿連接時(shí)可以用這個(gè) SQL 驗(yàn)證連接是否還活著避免拿到失效連接。3.2 連接池參數(shù)怎么定一個(gè)簡單的估算方法連接池最大連接數(shù)怎么定很多教程會(huì)說“設(shè)大一點(diǎn)就行”但實(shí)際不是這么回事。連接數(shù)設(shè)太大數(shù)據(jù)庫可能會(huì)因?yàn)椴l(fā)連接過多直接拒絕服務(wù)設(shè)太小JMeter 這邊又會(huì)排隊(duì)。我的做法是連接池最大連接數(shù) 目標(biāo)并發(fā)線程數(shù)。比如你要模擬 100 個(gè)用戶并發(fā)那么 Max Number of Connections 就設(shè) 100 或略大于 100比如 100。這樣每個(gè)線程拿到一個(gè)獨(dú)立連接不會(huì)出現(xiàn)兩個(gè)線程搶一個(gè)連接的情況。這里有個(gè)容易混淆的細(xì)節(jié)JMeter 的線程數(shù)和連接池連接數(shù)不是一一綁定的關(guān)系。線程可以復(fù)用連接但如果你想測的是“數(shù)據(jù)庫在 100 個(gè)并發(fā)連接下的表現(xiàn)”那連接數(shù)就必須給夠否則測出來的曲線是連接池排隊(duì)曲線不是數(shù)據(jù)庫性能曲線。3.3 為什么要用連接池而不是每個(gè)線程單獨(dú)連JMeter 里還有一種做法是每個(gè)線程自己創(chuàng)建數(shù)據(jù)庫連接不用連接池——比如用 BeanShell 或者 JSR223 寫代碼去DriverManager.getConnection()。我不推薦這種方式做壓測原因有兩個(gè)第一性能差。每次請求都重新創(chuàng)建連接開銷全花在 TCP 握手和認(rèn)證上測出來的響應(yīng)時(shí)間虛高。第二資源不可控。并發(fā) 100 個(gè)線程同時(shí)創(chuàng)建 100 個(gè)連接壓測機(jī)本身的文件描述符、內(nèi)存壓力都會(huì)變大干擾結(jié)果。所以標(biāo)準(zhǔn)做法就是一個(gè) JDBC Connection Configuration 管連接池N 個(gè) JDBC Request 從池里取連接執(zhí)行 SQL。連接池的創(chuàng)建、復(fù)用、回收J(rèn)Meter 都在底層幫你處理好了你要做的就是配置好那幾項(xiàng)參數(shù)。4. JDBC Request 詳解增刪改查都能壓4.1 SQL 查詢和變量名規(guī)則JDBC Request 是真正執(zhí)行 SQL 的地方。它長得很像一個(gè) HTTP 請求 Sample但參數(shù)完全不同。核心參數(shù)有三個(gè)Variable Name of Pool declared in JDBC Connection Configuration填連接池變量名也就是你在 JDBC Connection Configuration 里填的那個(gè)名字。如果這里填錯(cuò)JMeter 會(huì)直接報(bào)錯(cuò)找不到連接池。Query TypeSQL 類型有 Select Statement、Update Statement、Callable Statement、Prepared Select Statement、Prepared Update Statement 等。如果是普通查詢用 Select Statement如果 SQL 里有占位符?必須用 Prepared Select Statement 或 Prepared Update Statement。QuerySQL 語句本體。這里有個(gè)新手高頻疑問Query Type 選 Select Statement 和 Prepared Select Statement 有什么區(qū)別區(qū)別在占位符。如果你要執(zhí)行SELECT * FROM user WHERE id ?就必須用 Prepared Select Statement然后通過參數(shù)列表傳入?的值。如果你執(zhí)行的是完整 SQL沒有?用 Select Statement 就行。相同點(diǎn)是結(jié)果都存放在變量里供后續(xù)使用。4.2 查詢結(jié)果的三種用法JDBC Request 執(zhí)行完之后結(jié)果存在哪答案是JMeter 會(huì)把結(jié)果集存到變量里變量名規(guī)則是你在 JDBC Request 里填的Variable Name。比如你在 JDBC Request 的 Variable Name 填了mysql_result那么執(zhí)行完查詢后mysql_result整個(gè)結(jié)果集mysql_result_#結(jié)果集行數(shù)比如返回 10 行這個(gè)變量值就是 10mysql_result_1第一行數(shù)據(jù)mysql_result_1_id第一行的 id 字段值mysql_result_2_id第二行的 id 字段值用Variable Name 下劃線 行號(hào) 下劃線 列名這個(gè)規(guī)則就能取到任意一行任意一列的值。這個(gè)特性相當(dāng)有用。最常見的場景是你從表 A 查到一批訂單 ID然后要把這些 ID 作為參數(shù)傳給下一個(gè) JDBC Request 或 HTTP 請求。具體做法就是先執(zhí)行一條查詢 SQL然后在下一個(gè)請求里用${mysql_result_1_id}來引用第一行 ID。4.3 實(shí)際案例查詢用戶表數(shù)據(jù)我來演示一個(gè)最簡單的例子。假設(shè)數(shù)據(jù)庫里有一張user表字段有id、username、age我想壓測一條查詢 SQLSELECT id, username, age FROM user WHERE age 20配置如下JDBC Request Variable Nameuser_resultQuery TypeSelect StatementQuerySELECT id, username, age FROM user WHERE age 20跑完之后在察看結(jié)果樹里可以看到這個(gè) JDBC Request 的響應(yīng)數(shù)據(jù)里面是查到的所有行。如果你想把這批數(shù)據(jù)取出來給后續(xù)請求用比如遍歷前 10 個(gè)用戶 ID就可以用${user_result_1_id}、${user_result_2_id}這種形式去引用。注意結(jié)果集會(huì)按位置存儲(chǔ)mysql_result_1是第 1 行mysql_result_2是第 2 行以此類推。如果你查詢結(jié)果本身有排序需求在 SQL 里把ORDER BY寫好否則取出來的行順序可能不穩(wěn)定。4.4 執(zhí)行更新操作怎么配置壓測不光是查詢有時(shí)也要模擬寫入、更新的業(yè)務(wù)壓力。比如 100 個(gè)用戶同時(shí)更新自己的資料。如果是帶參數(shù)的更新比如UPDATE user SET age ? WHERE id ?那么 Query Type 要選Prepared Update StatementSQL 里的?是占位符需要通過“Parameter values”和“Parameter types”傳入實(shí)際值。這里有個(gè)重要細(xì)節(jié)執(zhí)行 Update/Insert/Delete 操作時(shí)如果數(shù)據(jù)庫沒有返回結(jié)果集JMeter 會(huì)返回受影響的行數(shù)。比如某個(gè) UPDATE 影響了 3 行JMeter 的響應(yīng)數(shù)據(jù)里會(huì)顯示3。如果你想驗(yàn)證更新是否成功一種做法是更新后再執(zhí)行一條 SELECT 去查這條數(shù)據(jù)配合斷言來校驗(yàn)。5. 參數(shù)化取值讓壓測數(shù)據(jù)動(dòng)起來5.1 CSVDataset 參數(shù)化每個(gè)線程分塊取值做數(shù)據(jù)庫壓測時(shí)你常常需要模擬“不同的用戶操作不同的數(shù)據(jù)”而不是 100 個(gè)用戶都查同一條記錄。前者才是真實(shí)業(yè)務(wù)場景也能更有效地壓出數(shù)據(jù)庫的查詢能力。JMeter 里最常用的參數(shù)化方式就是CSV 數(shù)據(jù)集配置CSV Data Set Config。它允許你從一個(gè) CSV 文件里按行讀取數(shù)據(jù)然后把每一列的值賦給變量。配置的時(shí)候有幾點(diǎn)要注意FilenameCSV 文件路徑Variable Names列名用英文逗號(hào)分隔比如id,username,ageDelimiter分隔符默認(rèn)是英文逗號(hào)Recycle on EOF讀完最后一行后是否回到開頭繼續(xù)讀。如果你壓測時(shí)長較長或者并發(fā)數(shù)大于 CSV 行數(shù)建議設(shè) True否則讀到末尾線程會(huì)直接結(jié)束或報(bào)錯(cuò)。Stop thread on EOF讀完最后一行是否停止線程。如果 Recycle on EOF 是 True這個(gè)就設(shè) False。Sharing mode共享模式。默認(rèn) All threads 是所有線程共享一個(gè)文件指針按順序往下讀如果你想每個(gè)線程各讀各的可以選 Current thread。我在實(shí)際項(xiàng)目里壓“100 并發(fā)用戶登錄”時(shí)會(huì)準(zhǔn)備一個(gè) 100 行的 CSV每行一個(gè)用戶 ID 和密碼然后把線程組并發(fā)數(shù)設(shè)為 100CSV 共享模式用默認(rèn)的 All threads這樣每個(gè)線程拿到一個(gè)不同的用戶數(shù)據(jù)誰也不會(huì)搶。5.2 從上一個(gè)查詢結(jié)果取參JDBC 請求結(jié)果復(fù)用CSV 適合數(shù)據(jù)預(yù)先準(zhǔn)備好的場景但有些場景數(shù)據(jù)是動(dòng)態(tài)生成的——你先要查一下有哪些訂單然后針對每個(gè)訂單做后續(xù)操作。這種時(shí)候就要用 JDBC Request 的查詢結(jié)果來做參數(shù)化。思路是先跑一條 SELECT把結(jié)果存到一個(gè)變量里然后在后一個(gè)請求里用${var_行號(hào)_列名}去引用。舉個(gè)例子第一步JDBC Request 查訂單 IDSELECT order_id, amount FROM orders WHERE status pending這個(gè) JDBC Request 的 Variable Name 設(shè)為order_result。第二步在 HTTP 請求或下一個(gè) JDBC Request 里引用訂單 ID${order_result_1_order_id} 訂單金額${order_result_1_amount}這樣就實(shí)現(xiàn)了“把數(shù)據(jù)庫查出來的數(shù)據(jù)作為下一個(gè)接口的參數(shù)”這個(gè)高頻需求。但如果查詢返回了多行而你希望循環(huán)處理每一行數(shù)據(jù)那還是建議配合ForEach 控制器來做。ForEach 控制器可以遍歷一個(gè)變量集合比如order_result下的所有行然后逐一執(zhí)行后續(xù)請求。配置時(shí)輸入變量前綴order_result循環(huán)變量名隨便取一個(gè)比如current_order然后在后續(xù)請求里用${current_order_order_id}就能依次取到每一行的數(shù)據(jù)。5.3 JDBC 請求結(jié)果里的特殊變量行數(shù)和 NULL使用查詢結(jié)果時(shí)有兩個(gè)場景很容易踩坑。第一空結(jié)果集。如果 SQL 查不到數(shù)據(jù)order_result_#會(huì)是 0此時(shí)不能引用order_result_1_order_id否則 JMeter 會(huì)輸出一個(gè)空值。為了不報(bào)錯(cuò)可以搭配If 控制器判斷order_result_#是否大于 0再執(zhí)行后續(xù)邏輯。第二字段值本身是 NULL。比如某個(gè)字段在某些行里是 NULL引用之后得到的字符串是null而不是空字符串。如果你的下游接口對參數(shù)格式有嚴(yán)格要求需要在 BeanShell 或 JSR223 里做一個(gè) null 值替換處理否則接口調(diào)用可能會(huì)因?yàn)槎鄠髁薾ull字符串而報(bào)錯(cuò)。5.4 直接用 JSR223 腳本搞定更復(fù)雜的數(shù)據(jù)加工如果上面的方式都滿足不了需求比如你要對查出來的數(shù)據(jù)進(jìn)行 MD5 加密后作為參數(shù)傳給接口那就得上 JSR223 腳本了。JSR223 Sampler 里可以用 Groovy 直接查數(shù)據(jù)庫處理結(jié)果集生成任意格式的字符串。Groovy 的語法比 BeanShell 簡潔太多性能也更好是 JMeter 官方推薦的方式。雖然這篇文章主要講 JDBC Request 這種圖形化配置但在自定義邏輯非常復(fù)雜的時(shí)候JSR223 是終極兜底方案。簡單示例import java.sql.* // 獲取連接池里的連接 def conn vars.get(db_pool) // 這只是示意 // 真實(shí)的連接獲取可以通過 DataSource 或者直接用 JDBC 驅(qū)動(dòng)獲取這里省略不過說實(shí)話只有你需要寫復(fù)雜邏輯時(shí)才用 JSR223一般情況下 JDBC Request CSV 已經(jīng)能覆蓋絕大多數(shù)場景。過度使用 JSR223 反而會(huì)讓腳本難以維護(hù)。6. 斷言校驗(yàn)怎么證明數(shù)據(jù)庫返回是對的6.1 響應(yīng)斷言最快最直接的校驗(yàn)方式壓數(shù)據(jù)庫不是把 SQL 跑完就完事了你得確認(rèn)返回內(nèi)容是符合預(yù)期的。比如你查詢age 20的用戶結(jié)果返回里至少有數(shù)據(jù)行而不是空結(jié)果集或者一堆錯(cuò)誤信息。JMeter 的響應(yīng)斷言可以加到 JDBC Request 上用來校驗(yàn)響應(yīng)內(nèi)容。配置方式很簡單在 JDBC Request 上右鍵 → Add → Assertions → Response AssertionField to Test選 Text ResponsePattern Matching Rules選 ContainsPatterns to Test填你要校驗(yàn)的關(guān)鍵字比如查詢user表你想確認(rèn)結(jié)果里有username這個(gè)字段名就可以在響應(yīng)斷言里填username。如果響應(yīng)里沒有這個(gè)關(guān)鍵字?jǐn)嘌跃蜁?huì)失敗在聚合報(bào)告里會(huì)看到錯(cuò)誤率上升。這里有個(gè)技巧有時(shí)候 SQL 查出來的數(shù)據(jù)量很大響應(yīng)內(nèi)容很長你沒法直觀地看到是否有數(shù)據(jù)這時(shí)可以直接用響應(yīng)斷言校驗(yàn) “返回行數(shù)不為 0”。具體做法是把 SQL 改成SELECT COUNT(*) AS cnt FROM user WHERE age 20然后斷言響應(yīng)里包含cnt10或某個(gè)具體數(shù)字。注意JMeter 響應(yīng)里 COUNT 查詢的顯示格式是類似cnt10這樣的配合 Contains 斷言就能判斷數(shù)據(jù)量是否符合預(yù)期。6.2 BeanShell 斷言處理復(fù)雜校驗(yàn)邏輯響應(yīng)斷言只能做簡單匹配如果你要做復(fù)雜判斷比如“查詢結(jié)果里最大金額大于 1000”或“返回行數(shù)在某個(gè)區(qū)間內(nèi)”就得用 BeanShell 斷言或者 JSR223 斷言。JSR223 斷言可以用 Groovy 寫邏輯清晰多了。比如判斷結(jié)果集行數(shù)def rowCount vars.get(user_result_#).toInteger() if (rowCount 10) { // 失敗手動(dòng)設(shè)置斷言結(jié)果 AssertionResult.setFailure(true) AssertionResult.setFailureMessage(查詢結(jié)果集行數(shù)小于10實(shí)際為: rowCount) }這段腳本的邏輯是從 JMeter 變量里取user_result_#的值轉(zhuǎn)成整數(shù)判斷是否小于 10如果小于就手動(dòng)標(biāo)記斷言失敗并輸出失敗原因。這樣在聚合報(bào)告或察看結(jié)果樹里你能很直觀地看到哪些請求沒通過校驗(yàn)。經(jīng)驗(yàn)斷言別加太多加的每一個(gè)斷言都會(huì)消耗額外的性能。壓測腳本里的斷言越精簡越好能用一個(gè)響應(yīng)斷言解決的就不要加腳本斷言。高并發(fā)壓測時(shí)過重的斷言會(huì)拉高 JMeter 本身的 CPU 開銷影響測試數(shù)據(jù)準(zhǔn)確性。6.3 結(jié)合“用結(jié)果樹看數(shù)據(jù)”排查問題壓測跑完后第一件事永遠(yuǎn)是看察看結(jié)果樹View Results Tree。在結(jié)果樹里每個(gè) JDBC Request 都能展開看它的請求數(shù)據(jù)、響應(yīng)數(shù)據(jù)、斷言結(jié)果。響應(yīng)數(shù)據(jù)里會(huì)顯示 SQL 執(zhí)行后返回的內(nèi)容格式。我遇到過很多測試小白寫完了腳本直接開壓壓完發(fā)現(xiàn)錯(cuò)誤率 100%然后開始懷疑數(shù)據(jù)庫出問題了。其實(shí)根本不是數(shù)據(jù)庫的問題而是 SQL 寫錯(cuò)了或者參數(shù)沒傳進(jìn)去。這種時(shí)候不用慌打開察看結(jié)果樹找一個(gè)失敗的請求看它的響應(yīng)數(shù)據(jù)里的報(bào)錯(cuò)信息十有八九一次就能定位到問題。7. 并發(fā)壓測實(shí)戰(zhàn)模擬 100 個(gè)用戶同時(shí)查庫7.1 線程組參數(shù)設(shè)計(jì)前面把 JDBC Request 和參數(shù)化都講完了接下來進(jìn)入實(shí)戰(zhàn)模式——模擬 100 個(gè)用戶同時(shí)訪問數(shù)據(jù)庫看數(shù)據(jù)庫的表現(xiàn)。線程組配置建議Number of Threads (users)100Ramp-Up Period (seconds)10Loop Count50 或者填 ∞根據(jù)你的壓測時(shí)長來定這里解釋一下 Ramp-Up Period 的作用它表示 100 個(gè)線程在 10 秒內(nèi)全部啟動(dòng)完畢也就是說每秒啟動(dòng) 10 個(gè)線程。這樣做是為了模擬用戶逐步進(jìn)入系統(tǒng)的真實(shí)場景而不是 100 個(gè)請求在同一毫秒內(nèi)全部打到數(shù)據(jù)庫。如果你希望一開始就是滿負(fù)載可以把 Ramp-Up 設(shè)成 1 秒如果你要做階梯壓測可以用 Stepping Thread Group 插件但這個(gè)插件需要額外安裝基礎(chǔ)場景下普通線程組就夠用了。Loop Count 表示每個(gè)線程執(zhí)行多少次查詢。假如一個(gè) JDBC Request 執(zhí)行一條 SQL100 個(gè)線程 × 循環(huán) 50 次 總共 5000 次 SQL 查詢。這個(gè)總數(shù)可以用來估算壓測時(shí)長和數(shù)據(jù)庫負(fù)載。7.2 實(shí)戰(zhàn)腳本結(jié)構(gòu)一個(gè)標(biāo)準(zhǔn)的數(shù)據(jù)庫壓測腳本結(jié)構(gòu)如下測試計(jì)劃線程組100 線程10 秒內(nèi)啟動(dòng)JDBC Connection Configuration連接池配置最大連接數(shù) 100CSV Data Set Config用戶數(shù)據(jù)參數(shù)化JDBC Request執(zhí)行 SQL響應(yīng)斷言校驗(yàn)返回結(jié)果監(jiān)聽器聚合報(bào)告Aggregate Report察看結(jié)果樹View Results Tree需要注意JDBC Connection Configuration 和 CSV Data Set Config 都是配置元件Config Element它們的作用范圍是“所在層級(jí)之下的所有請求”。放在線程組下就對該線程組里的所有 JDBC Request 生效。7.3 壓測過程中的實(shí)時(shí)監(jiān)控壓測跑起來之后除了看 JMeter 的聚合報(bào)告我強(qiáng)烈建議你同時(shí)監(jiān)控?cái)?shù)據(jù)庫端的指標(biāo)。光看 JMeter 的響應(yīng)時(shí)間是不夠的你還需要知道數(shù)據(jù)庫的 CPU、內(nèi)存、連接數(shù)、慢查詢數(shù)等指標(biāo)才能完整評(píng)估數(shù)據(jù)庫性能。具體做法如果是 MySQL可以在壓測時(shí)執(zhí)行SHOW PROCESSLIST;查看當(dāng)前所有連接和正在執(zhí)行的 SQL。查看數(shù)據(jù)庫的 CPU 和內(nèi)存占用比如用top或數(shù)據(jù)庫自帶的性能監(jiān)控工具。開啟慢查詢?nèi)罩緣簻y完后分析哪些 SQL 的執(zhí)行時(shí)間超過了閾值。這一步非常重要因?yàn)?JMeter 的聚合報(bào)告只能告訴你“響應(yīng)時(shí)間變慢了”但到底慢在數(shù)據(jù)庫的哪個(gè)環(huán)節(jié)——是 CPU 打滿了、還是鎖等待、還是磁盤 IO——必須結(jié)合數(shù)據(jù)庫端的指標(biāo)來看。7.4 聚合報(bào)告怎么解讀壓測結(jié)束看聚合報(bào)告的幾個(gè)核心指標(biāo)Samples總請求數(shù)Average平均響應(yīng)時(shí)間單位毫秒Min / Max最小/最大響應(yīng)時(shí)間Std. Dev.響應(yīng)時(shí)間標(biāo)準(zhǔn)差越大說明響應(yīng)時(shí)間波動(dòng)越明顯性能越不穩(wěn)定Error %錯(cuò)誤率正常壓測場景下應(yīng)為 0%有少量錯(cuò)誤要具體分析Throughput吞吐量單位通常是req/sec意思是每秒能處理多少請求舉個(gè)例子100 個(gè)線程、循環(huán) 50 次的腳本跑完Samples 是 5000Throughput 如果是 200/sec說明數(shù)據(jù)庫每秒能扛住 200 次這個(gè) SQL 查詢。如果你把循環(huán)次數(shù)加大Throughput 會(huì)逐步逼近數(shù)據(jù)庫的極限值這個(gè)極限值就是數(shù)據(jù)庫的處理能力上限。經(jīng)驗(yàn)壓測數(shù)據(jù)庫時(shí)平均響應(yīng)時(shí)間和吞吐量要一起看。如果平均響應(yīng)時(shí)間很低但吞吐量也低說明 JMeter 本身或網(wǎng)絡(luò)成了瓶頸不是數(shù)據(jù)庫不行如果吞吐量上去了但平均響應(yīng)時(shí)間也跟著飆升這才說明數(shù)據(jù)庫開始進(jìn)入高負(fù)載狀態(tài)。8. 常見問題與排查技巧實(shí)錄8.1 連接不通ClassNotFoundException 和 URL 報(bào)錯(cuò)問題現(xiàn)象JDBC Request 報(bào)ClassNotFoundException: com.mysql.jdbc.Driver或Cannot create PoolableConnectionFactory。排查思路先看驅(qū)動(dòng) Jar 包有沒有放到 JMeter 的 lib 目錄下然后看是否重啟了 JMeter。如果確定 Jar 包在再看 Driver Class 寫對沒有——MySQL 8.x 驅(qū)動(dòng)對應(yīng)的是com.mysql.cj.jdbc.Driver不是com.mysql.jdbc.Driver。如果報(bào)錯(cuò)信息是Unknown database xxx檢查連接 URL 里的數(shù)據(jù)庫名是否正確。如果是Access denied for user檢查賬號(hào)密碼和數(shù)據(jù)庫權(quán)限。8.2 連接池不夠用Too many connections問題現(xiàn)象壓測過程中JMeter 報(bào)Too many connections或者數(shù)據(jù)庫端出現(xiàn)Connection refused。原因分析這個(gè)報(bào)錯(cuò)有兩個(gè)方向一個(gè)是 JMeter 連接池最大連接數(shù)設(shè)得太大打爆了數(shù)據(jù)庫的最大連接數(shù)另一個(gè)是數(shù)據(jù)庫自身max_connections配置太小。解決方案先查看數(shù)據(jù)庫的max_connections比如 MySQL 可以用SHOW VARIABLES LIKE max_connections;查看。然后調(diào)整 JMeter 連接池的最大連接數(shù)讓它的上限略低于數(shù)據(jù)庫的max_connections留一些余量給其他應(yīng)用連接。順便說一句做壓測之前一定要和 DBA 或運(yùn)維確認(rèn)好數(shù)據(jù)庫的連接上限否則壓到一半數(shù)據(jù)庫直接把連接全踢掉測試結(jié)果就廢了。8.3 響應(yīng)時(shí)間異常長慢 SQL 還是連接池排隊(duì)問題現(xiàn)象聚合報(bào)告顯示平均響應(yīng)時(shí)間高達(dá)幾秒遠(yuǎn)大于你手動(dòng)執(zhí)行 SQL 的時(shí)間。原因分析首先要區(qū)分是數(shù)據(jù)庫真慢還是連接池在排隊(duì)。手動(dòng)執(zhí)行 SQL 快說明 SQL 本身沒問題。這時(shí)候要去看 JMeter 連接池的最大連接數(shù)是不是小于線程數(shù)——如果 100 個(gè)線程去搶 20 個(gè)連接剩下 80 個(gè)線程全在等連接響應(yīng)時(shí)間自然飆升。解決方案把 Max Number of Connections 調(diào)大使其等于或大于線程數(shù)再跑一次對比。如果響應(yīng)時(shí)間正常了說明之前的瓶頸是連接池如果響應(yīng)時(shí)間依然很大那就要去數(shù)據(jù)庫端看慢查詢?nèi)罩径ㄎ皇遣皇撬饕?、鎖等待等問題。還有一個(gè)細(xì)節(jié)如果連接 URL 設(shè)置了socketTimeout當(dāng)數(shù)據(jù)庫處理查詢超過這個(gè)值時(shí)JMeter 會(huì)直接報(bào) socket 超時(shí)。這種情況下不是數(shù)據(jù)庫變慢而是策略性地?cái)嚅_了連接。壓測時(shí)可以把 socketTimeout 調(diào)大一點(diǎn)避免誤判。8.4 變量引用出來是 null結(jié)果集行號(hào)與字段大小寫問題現(xiàn)象在后續(xù)請求里用${var_1_id}引用 JDBC 查詢結(jié)果發(fā)現(xiàn)值是 null 或者空字符串。原因排查第一先看結(jié)果集是不是空的。如果 SQL 查不出來數(shù)據(jù)任何引用都是空。用察看結(jié)果樹看響應(yīng)數(shù)據(jù)確認(rèn)是否有數(shù)據(jù)返回。第二看字段名大小寫。MySQL 的字段名默認(rèn)全小寫如果 SQL 里寫了別名比如SELECT id AS userId FROM user那么引用時(shí)要寫成${var_1_userId}。建議 SQL 里起別名時(shí)統(tǒng)一用帶下劃線的命名如user_id然后引用時(shí)保持大小寫一致。第三行號(hào)從 1 開始不是從 0 開始。如果變量名是order_result那么第一行是order_result_1沒有order_result_0這個(gè)變量。8.5 中文亂碼與編碼問題問題現(xiàn)象JDBC 查詢返回的中文變成問號(hào)或亂碼。原因排查大多是連接 URL 里沒有指定字符集。在 MySQL 連接 URL 上加上characterEncodingutf8jdbc:mysql://127.0.0.1:3306/testdb?useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/ShanghaicharacterEncodingutf8另外檢查數(shù)據(jù)庫表本身的字符集是不是 utf8mb4。如果表是 latin1 而應(yīng)用按 utf8 讀取也會(huì)亂碼。8.6 一個(gè)容易被忽略的問題壓測機(jī)性能不夠最后提一個(gè)很多人踩過的坑——壓測機(jī)本身的性能不夠。JMeter 是 Java 應(yīng)用100 個(gè)并發(fā)線程跑起來時(shí)壓測機(jī) CPU 和內(nèi)存消耗不小。如果你在本地筆記本上壓遠(yuǎn)程數(shù)據(jù)庫壓測結(jié)果可能不是你 SQL 的真實(shí)性能而是筆記本 CPU 打滿后的結(jié)果。怎么判斷壓測時(shí)打開任務(wù)管理器或top看看 Java 進(jìn)程的 CPU 占用率。如果已經(jīng)超過了機(jī)器 CPU 的 70% 以上建議換一臺(tái)性能更強(qiáng)的機(jī)器或者把 JMeter 部署到另一臺(tái)服務(wù)器上盡量讓壓測機(jī)資源充足確保瓶頸在數(shù)據(jù)庫端而不是客戶端。8.7 問題排查速查表問題現(xiàn)象可能原因解決方案ClassNotFoundException驅(qū)動(dòng) Jar 未放到 lib 目錄放入 Jar 包并重啟 JMeterCannot create PoolableConnectionFactoryURL 或賬號(hào)密碼錯(cuò)誤檢查 URL 格式、賬號(hào)權(quán)限Too many connections連接數(shù)超過數(shù)據(jù)庫上限調(diào)大數(shù)據(jù)庫 max_connections 或調(diào)小 JMeter 連接池響應(yīng)時(shí)間超長連接池排隊(duì)或慢 SQL調(diào)大連接池查看慢查詢?nèi)罩咀兞恐禐?null結(jié)果集為空或字段名大小寫不一致確認(rèn)查詢結(jié)果檢查 SQL 別名中文亂碼連接 URL 未指定字符集添加 characterEncodingutf8壓測結(jié)果不穩(wěn)定壓測機(jī)資源不足更換壓測機(jī)或降低線程數(shù)9. 一個(gè)完整的數(shù)據(jù)庫壓測腳本示例講了這么多最后給你一個(gè)完整的 MySQL 壓測腳本搭建過程從零到一可以直接照抄。9.1 測試場景模擬 100 個(gè)用戶并發(fā)查詢訂單表每個(gè)查詢根據(jù)不同的訂單 ID 查詢訂單信息持續(xù)壓測 10 分鐘觀察數(shù)據(jù)庫的吞吐量和響應(yīng)時(shí)間變化。9.2 準(zhǔn)備工作MySQL 數(shù)據(jù)庫提前創(chuàng)建好訂單表orders字段包括order_id、user_id、amount、status準(zhǔn)備一個(gè)order_ids.csv文件里面放 100 個(gè)訂單 ID用于參數(shù)化JMeter 5.xmysql-connector-java-8.0.x.jar已放入 lib 目錄并重啟9.3 腳本搭建步驟第一步創(chuàng)建測試計(jì)劃并添加線程組線程數(shù) 100Ramp-Up 10 秒循環(huán)次數(shù)勾選無限在調(diào)度器配置里設(shè)置持續(xù)時(shí)間為 600 秒。第二步添加 JDBC Connection Configuration配置項(xiàng)如下Variable Name for created poolmysql_poolMax Number of Connections100Max Wait10000Auto CommitTruePool Validation QuerySELECT 1Database Connection ConfigurationDatabase URLjdbc:mysql://127.0.0.1:3306/testdb?useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/ShanghaiJDBC Driver Classcom.mysql.cj.jdbc.DriverUsernametest_userPasswordyour_password第三步添加 CSV Data Set ConfigFilename/data/order_ids.csvVariable Namesorder_idDelimiter,Recycle on EOFTrueStop thread on EOFFalseSharing modeAll threads第四步添加 JDBC RequestVariable Name of Poolmysql_poolQuery TypePrepared Select StatementQuerySELECT * FROM orders WHERE order_id ?Parameter values${order_id}Parameter typesVARCHAR這里說明一下因?yàn)?SQL 里有?占位符所以 Query Type 必須選 Prepared Select StatementParameter values 里填 CSV 讀取出來的訂單 IDParameter types 填數(shù)據(jù)庫字段類型。第五步添加響應(yīng)斷言Field to TestText ResponsePattern Matching RulesContainsPatterns to Testorder_id這樣就確保了查詢請求返回的結(jié)果中包含 order_id 字段證明查詢是成功的。第六步添加監(jiān)聽器加一個(gè)聚合報(bào)告和一個(gè)察看結(jié)果樹。壓測結(jié)束后聚合報(bào)告里可以看到平均響應(yīng)時(shí)間、吞吐量、錯(cuò)誤率等核心數(shù)據(jù)。9.4 跑完怎么分析壓測結(jié)束后我一般這么看數(shù)據(jù)先看錯(cuò)誤率。如果錯(cuò)誤率為 0%說明 100 并發(fā)下這條 SQL 沒有出錯(cuò)數(shù)據(jù)庫連接和查詢都正常。如果錯(cuò)誤率大于 0查詢具體的錯(cuò)誤信息常見的是連接池不夠用或超時(shí)。然后看吞吐量變化。如果 JMeter 的 Throughput 在持續(xù)穩(wěn)定上升后趨于平緩說明已經(jīng)摸到了數(shù)據(jù)庫的處理上限。此時(shí)如果平均響應(yīng)時(shí)間還能接受說明數(shù)據(jù)庫還有冗余如果響應(yīng)時(shí)間已經(jīng)超標(biāo)比如超過 500ms說明數(shù)據(jù)庫快要撐不住了。最后結(jié)合數(shù)據(jù)庫端監(jiān)控比如 CPU、慢查詢?nèi)罩究雌款i到底在哪個(gè)環(huán)節(jié)然后給出測試結(jié)論和優(yōu)化建議。這里有一個(gè)小建議壓測時(shí)先把線程數(shù)保守一點(diǎn)比如 50跑一輪看結(jié)果再逐步升到 100、200。這樣做的好處是你能看到數(shù)據(jù)庫在不同并發(fā)下的表現(xiàn)曲線而不是一上來就壓到天花板拿到一堆根本沒法分析的數(shù)據(jù)。階梯式加壓是我在實(shí)際項(xiàng)目中比較喜歡用的方式。最后說幾句實(shí)在話用 JMeter 做數(shù)據(jù)庫壓測門檻真的不高但想做好需要你對數(shù)據(jù)庫本身的運(yùn)行機(jī)制有基本認(rèn)知。我在實(shí)際測試項(xiàng)目里見過不少人把壓測腳本配好了、跑出了漂亮的報(bào)告但一問數(shù)據(jù)庫端的指標(biāo)完全答不上來——CPU 多少、內(nèi)存多少、慢查詢有沒有、連接數(shù)有沒有到上限全是空白。這種壓測報(bào)告說實(shí)話價(jià)值有限。我的個(gè)人建議是壓測數(shù)據(jù)庫永遠(yuǎn)要把 JMeter 端的數(shù)據(jù)和數(shù)據(jù)庫端的數(shù)據(jù)結(jié)合起來看。JMeter 告訴你發(fā)生了什么數(shù)據(jù)庫的監(jiān)控告訴你為什么會(huì)發(fā)生。兩邊對照才能真正判斷數(shù)據(jù)庫的性能瓶頸在哪里也才能給出可信的測試結(jié)論。如果你只是剛接觸這塊先從最簡單的單條 SQL 查詢壓測入手把 JDBC Connection Configuration 和 JDBC Request 玩熟再慢慢加參數(shù)化、加斷言、加并發(fā)場景。不要一上來就想測多表關(guān)聯(lián)或存儲(chǔ)過程底子打好后面的內(nèi)容都是水到渠成的事。 JMeter壓測數(shù)據(jù)庫全指南：JDBC配置、參數(shù)化與并發(fā)實(shí)戰(zhàn)
1. 先想清楚壓數(shù)據(jù)庫和壓接口到底差在哪很多人用 JMeter 做接口測試、壓 Web 服務(wù)駕輕就熟。但一說到用 JMeter 直接壓數(shù)據(jù)庫不少人就懵了——數(shù)據(jù)庫也能用 JMeter 壓怎么連連上了能測啥先說結(jié)論不僅能壓而且非常好使。我在實(shí)際項(xiàng)目里既用 JMeter 壓過 MySQL、PostgreSQL也壓過 Oracle甚至給第三方數(shù)據(jù)中臺(tái)做過壓測靠的都是 JMeter 自帶的 JDBC 請求組件不需要裝任何額外插件。但有一個(gè)認(rèn)知必須先糾正用 JMeter 測數(shù)據(jù)庫不等于在數(shù)據(jù)庫客戶端里手動(dòng)執(zhí)行幾條 SQL 看返回時(shí)間。它做的是“模擬真實(shí)業(yè)務(wù)場景下大量并發(fā)請求同時(shí)打向數(shù)據(jù)庫”這件事——比如 100 個(gè)用戶同時(shí)登錄每個(gè)登錄動(dòng)作背后對應(yīng)著幾條 SQL這些 SQL 同時(shí)打到數(shù)據(jù)庫上數(shù)據(jù)庫扛不扛得住平均響應(yīng)時(shí)間多少有沒有慢查詢連接池會(huì)不會(huì)被打滿這才是壓數(shù)據(jù)庫的核心目的。所以這篇文章我不會(huì)只講“怎么連上數(shù)據(jù)庫”而是把 JMeter 測試數(shù)據(jù)庫的完整方法拆開揉碎環(huán)境準(zhǔn)備、JDBC 連接配置、JDBC Request 詳解、參數(shù)化傳值、斷言校驗(yàn)、并發(fā)場景搭建、常見問題排查一條龍講清楚。你照著做基本可以覆蓋日常工作中 90% 的數(shù)據(jù)庫壓測需求。適合誰看剛接觸 JMeter、想用它做數(shù)據(jù)庫壓測的測試新人被領(lǐng)導(dǎo)臨時(shí)派活、需要在兩天內(nèi)給出數(shù)據(jù)庫性能結(jié)論的測試工程師以及那些已經(jīng)會(huì)基本接口壓測、但沒系統(tǒng)搞過 JDBC 請求的老手?？赐昴阒辽倌塥?dú)立搭出一套帶參數(shù)化、帶斷言、帶并發(fā)模型的數(shù)據(jù)庫壓測腳本。2. 環(huán)境準(zhǔn)備驅(qū)動(dòng)、版本、連接方式一步都不能錯(cuò)2.1 先確認(rèn) JMeter 版本和 JDBC 驅(qū)動(dòng)開始之前先確認(rèn)你的 JMeter 版本。我這邊用的是 JMeter 5.xJDBC 請求相關(guān)的組件從 3.x 就有界面和配置項(xiàng)基本一致所以你用 4.x 或 5.x 都行不用太糾結(jié)版本。關(guān)鍵在于JDBC 驅(qū)動(dòng) Jar 包。JMeter 本身不自帶數(shù)據(jù)庫驅(qū)動(dòng)你必須手動(dòng)把對應(yīng)數(shù)據(jù)庫的驅(qū)動(dòng) Jar 包放到 JMeter 的lib目錄下然后重啟 JMeter 才能生效。常見數(shù)據(jù)庫對應(yīng)的驅(qū)動(dòng) Jar 包MySQLmysql-connector-java-8.0.x.jar如果你連的是 MySQL 5.x建議用 5.1.4x 版本MySQL 8.x 一定要用 8.0 版本的驅(qū)動(dòng)不然連接會(huì)報(bào)錯(cuò)。PostgreSQLpostgresql-42.x.x.jarOracleojdbc8.jar或ojdbc11.jar看你數(shù)據(jù)庫版本SQL Servermssql-jdbc-9.x.x.jar驅(qū)動(dòng)包放好之后重啟 JMeter然后用一個(gè)最簡單的 JDBC 請求驗(yàn)證一下能不能連上。別一上來就搞復(fù)雜場景連接都不通的話后面全是白搭。2.2 JDBC 驅(qū)動(dòng)類名和連接 URL別記混了很多新手死在第一步就是驅(qū)動(dòng)類名和 URL 寫錯(cuò)。這里直接給你一份對照表抄作業(yè)就行數(shù)據(jù)庫JDBC Driver ClassJDBC URL 格式MySQLcom.mysql.jdbc.Driver5.x/com.mysql.cj.jdbc.Driver8.xjdbc:mysql://127.0.0.1:3306/testdb?useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/ShanghaiPostgreSQLorg.postgresql.Driverjdbc:postgresql://127.0.0.1:5432/testdbOracleoracle.jdbc.OracleDriverjdbc:oracle:thin:127.0.0.1:1521/ORCLSQL Servercom.microsoft.sqlserver.jdbc.SQLServerDriverjdbc:sqlserver://127.0.0.1:1433;DatabaseNametestdb注意 MySQL 這里有兩個(gè)坑第一MySQL 5.x 和 8.x 的 Driver Class 不一樣。8.x 是com.mysql.cj.jdbc.Driver不是com.mysql.jdbc.Driver寫錯(cuò)直接報(bào)ClassNotFoundException。第二MySQL 8.x 連接 URL 里建議加上useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/Shanghai。不加 serverTimezone 會(huì)報(bào)時(shí)區(qū)錯(cuò)誤不加 allowPublicKeyRetrieval 會(huì)在某些認(rèn)證方式下報(bào)Public Key Retrieval is not allowed。這兩個(gè)參數(shù)我每次都會(huì)帶上省得排查半天。經(jīng)驗(yàn)我一般會(huì)在連接 URL 里額外加一個(gè)connectTimeout5000socketTimeout10000避免數(shù)據(jù)庫掛了之后線程一直卡在等待上壓測時(shí)能很快暴露連接超時(shí)問題。比如jdbc:mysql://127.0.0.1:3306/testdb?useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/ShanghaiconnectTimeout5000socketTimeout100002.3 環(huán)境驗(yàn)證用一個(gè)最簡單的查詢打通鏈路驅(qū)動(dòng)放好、配置想清楚了先做個(gè)連通性測試——在 JMeter 里建一個(gè)測試計(jì)劃加一個(gè) JDBC Connection Configuration再選一個(gè)庫建一個(gè)線程池跑一條SELECT 1如果返回正常鏈路就通了。這一步別看簡單它價(jià)值很大能一次性排除驅(qū)動(dòng)、URL、賬號(hào)密碼、網(wǎng)絡(luò)四個(gè)環(huán)節(jié)的問題。如果SELECT 1都跑不通那后面再復(fù)雜的腳本也跑不通不如先在這里把問題解決掉。3. JDBC Connection Configuration連接池配置才是壓測的關(guān)鍵3.1 配置項(xiàng)逐行拆解JDBC Connection Configuration 是 JDBC 請求的前置條件相當(dāng)于給所有 JDBC 請求提供數(shù)據(jù)庫連接池。它不是一個(gè)“填個(gè) URL 就行”的簡單配置每個(gè)選項(xiàng)背后都有講究。關(guān)鍵的幾個(gè)配置項(xiàng)Variable Name for created pool連接池變量名隨便起比如db_pool但你要記死它因?yàn)?JDBC Request 里要通過這個(gè)名字來引用這個(gè)連接池。一個(gè)測試計(jì)劃里可以配置多個(gè)連接池給不同庫用靠名字區(qū)分。Max Number of Connections最大連接數(shù)。這個(gè)值很關(guān)鍵它決定了 JMeter 能同時(shí)從池里拿多少個(gè)連接。如果你壓 100 個(gè)并發(fā)但最大連接數(shù)只有 10那 JMeter 的請求就會(huì)排隊(duì)等連接測出來的結(jié)果不是數(shù)據(jù)庫的真實(shí)瓶頸而是連接池的瓶頸。Max Wait最大等待時(shí)間單位毫秒。連接池沒空閑連接時(shí)請求最多等多久超時(shí)拋異常。一般設(shè) 10000。Time Between Eviction Runs清理線程運(yùn)行間隔。JMeter 會(huì)定期清理空閑過久的連接一般設(shè) 60000。Auto Commit自動(dòng)提交。只做查詢壓測時(shí)設(shè) True 就好涉及事務(wù)、插入、更新時(shí)按需改成 False。Transaction Isolation事務(wù)隔離級(jí)別默認(rèn) DEFAULT 即可不用特別改。Pool Validation Query連接有效性檢查 SQL。MySQL 下寫SELECT 1PostgreSQL 下寫SELECT 1Oracle 下寫SELECT 1 FROM DUAL。JMeter 每次從池里拿連接時(shí)可以用這個(gè) SQL 驗(yàn)證連接是否還活著避免拿到失效連接。3.2 連接池參數(shù)怎么定一個(gè)簡單的估算方法連接池最大連接數(shù)怎么定很多教程會(huì)說“設(shè)大一點(diǎn)就行”但實(shí)際不是這么回事。連接數(shù)設(shè)太大數(shù)據(jù)庫可能會(huì)因?yàn)椴l(fā)連接過多直接拒絕服務(wù)設(shè)太小JMeter 這邊又會(huì)排隊(duì)。我的做法是連接池最大連接數(shù) 目標(biāo)并發(fā)線程數(shù)。比如你要模擬 100 個(gè)用戶并發(fā)那么 Max Number of Connections 就設(shè) 100 或略大于 100比如 100。這樣每個(gè)線程拿到一個(gè)獨(dú)立連接不會(huì)出現(xiàn)兩個(gè)線程搶一個(gè)連接的情況。這里有個(gè)容易混淆的細(xì)節(jié)JMeter 的線程數(shù)和連接池連接數(shù)不是一一綁定的關(guān)系。線程可以復(fù)用連接但如果你想測的是“數(shù)據(jù)庫在 100 個(gè)并發(fā)連接下的表現(xiàn)”那連接數(shù)就必須給夠否則測出來的曲線是連接池排隊(duì)曲線不是數(shù)據(jù)庫性能曲線。3.3 為什么要用連接池而不是每個(gè)線程單獨(dú)連JMeter 里還有一種做法是每個(gè)線程自己創(chuàng)建數(shù)據(jù)庫連接不用連接池——比如用 BeanShell 或者 JSR223 寫代碼去DriverManager.getConnection()。我不推薦這種方式做壓測原因有兩個(gè)第一性能差。每次請求都重新創(chuàng)建連接開銷全花在 TCP 握手和認(rèn)證上測出來的響應(yīng)時(shí)間虛高。第二資源不可控。并發(fā) 100 個(gè)線程同時(shí)創(chuàng)建 100 個(gè)連接壓測機(jī)本身的文件描述符、內(nèi)存壓力都會(huì)變大干擾結(jié)果。所以標(biāo)準(zhǔn)做法就是一個(gè) JDBC Connection Configuration 管連接池N 個(gè) JDBC Request 從池里取連接執(zhí)行 SQL。連接池的創(chuàng)建、復(fù)用、回收J(rèn)Meter 都在底層幫你處理好了你要做的就是配置好那幾項(xiàng)參數(shù)。4. JDBC Request 詳解增刪改查都能壓4.1 SQL 查詢和變量名規(guī)則JDBC Request 是真正執(zhí)行 SQL 的地方。它長得很像一個(gè) HTTP 請求 Sample但參數(shù)完全不同。核心參數(shù)有三個(gè)Variable Name of Pool declared in JDBC Connection Configuration填連接池變量名也就是你在 JDBC Connection Configuration 里填的那個(gè)名字。如果這里填錯(cuò)JMeter 會(huì)直接報(bào)錯(cuò)找不到連接池。Query TypeSQL 類型有 Select Statement、Update Statement、Callable Statement、Prepared Select Statement、Prepared Update Statement 等。如果是普通查詢用 Select Statement如果 SQL 里有占位符?必須用 Prepared Select Statement 或 Prepared Update Statement。QuerySQL 語句本體。這里有個(gè)新手高頻疑問Query Type 選 Select Statement 和 Prepared Select Statement 有什么區(qū)別區(qū)別在占位符。如果你要執(zhí)行SELECT * FROM user WHERE id ?就必須用 Prepared Select Statement然后通過參數(shù)列表傳入?的值。如果你執(zhí)行的是完整 SQL沒有?用 Select Statement 就行。相同點(diǎn)是結(jié)果都存放在變量里供后續(xù)使用。4.2 查詢結(jié)果的三種用法JDBC Request 執(zhí)行完之后結(jié)果存在哪答案是JMeter 會(huì)把結(jié)果集存到變量里變量名規(guī)則是你在 JDBC Request 里填的Variable Name。比如你在 JDBC Request 的 Variable Name 填了mysql_result那么執(zhí)行完查詢后mysql_result整個(gè)結(jié)果集mysql_result_#結(jié)果集行數(shù)比如返回 10 行這個(gè)變量值就是 10mysql_result_1第一行數(shù)據(jù)mysql_result_1_id第一行的 id 字段值mysql_result_2_id第二行的 id 字段值用Variable Name 下劃線 行號(hào) 下劃線 列名這個(gè)規(guī)則就能取到任意一行任意一列的值。這個(gè)特性相當(dāng)有用。最常見的場景是你從表 A 查到一批訂單 ID然后要把這些 ID 作為參數(shù)傳給下一個(gè) JDBC Request 或 HTTP 請求。具體做法就是先執(zhí)行一條查詢 SQL然后在下一個(gè)請求里用${mysql_result_1_id}來引用第一行 ID。4.3 實(shí)際案例查詢用戶表數(shù)據(jù)我來演示一個(gè)最簡單的例子。假設(shè)數(shù)據(jù)庫里有一張user表字段有id、username、age我想壓測一條查詢 SQLSELECT id, username, age FROM user WHERE age 20配置如下JDBC Request Variable Nameuser_resultQuery TypeSelect StatementQuerySELECT id, username, age FROM user WHERE age 20跑完之后在察看結(jié)果樹里可以看到這個(gè) JDBC Request 的響應(yīng)數(shù)據(jù)里面是查到的所有行。如果你想把這批數(shù)據(jù)取出來給后續(xù)請求用比如遍歷前 10 個(gè)用戶 ID就可以用${user_result_1_id}、${user_result_2_id}這種形式去引用。注意結(jié)果集會(huì)按位置存儲(chǔ)mysql_result_1是第 1 行mysql_result_2是第 2 行以此類推。如果你查詢結(jié)果本身有排序需求在 SQL 里把ORDER BY寫好否則取出來的行順序可能不穩(wěn)定。4.4 執(zhí)行更新操作怎么配置壓測不光是查詢有時(shí)也要模擬寫入、更新的業(yè)務(wù)壓力。比如 100 個(gè)用戶同時(shí)更新自己的資料。如果是帶參數(shù)的更新比如UPDATE user SET age ? WHERE id ?那么 Query Type 要選Prepared Update StatementSQL 里的?是占位符需要通過“Parameter values”和“Parameter types”傳入實(shí)際值。這里有個(gè)重要細(xì)節(jié)執(zhí)行 Update/Insert/Delete 操作時(shí)如果數(shù)據(jù)庫沒有返回結(jié)果集JMeter 會(huì)返回受影響的行數(shù)。比如某個(gè) UPDATE 影響了 3 行JMeter 的響應(yīng)數(shù)據(jù)里會(huì)顯示3。如果你想驗(yàn)證更新是否成功一種做法是更新后再執(zhí)行一條 SELECT 去查這條數(shù)據(jù)配合斷言來校驗(yàn)。5. 參數(shù)化取值讓壓測數(shù)據(jù)動(dòng)起來5.1 CSVDataset 參數(shù)化每個(gè)線程分塊取值做數(shù)據(jù)庫壓測時(shí)你常常需要模擬“不同的用戶操作不同的數(shù)據(jù)”而不是 100 個(gè)用戶都查同一條記錄。前者才是真實(shí)業(yè)務(wù)場景也能更有效地壓出數(shù)據(jù)庫的查詢能力。JMeter 里最常用的參數(shù)化方式就是CSV 數(shù)據(jù)集配置CSV Data Set Config。它允許你從一個(gè) CSV 文件里按行讀取數(shù)據(jù)然后把每一列的值賦給變量。配置的時(shí)候有幾點(diǎn)要注意FilenameCSV 文件路徑Variable Names列名用英文逗號(hào)分隔比如id,username,ageDelimiter分隔符默認(rèn)是英文逗號(hào)Recycle on EOF讀完最后一行后是否回到開頭繼續(xù)讀。如果你壓測時(shí)長較長或者并發(fā)數(shù)大于 CSV 行數(shù)建議設(shè) True否則讀到末尾線程會(huì)直接結(jié)束或報(bào)錯(cuò)。Stop thread on EOF讀完最后一行是否停止線程。如果 Recycle on EOF 是 True這個(gè)就設(shè) False。Sharing mode共享模式。默認(rèn) All threads 是所有線程共享一個(gè)文件指針按順序往下讀如果你想每個(gè)線程各讀各的可以選 Current thread。我在實(shí)際項(xiàng)目里壓“100 并發(fā)用戶登錄”時(shí)會(huì)準(zhǔn)備一個(gè) 100 行的 CSV每行一個(gè)用戶 ID 和密碼然后把線程組并發(fā)數(shù)設(shè)為 100CSV 共享模式用默認(rèn)的 All threads這樣每個(gè)線程拿到一個(gè)不同的用戶數(shù)據(jù)誰也不會(huì)搶。5.2 從上一個(gè)查詢結(jié)果取參JDBC 請求結(jié)果復(fù)用CSV 適合數(shù)據(jù)預(yù)先準(zhǔn)備好的場景但有些場景數(shù)據(jù)是動(dòng)態(tài)生成的——你先要查一下有哪些訂單然后針對每個(gè)訂單做后續(xù)操作。這種時(shí)候就要用 JDBC Request 的查詢結(jié)果來做參數(shù)化。思路是先跑一條 SELECT把結(jié)果存到一個(gè)變量里然后在后一個(gè)請求里用${var_行號(hào)_列名}去引用。舉個(gè)例子第一步JDBC Request 查訂單 IDSELECT order_id, amount FROM orders WHERE status pending這個(gè) JDBC Request 的 Variable Name 設(shè)為order_result。第二步在 HTTP 請求或下一個(gè) JDBC Request 里引用訂單 ID${order_result_1_order_id} 訂單金額${order_result_1_amount}這樣就實(shí)現(xiàn)了“把數(shù)據(jù)庫查出來的數(shù)據(jù)作為下一個(gè)接口的參數(shù)”這個(gè)高頻需求。但如果查詢返回了多行而你希望循環(huán)處理每一行數(shù)據(jù)那還是建議配合ForEach 控制器來做。ForEach 控制器可以遍歷一個(gè)變量集合比如order_result下的所有行然后逐一執(zhí)行后續(xù)請求。配置時(shí)輸入變量前綴order_result循環(huán)變量名隨便取一個(gè)比如current_order然后在后續(xù)請求里用${current_order_order_id}就能依次取到每一行的數(shù)據(jù)。5.3 JDBC 請求結(jié)果里的特殊變量行數(shù)和 NULL使用查詢結(jié)果時(shí)有兩個(gè)場景很容易踩坑。第一空結(jié)果集。如果 SQL 查不到數(shù)據(jù)order_result_#會(huì)是 0此時(shí)不能引用order_result_1_order_id否則 JMeter 會(huì)輸出一個(gè)空值。為了不報(bào)錯(cuò)可以搭配If 控制器判斷order_result_#是否大于 0再執(zhí)行后續(xù)邏輯。第二字段值本身是 NULL。比如某個(gè)字段在某些行里是 NULL引用之后得到的字符串是null而不是空字符串。如果你的下游接口對參數(shù)格式有嚴(yán)格要求需要在 BeanShell 或 JSR223 里做一個(gè) null 值替換處理否則接口調(diào)用可能會(huì)因?yàn)槎鄠髁薾ull字符串而報(bào)錯(cuò)。5.4 直接用 JSR223 腳本搞定更復(fù)雜的數(shù)據(jù)加工如果上面的方式都滿足不了需求比如你要對查出來的數(shù)據(jù)進(jìn)行 MD5 加密后作為參數(shù)傳給接口那就得上 JSR223 腳本了。JSR223 Sampler 里可以用 Groovy 直接查數(shù)據(jù)庫處理結(jié)果集生成任意格式的字符串。Groovy 的語法比 BeanShell 簡潔太多性能也更好是 JMeter 官方推薦的方式。雖然這篇文章主要講 JDBC Request 這種圖形化配置但在自定義邏輯非常復(fù)雜的時(shí)候JSR223 是終極兜底方案。簡單示例import java.sql.* // 獲取連接池里的連接 def conn vars.get(db_pool) // 這只是示意 // 真實(shí)的連接獲取可以通過 DataSource 或者直接用 JDBC 驅(qū)動(dòng)獲取這里省略不過說實(shí)話只有你需要寫復(fù)雜邏輯時(shí)才用 JSR223一般情況下 JDBC Request CSV 已經(jīng)能覆蓋絕大多數(shù)場景。過度使用 JSR223 反而會(huì)讓腳本難以維護(hù)。6. 斷言校驗(yàn)怎么證明數(shù)據(jù)庫返回是對的6.1 響應(yīng)斷言最快最直接的校驗(yàn)方式壓數(shù)據(jù)庫不是把 SQL 跑完就完事了你得確認(rèn)返回內(nèi)容是符合預(yù)期的。比如你查詢age 20的用戶結(jié)果返回里至少有數(shù)據(jù)行而不是空結(jié)果集或者一堆錯(cuò)誤信息。JMeter 的響應(yīng)斷言可以加到 JDBC Request 上用來校驗(yàn)響應(yīng)內(nèi)容。配置方式很簡單在 JDBC Request 上右鍵 → Add → Assertions → Response AssertionField to Test選 Text ResponsePattern Matching Rules選 ContainsPatterns to Test填你要校驗(yàn)的關(guān)鍵字比如查詢user表你想確認(rèn)結(jié)果里有username這個(gè)字段名就可以在響應(yīng)斷言里填username。如果響應(yīng)里沒有這個(gè)關(guān)鍵字?jǐn)嘌跃蜁?huì)失敗在聚合報(bào)告里會(huì)看到錯(cuò)誤率上升。這里有個(gè)技巧有時(shí)候 SQL 查出來的數(shù)據(jù)量很大響應(yīng)內(nèi)容很長你沒法直觀地看到是否有數(shù)據(jù)這時(shí)可以直接用響應(yīng)斷言校驗(yàn) “返回行數(shù)不為 0”。具體做法是把 SQL 改成SELECT COUNT(*) AS cnt FROM user WHERE age 20然后斷言響應(yīng)里包含cnt10或某個(gè)具體數(shù)字。注意JMeter 響應(yīng)里 COUNT 查詢的顯示格式是類似cnt10這樣的配合 Contains 斷言就能判斷數(shù)據(jù)量是否符合預(yù)期。6.2 BeanShell 斷言處理復(fù)雜校驗(yàn)邏輯響應(yīng)斷言只能做簡單匹配如果你要做復(fù)雜判斷比如“查詢結(jié)果里最大金額大于 1000”或“返回行數(shù)在某個(gè)區(qū)間內(nèi)”就得用 BeanShell 斷言或者 JSR223 斷言。JSR223 斷言可以用 Groovy 寫邏輯清晰多了。比如判斷結(jié)果集行數(shù)def rowCount vars.get(user_result_#).toInteger() if (rowCount 10) { // 失敗手動(dòng)設(shè)置斷言結(jié)果 AssertionResult.setFailure(true) AssertionResult.setFailureMessage(查詢結(jié)果集行數(shù)小于10實(shí)際為: rowCount) }這段腳本的邏輯是從 JMeter 變量里取user_result_#的值轉(zhuǎn)成整數(shù)判斷是否小于 10如果小于就手動(dòng)標(biāo)記斷言失敗并輸出失敗原因。這樣在聚合報(bào)告或察看結(jié)果樹里你能很直觀地看到哪些請求沒通過校驗(yàn)。經(jīng)驗(yàn)斷言別加太多加的每一個(gè)斷言都會(huì)消耗額外的性能。壓測腳本里的斷言越精簡越好能用一個(gè)響應(yīng)斷言解決的就不要加腳本斷言。高并發(fā)壓測時(shí)過重的斷言會(huì)拉高 JMeter 本身的 CPU 開銷影響測試數(shù)據(jù)準(zhǔn)確性。6.3 結(jié)合“用結(jié)果樹看數(shù)據(jù)”排查問題壓測跑完后第一件事永遠(yuǎn)是看察看結(jié)果樹View Results Tree。在結(jié)果樹里每個(gè) JDBC Request 都能展開看它的請求數(shù)據(jù)、響應(yīng)數(shù)據(jù)、斷言結(jié)果。響應(yīng)數(shù)據(jù)里會(huì)顯示 SQL 執(zhí)行后返回的內(nèi)容格式。我遇到過很多測試小白寫完了腳本直接開壓壓完發(fā)現(xiàn)錯(cuò)誤率 100%然后開始懷疑數(shù)據(jù)庫出問題了。其實(shí)根本不是數(shù)據(jù)庫的問題而是 SQL 寫錯(cuò)了或者參數(shù)沒傳進(jìn)去。這種時(shí)候不用慌打開察看結(jié)果樹找一個(gè)失敗的請求看它的響應(yīng)數(shù)據(jù)里的報(bào)錯(cuò)信息十有八九一次就能定位到問題。7. 并發(fā)壓測實(shí)戰(zhàn)模擬 100 個(gè)用戶同時(shí)查庫7.1 線程組參數(shù)設(shè)計(jì)前面把 JDBC Request 和參數(shù)化都講完了接下來進(jìn)入實(shí)戰(zhàn)模式——模擬 100 個(gè)用戶同時(shí)訪問數(shù)據(jù)庫看數(shù)據(jù)庫的表現(xiàn)。線程組配置建議Number of Threads (users)100Ramp-Up Period (seconds)10Loop Count50 或者填 ∞根據(jù)你的壓測時(shí)長來定這里解釋一下 Ramp-Up Period 的作用它表示 100 個(gè)線程在 10 秒內(nèi)全部啟動(dòng)完畢也就是說每秒啟動(dòng) 10 個(gè)線程。這樣做是為了模擬用戶逐步進(jìn)入系統(tǒng)的真實(shí)場景而不是 100 個(gè)請求在同一毫秒內(nèi)全部打到數(shù)據(jù)庫。如果你希望一開始就是滿負(fù)載可以把 Ramp-Up 設(shè)成 1 秒如果你要做階梯壓測可以用 Stepping Thread Group 插件但這個(gè)插件需要額外安裝基礎(chǔ)場景下普通線程組就夠用了。Loop Count 表示每個(gè)線程執(zhí)行多少次查詢。假如一個(gè) JDBC Request 執(zhí)行一條 SQL100 個(gè)線程 × 循環(huán) 50 次 總共 5000 次 SQL 查詢。這個(gè)總數(shù)可以用來估算壓測時(shí)長和數(shù)據(jù)庫負(fù)載。7.2 實(shí)戰(zhàn)腳本結(jié)構(gòu)一個(gè)標(biāo)準(zhǔn)的數(shù)據(jù)庫壓測腳本結(jié)構(gòu)如下測試計(jì)劃線程組100 線程10 秒內(nèi)啟動(dòng)JDBC Connection Configuration連接池配置最大連接數(shù) 100CSV Data Set Config用戶數(shù)據(jù)參數(shù)化JDBC Request執(zhí)行 SQL響應(yīng)斷言校驗(yàn)返回結(jié)果監(jiān)聽器聚合報(bào)告Aggregate Report察看結(jié)果樹View Results Tree需要注意JDBC Connection Configuration 和 CSV Data Set Config 都是配置元件Config Element它們的作用范圍是“所在層級(jí)之下的所有請求”。放在線程組下就對該線程組里的所有 JDBC Request 生效。7.3 壓測過程中的實(shí)時(shí)監(jiān)控壓測跑起來之后除了看 JMeter 的聚合報(bào)告我強(qiáng)烈建議你同時(shí)監(jiān)控?cái)?shù)據(jù)庫端的指標(biāo)。光看 JMeter 的響應(yīng)時(shí)間是不夠的你還需要知道數(shù)據(jù)庫的 CPU、內(nèi)存、連接數(shù)、慢查詢數(shù)等指標(biāo)才能完整評(píng)估數(shù)據(jù)庫性能。具體做法如果是 MySQL可以在壓測時(shí)執(zhí)行SHOW PROCESSLIST;查看當(dāng)前所有連接和正在執(zhí)行的 SQL。查看數(shù)據(jù)庫的 CPU 和內(nèi)存占用比如用top或數(shù)據(jù)庫自帶的性能監(jiān)控工具。開啟慢查詢?nèi)罩緣簻y完后分析哪些 SQL 的執(zhí)行時(shí)間超過了閾值。這一步非常重要因?yàn)?JMeter 的聚合報(bào)告只能告訴你“響應(yīng)時(shí)間變慢了”但到底慢在數(shù)據(jù)庫的哪個(gè)環(huán)節(jié)——是 CPU 打滿了、還是鎖等待、還是磁盤 IO——必須結(jié)合數(shù)據(jù)庫端的指標(biāo)來看。7.4 聚合報(bào)告怎么解讀壓測結(jié)束看聚合報(bào)告的幾個(gè)核心指標(biāo)Samples總請求數(shù)Average平均響應(yīng)時(shí)間單位毫秒Min / Max最小/最大響應(yīng)時(shí)間Std. Dev.響應(yīng)時(shí)間標(biāo)準(zhǔn)差越大說明響應(yīng)時(shí)間波動(dòng)越明顯性能越不穩(wěn)定Error %錯(cuò)誤率正常壓測場景下應(yīng)為 0%有少量錯(cuò)誤要具體分析Throughput吞吐量單位通常是req/sec意思是每秒能處理多少請求舉個(gè)例子100 個(gè)線程、循環(huán) 50 次的腳本跑完Samples 是 5000Throughput 如果是 200/sec說明數(shù)據(jù)庫每秒能扛住 200 次這個(gè) SQL 查詢。如果你把循環(huán)次數(shù)加大Throughput 會(huì)逐步逼近數(shù)據(jù)庫的極限值這個(gè)極限值就是數(shù)據(jù)庫的處理能力上限。經(jīng)驗(yàn)壓測數(shù)據(jù)庫時(shí)平均響應(yīng)時(shí)間和吞吐量要一起看。如果平均響應(yīng)時(shí)間很低但吞吐量也低說明 JMeter 本身或網(wǎng)絡(luò)成了瓶頸不是數(shù)據(jù)庫不行如果吞吐量上去了但平均響應(yīng)時(shí)間也跟著飆升這才說明數(shù)據(jù)庫開始進(jìn)入高負(fù)載狀態(tài)。8. 常見問題與排查技巧實(shí)錄8.1 連接不通ClassNotFoundException 和 URL 報(bào)錯(cuò)問題現(xiàn)象JDBC Request 報(bào)ClassNotFoundException: com.mysql.jdbc.Driver或Cannot create PoolableConnectionFactory。排查思路先看驅(qū)動(dòng) Jar 包有沒有放到 JMeter 的 lib 目錄下然后看是否重啟了 JMeter。如果確定 Jar 包在再看 Driver Class 寫對沒有——MySQL 8.x 驅(qū)動(dòng)對應(yīng)的是com.mysql.cj.jdbc.Driver不是com.mysql.jdbc.Driver。如果報(bào)錯(cuò)信息是Unknown database xxx檢查連接 URL 里的數(shù)據(jù)庫名是否正確。如果是Access denied for user檢查賬號(hào)密碼和數(shù)據(jù)庫權(quán)限。8.2 連接池不夠用Too many connections問題現(xiàn)象壓測過程中JMeter 報(bào)Too many connections或者數(shù)據(jù)庫端出現(xiàn)Connection refused。原因分析這個(gè)報(bào)錯(cuò)有兩個(gè)方向一個(gè)是 JMeter 連接池最大連接數(shù)設(shè)得太大打爆了數(shù)據(jù)庫的最大連接數(shù)另一個(gè)是數(shù)據(jù)庫自身max_connections配置太小。解決方案先查看數(shù)據(jù)庫的max_connections比如 MySQL 可以用SHOW VARIABLES LIKE max_connections;查看。然后調(diào)整 JMeter 連接池的最大連接數(shù)讓它的上限略低于數(shù)據(jù)庫的max_connections留一些余量給其他應(yīng)用連接。順便說一句做壓測之前一定要和 DBA 或運(yùn)維確認(rèn)好數(shù)據(jù)庫的連接上限否則壓到一半數(shù)據(jù)庫直接把連接全踢掉測試結(jié)果就廢了。8.3 響應(yīng)時(shí)間異常長慢 SQL 還是連接池排隊(duì)問題現(xiàn)象聚合報(bào)告顯示平均響應(yīng)時(shí)間高達(dá)幾秒遠(yuǎn)大于你手動(dòng)執(zhí)行 SQL 的時(shí)間。原因分析首先要區(qū)分是數(shù)據(jù)庫真慢還是連接池在排隊(duì)。手動(dòng)執(zhí)行 SQL 快說明 SQL 本身沒問題。這時(shí)候要去看 JMeter 連接池的最大連接數(shù)是不是小于線程數(shù)——如果 100 個(gè)線程去搶 20 個(gè)連接剩下 80 個(gè)線程全在等連接響應(yīng)時(shí)間自然飆升。解決方案把 Max Number of Connections 調(diào)大使其等于或大于線程數(shù)再跑一次對比。如果響應(yīng)時(shí)間正常了說明之前的瓶頸是連接池如果響應(yīng)時(shí)間依然很大那就要去數(shù)據(jù)庫端看慢查詢?nèi)罩径ㄎ皇遣皇撬饕?、鎖等待等問題。還有一個(gè)細(xì)節(jié)如果連接 URL 設(shè)置了socketTimeout當(dāng)數(shù)據(jù)庫處理查詢超過這個(gè)值時(shí)JMeter 會(huì)直接報(bào) socket 超時(shí)。這種情況下不是數(shù)據(jù)庫變慢而是策略性地?cái)嚅_了連接。壓測時(shí)可以把 socketTimeout 調(diào)大一點(diǎn)避免誤判。8.4 變量引用出來是 null結(jié)果集行號(hào)與字段大小寫問題現(xiàn)象在后續(xù)請求里用${var_1_id}引用 JDBC 查詢結(jié)果發(fā)現(xiàn)值是 null 或者空字符串。原因排查第一先看結(jié)果集是不是空的。如果 SQL 查不出來數(shù)據(jù)任何引用都是空。用察看結(jié)果樹看響應(yīng)數(shù)據(jù)確認(rèn)是否有數(shù)據(jù)返回。第二看字段名大小寫。MySQL 的字段名默認(rèn)全小寫如果 SQL 里寫了別名比如SELECT id AS userId FROM user那么引用時(shí)要寫成${var_1_userId}。建議 SQL 里起別名時(shí)統(tǒng)一用帶下劃線的命名如user_id然后引用時(shí)保持大小寫一致。第三行號(hào)從 1 開始不是從 0 開始。如果變量名是order_result那么第一行是order_result_1沒有order_result_0這個(gè)變量。8.5 中文亂碼與編碼問題問題現(xiàn)象JDBC 查詢返回的中文變成問號(hào)或亂碼。原因排查大多是連接 URL 里沒有指定字符集。在 MySQL 連接 URL 上加上characterEncodingutf8jdbc:mysql://127.0.0.1:3306/testdb?useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/ShanghaicharacterEncodingutf8另外檢查數(shù)據(jù)庫表本身的字符集是不是 utf8mb4。如果表是 latin1 而應(yīng)用按 utf8 讀取也會(huì)亂碼。8.6 一個(gè)容易被忽略的問題壓測機(jī)性能不夠最后提一個(gè)很多人踩過的坑——壓測機(jī)本身的性能不夠。JMeter 是 Java 應(yīng)用100 個(gè)并發(fā)線程跑起來時(shí)壓測機(jī) CPU 和內(nèi)存消耗不小。如果你在本地筆記本上壓遠(yuǎn)程數(shù)據(jù)庫壓測結(jié)果可能不是你 SQL 的真實(shí)性能而是筆記本 CPU 打滿后的結(jié)果。怎么判斷壓測時(shí)打開任務(wù)管理器或top看看 Java 進(jìn)程的 CPU 占用率。如果已經(jīng)超過了機(jī)器 CPU 的 70% 以上建議換一臺(tái)性能更強(qiáng)的機(jī)器或者把 JMeter 部署到另一臺(tái)服務(wù)器上盡量讓壓測機(jī)資源充足確保瓶頸在數(shù)據(jù)庫端而不是客戶端。8.7 問題排查速查表問題現(xiàn)象可能原因解決方案ClassNotFoundException驅(qū)動(dòng) Jar 未放到 lib 目錄放入 Jar 包并重啟 JMeterCannot create PoolableConnectionFactoryURL 或賬號(hào)密碼錯(cuò)誤檢查 URL 格式、賬號(hào)權(quán)限Too many connections連接數(shù)超過數(shù)據(jù)庫上限調(diào)大數(shù)據(jù)庫 max_connections 或調(diào)小 JMeter 連接池響應(yīng)時(shí)間超長連接池排隊(duì)或慢 SQL調(diào)大連接池查看慢查詢?nèi)罩咀兞恐禐?null結(jié)果集為空或字段名大小寫不一致確認(rèn)查詢結(jié)果檢查 SQL 別名中文亂碼連接 URL 未指定字符集添加 characterEncodingutf8壓測結(jié)果不穩(wěn)定壓測機(jī)資源不足更換壓測機(jī)或降低線程數(shù)9. 一個(gè)完整的數(shù)據(jù)庫壓測腳本示例講了這么多最后給你一個(gè)完整的 MySQL 壓測腳本搭建過程從零到一可以直接照抄。9.1 測試場景模擬 100 個(gè)用戶并發(fā)查詢訂單表每個(gè)查詢根據(jù)不同的訂單 ID 查詢訂單信息持續(xù)壓測 10 分鐘觀察數(shù)據(jù)庫的吞吐量和響應(yīng)時(shí)間變化。9.2 準(zhǔn)備工作MySQL 數(shù)據(jù)庫提前創(chuàng)建好訂單表orders字段包括order_id、user_id、amount、status準(zhǔn)備一個(gè)order_ids.csv文件里面放 100 個(gè)訂單 ID用于參數(shù)化JMeter 5.xmysql-connector-java-8.0.x.jar已放入 lib 目錄并重啟9.3 腳本搭建步驟第一步創(chuàng)建測試計(jì)劃并添加線程組線程數(shù) 100Ramp-Up 10 秒循環(huán)次數(shù)勾選無限在調(diào)度器配置里設(shè)置持續(xù)時(shí)間為 600 秒。第二步添加 JDBC Connection Configuration配置項(xiàng)如下Variable Name for created poolmysql_poolMax Number of Connections100Max Wait10000Auto CommitTruePool Validation QuerySELECT 1Database Connection ConfigurationDatabase URLjdbc:mysql://127.0.0.1:3306/testdb?useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/ShanghaiJDBC Driver Classcom.mysql.cj.jdbc.DriverUsernametest_userPasswordyour_password第三步添加 CSV Data Set ConfigFilename/data/order_ids.csvVariable Namesorder_idDelimiter,Recycle on EOFTrueStop thread on EOFFalseSharing modeAll threads第四步添加 JDBC RequestVariable Name of Poolmysql_poolQuery TypePrepared Select StatementQuerySELECT * FROM orders WHERE order_id ?Parameter values${order_id}Parameter typesVARCHAR這里說明一下因?yàn)?SQL 里有?占位符所以 Query Type 必須選 Prepared Select StatementParameter values 里填 CSV 讀取出來的訂單 IDParameter types 填數(shù)據(jù)庫字段類型。第五步添加響應(yīng)斷言Field to TestText ResponsePattern Matching RulesContainsPatterns to Testorder_id這樣就確保了查詢請求返回的結(jié)果中包含 order_id 字段證明查詢是成功的。第六步添加監(jiān)聽器加一個(gè)聚合報(bào)告和一個(gè)察看結(jié)果樹。壓測結(jié)束后聚合報(bào)告里可以看到平均響應(yīng)時(shí)間、吞吐量、錯(cuò)誤率等核心數(shù)據(jù)。9.4 跑完怎么分析壓測結(jié)束后我一般這么看數(shù)據(jù)先看錯(cuò)誤率。如果錯(cuò)誤率為 0%說明 100 并發(fā)下這條 SQL 沒有出錯(cuò)數(shù)據(jù)庫連接和查詢都正常。如果錯(cuò)誤率大于 0查詢具體的錯(cuò)誤信息常見的是連接池不夠用或超時(shí)。然后看吞吐量變化。如果 JMeter 的 Throughput 在持續(xù)穩(wěn)定上升后趨于平緩說明已經(jīng)摸到了數(shù)據(jù)庫的處理上限。此時(shí)如果平均響應(yīng)時(shí)間還能接受說明數(shù)據(jù)庫還有冗余如果響應(yīng)時(shí)間已經(jīng)超標(biāo)比如超過 500ms說明數(shù)據(jù)庫快要撐不住了。最后結(jié)合數(shù)據(jù)庫端監(jiān)控比如 CPU、慢查詢?nèi)罩究雌款i到底在哪個(gè)環(huán)節(jié)然后給出測試結(jié)論和優(yōu)化建議。這里有一個(gè)小建議壓測時(shí)先把線程數(shù)保守一點(diǎn)比如 50跑一輪看結(jié)果再逐步升到 100、200。這樣做的好處是你能看到數(shù)據(jù)庫在不同并發(fā)下的表現(xiàn)曲線而不是一上來就壓到天花板拿到一堆根本沒法分析的數(shù)據(jù)。階梯式加壓是我在實(shí)際項(xiàng)目中比較喜歡用的方式。最后說幾句實(shí)在話用 JMeter 做數(shù)據(jù)庫壓測門檻真的不高但想做好需要你對數(shù)據(jù)庫本身的運(yùn)行機(jī)制有基本認(rèn)知。我在實(shí)際測試項(xiàng)目里見過不少人把壓測腳本配好了、跑出了漂亮的報(bào)告但一問數(shù)據(jù)庫端的指標(biāo)完全答不上來——CPU 多少、內(nèi)存多少、慢查詢有沒有、連接數(shù)有沒有到上限全是空白。這種壓測報(bào)告說實(shí)話價(jià)值有限。我的個(gè)人建議是壓測數(shù)據(jù)庫永遠(yuǎn)要把 JMeter 端的數(shù)據(jù)和數(shù)據(jù)庫端的數(shù)據(jù)結(jié)合起來看。JMeter 告訴你發(fā)生了什么數(shù)據(jù)庫的監(jiān)控告訴你為什么會(huì)發(fā)生。兩邊對照才能真正判斷數(shù)據(jù)庫的性能瓶頸在哪里也才能給出可信的測試結(jié)論。如果你只是剛接觸這塊先從最簡單的單條 SQL 查詢壓測入手把 JDBC Connection Configuration 和 JDBC Request 玩熟再慢慢加參數(shù)化、加斷言、加并發(fā)場景。不要一上來就想測多表關(guān)聯(lián)或存儲(chǔ)過程底子打好后面的內(nèi)容都是水到渠成的事。