TPC-H測試標準，以8張表，22個查詢作為基礎，在一定時間內(通常是1小時)，通過7個并發查詢，衡量數據庫的每秒處理事務數，作為數據庫性能度量標準。用一個公式來描述整個過程，就是 QphH@Size.

2018 年，惠普使用 microsoft sql server on linux 作為測試對象，向 TPC 組織， 提交了一次TPC-H性能報告。

在1T的數據量下，花費近47萬美金，達到了每小時100萬的查詢數，即每秒可完成280查詢。公式表達，1009065.5 QphH@1000GB.

當然，這還沒考慮到查詢性能的可接受程度，以27.6s這樣的平均速，其實很多用戶是會不滿意的。

這份報告雖然說明一定的問題，比如 Throughput 度量，性價比，但缺少對服務器的性能監控。比如7個并發，1小時連續壓測下，服務器的性能監控圖。

再者，數據庫的最終吞吐量，是否可以再擴大，也沒有具體說明白。如果降低并發，是不是能夠獲得較好的性能？

為了模擬惠普的這次測試，我通讀了TPC-H的測試標準，惠普的這份測試報告，還有幾篇來自維普的論文。最終找到了模擬的方法。

以下是詳細的測試步驟：

1）下載 HammerDB 軟件
2）準備 SQL Server 測試環境
3）復現 Power Test
4) 復現 Throughput Test

1) 下載 HammerDB

公眾號后臺回復 HammerDB，即可得到 zip 版本的 HammerDB 連接。

解壓縮后，直接打開，就可以使用

2）準備 SQL Server 測試環境

這就要自己準備了，到微軟的官方網站下載180天的試用版，即可

3）復現 Power Test

由于這次模擬的是 SQL Server TPC-H 測試標準，所以在 HammerDB 中，我們需要預先配置：

第一次打開 HammerDB 是這樣的，以 Oracle TPC-C 為默認選中狀態：

通過菜單 Options, 配置 SQL Server TPC-H 測試標準：

在 TPC-H 整套測試方案中，指定了8張表，22個查詢，配備相應的數據生成程序與查詢生成程序，但這兩個程序都是使用c/c++寫的，必須先通過編譯，再通過調用接口來用在自己的測試方案中，我嘗試了下，放棄！不僅源碼復雜，有些環境還需要額外配置。

在搜索了 n 篇論文以及博文之后，我發現 HammerDB 已經替我們把這些環境配置都搞定了，于是就它了。

有了 HammerDB,我們唯一要做的事情，就是指定一個可用的測試數據庫就可以。

這里需要說明的是 Scale Factor，也就是擴展因子。說人話，就是數據庫大小配置。總共可以分為6級，1GB,10GB,30GB,100GB,300GB,1000GB.

那么既然是自己測試，選擇1，即1GB，就可以了

點一下 Build，就完成了數據庫環境配置。

通過 SQL Server Profiler, 我們可以看到數據庫正在發生的一切：

通過 HammerDB 的Build界面，可以看到執行狀態:

當然，時間會很久，我們可以去喝一杯咖啡再來，HammerDB會自動報告，數據裝載是否完成：

由于裝載時間非常長，所以一旦數據庫建立成功，我們就要對它進行備份:

接下來，我們就要試著運行一次 Power Test:

首先配置 Driver Script:

Driver Script 做的事情，就是為測試中的虛擬用戶，配置執行的操作。比如配置一組22個查詢組成的查詢流，讓虛擬用戶在登錄數據庫，依次執行這22個查詢。

配置完 Driver Script, 我們就可以生成指定數量的并發用戶。這些用戶，可以執行剛才配置的 Driver Script.

Power Test 測試目的，是察看是否有明顯的響應時間缺陷，所以設置單個用戶：

一旦配置完成，就可以雙擊 Create 來生成虛擬用戶的配置信息：

接著，我們點擊運行單用戶的單次執行：

耐心等待測試完成：

單輪測試用了124秒，似乎不夠理想。但這是我可憐的筆記本虛擬機服務器啊。

然后，肯定會有讀者說，這是數據倉庫啊，不能沒有寫入的操作啊。是的，這個寫入，我們也可以模擬，通過開啟 Refresh Function:

然后再重復新建用戶，并開啟測試。

4）復現 Throughput Testing

Throughput 是吞吐量的意思，這個概念很有意思。

首先來說說并發用戶。當同時有10個用戶訪問數據庫時，假設他們同時執行1條 SELECT 語句。此時，并發數是10，Throughput 也是10，但你能不能說數據庫并發度不夠呢？不能。因為此時這并發的10個用戶，都對速度感到滿意，說明完全可以再容納更多的人來數據庫查詢。

于是，增加了100個人來，還是運行 一條SELECT語句。那么此時，如果大家還是對響應很滿意，說明數據庫非常棒，還可以吸納更多的人。

好，加20倍流量，來了200人。于是，有用戶反映，速度慢了，明顯慢了一倍以上，當有50%的人都說慢了的時候，顯然數據庫的吞吐量，要小于 200.

我們往下調調，來150人吧。此時90%以上的人，對速度滿意，那么就可以說，數據庫的吞吐量在 150左右了。

這，就是 TPC-H 測試標準報告中，要體現的內容了。不過，人家更標準，使用的是 QphH@Size.

所以，我們要使用 hammerDB來模擬這個操作：

首先設置4個并發用戶，第一個用戶會模擬寫入的操作：

開啟 QphH@Size 的統計功能：

等待測試完成

理論上，測試時間越長，測試的準確度越高，但我們只是模擬，所以運行一組 Query Set, 讓 HammerDB 幫我們預估就可以了：

可以看到，4個并發測試下來，大概可以得到每小時近20000個事務處理。也就是每秒鐘處理6個事務。

那么是不是 Throughput 為6，就是我的數據庫極限了呢，我懷疑，可以更高。于是我調高了用戶并發數，加了2個，再來看 QphH:

發現，最高的 QphH 雖然比4個用戶那次高，但明顯已經影響了用戶的響應時間，普遍從原來的100s 延長到了160s 以上。說明，已經不能再增加并發查詢了，6事務/秒已經是我這臺數據庫的極限。

很可惜的是，HammerDB 并不能動態增加用戶數，導致測試不流暢，不得不說是個遺憾。我看到 oracle 廠商在 demo 他們的系統時，并發用戶數，是動態可加的，想加就加，相減就減，操作隨意地令人發指。提高了測試的準確度。

說Oracle是世界，乃至宇宙第一，還不得不服。

總結

以上是生活随笔為你收集整理的dialog能提交数据吗_你的数据库，能撑起多少并发，有数吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。