簡介
BenchmarkSQL是一款經典的開源數據庫測試工具，內嵌了TPCC測試腳本，可以對PostgreSQL、Oracle以及Firebird等數據庫進行測試.。
TPC-C 於 1992 年 7 月 23 日認可為新的基准測試。TPC(Transaction Processing Performance Council，事務處理性能委員會)-C是衡量聯機事務處理（OLTP，Online TransactionProcessing）系統的工業標准，是行業中公認的權威和最為復雜的在線事務處理基准測試。它通過模擬倉庫和訂單管理系統，測試廣泛的數據庫功能，包括查詢、更新和 mini-batch事務（隊列式小批量事務）。TPC-C基准測試針對一種模擬訂單錄入與銷售環境測量每分鍾事務（tpmC-transactions per minute）吞吐量。
測試模型
測試用到的模型是一個大型的批發銷售公司，在地理分布的多個區域有業務，並且使用倉庫管理。當業務擴展的時候，公司將添加新的倉庫。每個倉庫負責十個區域的供貨，每個區域 3000 個客戶服務，每個倉庫維護 100000 種商品的庫存紀錄。
TPC-C 標准測試模擬了 5 種事務處理，通過這些事務處理來模擬真實的用戶操作,事務分別為新訂單（New-Order）、支付操作(Payment)、訂單狀態查詢(Order-Status)、發貨(Delivery)、庫存狀態查詢(Stock-Level)。下面將對其執行的事務內容及特點進行詳細介紹.
1．新訂單（New-Order）
事務內容：對於任意一個客戶端,從固定的倉庫隨機選取 5-15 件商品,創建新訂單.其中 1%的訂單要由假想的用戶操作失敗而回滾。
主要特點：中量級、讀寫頻繁、要求響應快.
2．支付操作(Payment)
事務內容：對於任意一個客戶端,從固定的倉庫隨機選取一個轄區及其內用戶,采用隨機的金額支付一筆訂單,並作相應歷史記錄。
主要特點：輕量級，讀寫頻繁，要求響應快
3．訂單狀態查詢(Order-Status)
事務內容：對於任意一個客戶端,從固定的倉庫隨機選取一個轄區及其內用戶,讀取其最后一條訂單,顯示訂單內每件商品的狀態。
主要特點：中量級，只讀頻率低，要求響應快
4．發貨(Delivery)
事務內容：對於任意一個客戶端,隨機選取一個發貨包,更新被處理訂單的用戶余額,並把該訂單從新訂單中刪除.
主要特點：1-10 個批量，讀寫頻率低，較寬松的響應時間
5．庫存狀態查詢(Stock-Level)
事物內容：對於任意一個客戶端,從固定的倉庫和轄區隨機選取最后 20 條訂單,查看訂單中所有的貨物的庫存,計算並顯示所有庫存低於隨機生成域值的商品數量.
主要特點：重量級,只讀頻率低,較寬松的響應時間.
演示環境
PostgreSQL：13.0
OS:CentOS 8
openjdk version "1.8.0_292"
ant：1.10.5
benchmarksql：5.0
獲取版本
訪問官網獲取最新版本benchmarksql-5.0.zip
https://sourceforge.net/projects/benchmarksql/
編譯
unzip benchmarksql-5.0.zip ant
配置參數
進入run目錄，配置如下參數
vi props.pg
db=postgres driver=org.postgresql.Driver conn=jdbc:postgresql://localhost:5432/postgres user=benchmarksql password=PWbmsql warehouses=1 loadWorkers=4 terminals=1 //To run specified transactions per terminal- runMins must equal zero runTxnsPerTerminal=10 //To run for specified minutes- runTxnsPerTerminal must equal zero runMins=0 //Number of total transactions per minute limitTxnsPerMin=300 //Set to true to run in 4.x compatible mode. Set to false to use the //entire configured database evenly. terminalWarehouseFixed=true //The following five values must add up to 100 //The default percentages of 45, 43, 4, 4 & 4 match the TPC-C spec newOrderWeight=45 paymentWeight=43 orderStatusWeight=4 deliveryWeight=4 stockLevelWeight=4 // Directory name to create for collecting detailed result data. // Comment this out to suppress. resultDirectory=my_result_%tY-%tm-%td_%tH%tM%tS osCollectorScript=./misc/os_collector_linux.py osCollectorInterval=1 //osCollectorSSHAddr=user@dbhost osCollectorDevices=net_eth0 blk_sda
主要參數解釋如下
| 參數 | 值 | 說明 |
|---|---|---|
| db | postgres | 指定數據庫類型（修改后增加的數據庫類型） |
| driver | org.postgresql.Driver | 數據庫的驅動類名稱，不需要更改 |
| conn | jdbc:postgresql://localhost:5432/postgres |
連接字符串，需要更改localhost為對應pg服務IP、5432位對應pg服務端口、postgres為對應測試數據庫名 |
| user | postgres | 用戶名 |
| password | 123456 | 用戶密碼 |
| warehouses | 10 | 初始化加載數據時，需要創建多少倉庫的數據。每倉庫約80MB數據,數量根據實際服務器內存配置。 |
| loadWorkers | 4 | 表示加載數據時，開啟加載數據的進程數，加載速度會隨worker數量的增加而有所提升。 |
| terminals | 20 | 終端數量，指同時有多少終端並發執行，通常設置為CPU線程總數的2～6倍 |
| runTxnsPerTerminal | 0 | 每個終端（terminal）運行的固定事務數量，例如：如果該值設置為10，意味着每個terminal運行10個事務，如果有32個終端，那整體運行320個事務后，測試結束。該參數配置為非0值時，下面的runMins參數必須設置為0 |
| runMins | 1 | 要測試的整體時間，單位為分鍾，如果runMins設置為60，那么測試持續1小時后結束。該值設置為非0值時，runTxnsPerTerminal參數必須設置為0。這兩個參數不能同時設置為正整數，如果設置其中一個，另一個必須為0，主要區別是runMins定義時間長度來控制測試時間；runTxnsPerTerminal定義事務總數來控制時間。 |
| limitTnxsPermin | 0 | 限制每分鍾執行的事務總數。0表示不限制 |
| terminalWarehouseFixed | true | 用於指定終端和倉庫的綁定模式，設置為true時可以運行4.x兼容模式，意思為每個終端都有一個固定的倉庫。設置為false時可以均勻的使用數據庫整體配置，TPCC規定每個終端都必須有一個綁定的倉庫，所以一般使用默認值true。 |
數據准備
創建數據庫表並加載數據
./runDatabaseBuild.sh props.pg
執行測試
執行如下命令開始測試
./runBenchmark.sh props.pg
測試完后會顯示簡要的測試結果，包括平均tpmC值（每分鍾執行的事務數--每分鍾能夠處理的訂單數量），tpmTOTAL（總訂單量）等等。
流量指標(Throughput,簡稱tpmC)：按照TPC組織的定義，流量指標描述了系統在執行支付操作、訂單狀態查詢、發貨和庫存狀態查詢這4種交易的同時，每分鍾可以處理多少個新訂單交易。所有交易的響應時間必須滿 足TPC-C測試規范的要求，且各種交易數量所占的比例也應該滿足TPC-C測試規范的要求。在這種情況下，流量指標值越大說明系統的聯機事務處理能力越高。
生成報告
生成圖形的腳本generateReport.sh要求操作系統環境中已經安裝了R語言
./generateReport.sh my_result_2021-05-23_175724
可以通過html查看生成的報告
重新運行測試
執行runDatabaseDestroy.sh腳本帶配置文件可以將所有的數據和表都刪除，然后再重新修改配置后運行測試。