評估 AlloyDB for PostgreSQL 的 OLTP 效能

如要評估 AlloyDB for PostgreSQL 中交易工作負載的處理量和延遲時間，您可以設定 AlloyDB 和用戶端機器，使用 TPC-C (業界標準 OLTP 基準規格) 基準測試線上交易處理 (OLTP) 效能。您也可以執行自訂的讀取和寫入密集型 OLTP 情境，例如「僅限索引插入」和「僅限選取」。

本文件中的操作說明是以 AlloyDB 和用戶端機器的特定設定為基礎。請按照基準測試操作說明，在每個步驟使用提供的值。

AlloyDB 工作負載功能

AlloyDB 提供企業級的可靠性、擴充性和效能，適用於所有企業和重要工作負載。AlloyDB 提供下列元件和功能，可為交易 (OLTP)、分析 (OLAP) 和混合 (HTAP) 工作負載提供高效能：

  • 記錄和交易管理
  • 動態記憶體管理
  • 整合人工智慧與機器學習
  • 內建資料欄引擎
  • 多層快取
  • 分散式且可擴充的儲存空間

關聯式資料庫系統通常需要資料庫管理員最佳化資料庫，才能進行基準測試，包括設定交易記錄、建立適當的緩衝集區大小，以及修改其他資料庫參數或旗標和特性。這些設定會因執行個體大小和類型而異。

AlloyDB 已預先設定各機型的最佳化設定。AlloyDB 不需在資料庫層級調整旗標，就能達到高 OLTP 效能，因為 AlloyDB 本身就具備高 OLTP 效能。

支援的基準類型

本文說明如何使用下列工具執行 OLTP 基準測試：

OLTP 基準測試驅動程式 用途
HammerDB HammerDB 會以每分鐘交易數 (TPM) 衡量系統效能，並產生包含詳細統計資料和成效指標的報表。

HammerDB 支援基準參數自訂功能，可讓您調整資料庫大小、倉儲數量和其他工作負載特性，模擬不同情境。

HammerDB 包含 TPC-C 基準測試實作，可用於評估 OLTP 系統的效能。HammerDB TPC-C 實作可讓您模擬類似 TPC-C 基準的工作負載，包括模擬批發供應商環境行為的混合交易。
pgbench pgbench 是 PostgreSQL 隨附的基準測試工具，可讓您模擬交易工作負載，例如插入、更新、選取資料，以及測量資料庫系統的每秒交易數 (TPS) 效能。

使用 pgbench 時，您可以自訂資料庫大小、用戶端數量和交易組合，模擬實際工作負載，並深入瞭解系統在不同情境下的行為。
pgbench 包含 TPC-B 實作。pgbench TPC-B 實作與 TPC-B 基準測試類似。

事前準備

  1. 登入 Google Cloud 帳戶。如果您未曾使用過 Google Cloud，歡迎 建立帳戶，親自體驗實際使用我們產品的成效。新客戶還能獲得價值 $300 美元的免費抵免額，用於執行、測試及部署工作負載。

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

  4. Enable the AlloyDB, Compute Engine, and Resource Manager APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  5. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  6. Verify that billing is enabled for your Google Cloud project.

  7. Enable the AlloyDB, Compute Engine, and Resource Manager APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

    8.

  8. 啟用必要的 Cloud API，以便建立及連線至 AlloyDB for PostgreSQL。

    啟用 API

    1. 在「確認專案」步驟中，點選「下一步」，確認要變更的專案名稱。

    2. 在「啟用 API」步驟中，點選「啟用」來啟用下列項目：

      • AlloyDB API
      • Compute Engine API
      • Cloud Resource Manager API
      • Service Networking API

      如果您打算使用與 AlloyDB 位於相同 Google Cloud 專案的虛擬私有雲網路，設定 AlloyDB 的網路連線，就必須啟用 Service Networking API。

      如要使用位於其他 Google Cloud 專案的虛擬私有雲網路，設定 AlloyDB 的網路連線，則須啟用 Compute Engine API 和 Cloud Resource Manager API。

設定及佈建資料庫和用戶端機器

建立 AlloyDB 叢集和執行個體，開始進行基準測試。除非另有說明，否則本文件中的資訊是以 16 個 vCPU 和 128 GB RAM 的主要 AlloyDB 執行個體為依據。

建立 AlloyDB 叢集和執行個體

  1. 前往「Clusters」(叢集) 頁面。

    前往叢集

  2. 點選「建立叢集」。

  3. 在「Cluster ID」(叢集 ID) 欄位中，輸入叢集名稱。

  4. 在「可用區可用性」部分，選取「多個可用區 (可用性高)」做為叢集類型。

  5. 選取預設網路。

  6. 在「Database version」(資料庫版本) 欄位中，選取下列其中一個選項：

    • PostgreSQL 17

    • PostgreSQL 18

  7. 記下主要可用區的位置和私人 IP 位址。不建立讀取集區。

  8. 點選「建立叢集」。

佈建用戶端機器

如要執行 OLTP 基準測試，您需要具備足夠處理能力的用戶端機器。HammerDB 和 pgbench 等基準測試工具會以高度平行的方式執行，並耗用大量 CPU。執行 OLTP 基準測試時，用戶端機器不得成為瓶頸。

除非另有指定，否則本文件中的操作說明會使用搭載 128 GB 磁碟的 E2-standard-32 機器，做為 OLTP 基準測試的用戶端，在搭載 128 GB RAM 的 16 個 vCPU 機器上驅動 AlloyDB 執行個體。您必須在 AlloyDB 主要執行個體所在的可用區中建立用戶端機器。

如要在具備 16 個虛擬 CPU 的 AlloyDB 主要執行個體上執行 TPC-C 基準測試，請按照下列步驟建立 Compute Engine VM 並佈建用戶端機器：

  1. 前往 Google Cloud 控制台的「VM instances」(VM 執行個體) 頁面。

    前往 VM 執行個體

  2. 選取要連線的 AlloyDB 執行個體所在專案。
  3. 點選「建立執行個體」。
  4. 按一下「機器設定」部分。
  5. 輸入執行個體的「Name」(名稱)。
  6. 設定要建立執行個體的可用區。可用區必須與 AlloyDB 主要執行個體的可用區相同。
  7. 選取機型「e2-standard-32」。
  8. 保留「OS 和儲存空間」專區的預設值。
  9. 按一下「Networking」(網路) 專區，然後將「Network interfaces」(網路介面) 設為已設定私人服務存取 AlloyDB 的虛擬私有雲網路。
    如果「網路介面」未設為已設定私人服務存取權的虛擬私有雲網路，請展開該區段，然後將「網路」設為該虛擬私有雲網路。
  10. 保留「觀測能力」部分的預設值。
  11. 按一下「安全性」部分。
  12. 在「身分及 API 存取權」部分，將「存取權範圍」設為「允許所有 Cloud API 的完整存取權」。
  13. 保留「Advanced」(進階) 區段中的預設值。
  14. 點選「建立」。
  15. VM 建立完成後，請使用 SSH 連線至您建立的 Compute Engine VM。

設定基準測試驅動程式機器

安裝並設定資料庫和用戶端機器後，請設定在 Google Cloud上執行的用戶端機器，並在其中安裝 HammerDB 和 pgbench 等基準測試工具。

如要設定基準測試驅動程式機器，請按照下列步驟操作：

  1. 使用下列 gcloud compute ssh 指令連線至用戶端機器：

    gcloud compute ssh --zone "PRIMARY_ZONE" "CLIENT_MACHINE_NAME"  --project "GOOGLE_PROJECT"

  2. 安裝 PostgreSQL 用戶端。

    1. 使用下列指令安裝 PostgreSQL 用戶端 (包含 psql 應用程式)，然後確認可以連線。

      sudo apt-get update
sudo apt install postgresql-client

    2. 請使用下列指令，確認用戶端正常運作，且可連線至 AlloyDB。請使用主要 AlloyDB 執行個體的私人 IP 位址。

      psql -h PRIVATE_IP -U postgres

  3. 執行下列指令，安裝 TPC-C 基準測試的 HammerDB-4.6 驅動程式：

    mkdir hammerdb
pushd hammerdb
curl -OL https://github.com/TPC-Council/HammerDB/releases/download/v4.6/HammerDB-4.6-Linux.tar.gz
tar zxvf HammerDB-4.6-Linux.tar.gz

  4. 執行下列指令，安裝 TPC-B 和其他 OLTP 基準測試的 pgbench 驅動程式：

    sudo apt-get update
sudo apt-get install postgresql-contrib
pgbench --version

    如果 pgbench --version 執行時未發生錯誤，表示已安裝 pgbench。

執行基準測試清除作業

如果您打算連續執行多項基準測試，則必須在每項基準測試之間執行基準測試清除作業，確保基準測試結果準確可靠。

基準測試清除作業可確保先前基準測試的殘留影響不會影響新基準測試的效能評估。基準測試清理作業也有助於確保基準測試結果的一致性和可重複性，這對於在不同系統之間進行有意義的比較，或找出硬體、軟體或設定中的最佳化領域至關重要。

請按照下列步驟執行基準測試清理作業，再執行其他基準測試：

  1. 刪除先前的基準資料或基準資料庫。如要捨棄先前的基準資料庫，請在用戶端機器上使用下列 psql 指令：

    psql -h PRIVATE_IP -U postgres -c "DROP DATABASE IF EXISTS <database_name>;"

    如要進一步瞭解如何使用 psql，請參閱「連線至資料庫」。

  2. 重新啟動 AlloyDB 執行個體。這個步驟會清除資料庫和作業系統層級的快取。

執行 TPC-C 基準測試

HammerDB 是一種基準測試工具，內含 TPC-C 基準測試實作，可用於評估 OLTP 系統的效能。HammerDB 的 TPC-C 實作可讓您模擬類似 TPC-C 基準的工作負載，包括模擬批發供應商環境行為的混合交易。

HammerDB 會以每分鐘交易數 (TPM) 為單位評估系統效能，並產生包含詳細統計資料和成效指標的報表。此外，HammerDB 支援自訂基準測試參數，使用者可以調整資料庫大小、倉儲數量和其他工作負載特性，模擬不同情境。

成效評估情境

TPC-C 基準測試的效能評估方法如下：

  • 部分 (~30%) 快取模式：在這個模式中，系統會產生大型 TPC-C 資料庫，但只能部分放入緩衝區快取。這個模式中的交易不一定會從記憶體提供，且會對基礎儲存子系統產生 I/O。這個情境適用於許多使用者的 OLTP 需求。

  • 完全 (100%) 快取模式：在這個模式中，TPC-C 資料庫完全符合緩衝區快取。AlloyDB 執行個體使用約 90% 的可用 128 GB RAM，包括緩衝區快取。

    由於 TPC-C 交易執行的 I/O 極少 (因為讀取作業大多由緩衝區快取提供)，因此在這種模式下，預期 TPM 會高於部分快取的執行作業。這個情境適用於 I/O 需求極低的使用者，可滿足其 OLTP 需求。

設定用戶端機器

  1. 設定基準測試驅動程式機器。

  2. 如果您連續執行多項基準測試，請執行基準測試清除作業。

  3. 執行下列指令，開啟 hammerdb/HammerDB-4.6 directory：

    cd hammerdb/HammerDB-4.6

    您會從這個目錄執行指令，設定用戶端機器。

  4. 使用下列指令建立 setup.env 檔案：

    cat << EOF > setup.env
# Private IP of the AlloyDB primary instance
export PGHOST=PRIVATE_IP
# Postgres default port address. You do not need to change it unless you use non-default port address.
export PGPORT=5432   # default port to connect with postgres
# Number of TPC-C warehouses to load. This determines the overall database size.
export NUM_WAREHOUSE=576
# Number of users for running the benchmark.
export NUM_USERS=256
EOF

  5. 編輯產生的 setup.env 檔案，將所有醒目顯示的參數值，替換為最適合您環境設定的參數值。

  6. 選用：在 setup.env 檔案中，將 NUM_WAREHOUSE 變更為 3200，測試部分 (~30%) 快取模式。詳情請參閱「效能評估情境」。

  7. 選用：在 setup.env file 中將 NUM_WAREHOUSE 變更為 576，測試完全 (100%) 快取模式。詳情請參閱「效能評估情境」。

將 TPC-C 資料載入資料庫

載入步驟是指在執行效能測試前，先將初始資料填入基準測試資料庫。

在載入步驟中，系統會根據 TPC-C 規格，在資料庫中填入指定數量的倉儲、客戶和其他實體。載入步驟的目的是為效能測試建立實際工作負載，並確保不同系統的測試結果具有可比較性。

載入步驟完成後，資料庫會處於一致狀態，並有一組定義的初始資料，可供 TPC-C 基準測試使用。

如要載入 TPC-C 資料庫，請按照下列步驟操作：

  1. 使用下列指令，切換至基準主目錄：

    cd hammerdb/HammerDB-4.6

  2. 複製下列內容並貼到 build-tpcc.sh：

    #!/bin/bash -x

source ./setup.env

# create role tpcc with superuser login as 'postgres' and password as 'AlloyDB#123';
# -----------------------------------------------------

./hammerdbcli << EOF

# CONFIGURE PARAMETERS FOR TPCC BENCHMARK
# --------------------------------------
dbset db pg
dbset bm tpc-c

# CONFIGURE POSTGRES HOST AND PORT
# --------------------------------------
diset connection pg_host $PGHOST
diset connection pg_port $PGPORT

# CONFIGURE TPCC
# --------------------------------------
diset tpcc pg_superuser postgres
diset tpcc pg_superuserpass AlloyDB#123
diset tpcc pg_user tpcc
diset tpcc pg_pass AlloyDB#123
diset tpcc pg_dbase tpcc

# SET NUMBER OF WAREHOUSES AND USERS TO MANAGE EACH WAREHOUSE
# THIS IMPORTANT METRIC ESTABLISHES THE DATABASE SCALE/SIZE
# --------------------------------------
diset tpcc pg_count_ware $NUM_WAREHOUSE
diset tpcc pg_num_vu 10

# LOG OUTPUT AND CONFIGURATION DETAILS
# --------------------------------------
vuset logtotemp 1
print dict

# CREATE AND POPULATE DATABASE SCHEMA
# --------------------------------------
buildschema

waittocomplete
vudestroy
quit

EOF

  3. 執行下列載入指令，並等待指令執行完畢。

    chmod +x ./build-tpcc.sh
mkdir results
sudo nohup ./build-tpcc.sh > results/build-tpcc.out 2>&1

  4. 驗證載入作業。前一個指令碼完成後，建議您確認資料庫是否已成功載入。如要確認資料庫大小，請執行下列指令：

    psql -h $PGHOST -p 5432 -U postgres
postgres=> \l+ tpcc
                                                                          List of databases
     Name     |      Owner       | Encoding | Collate |  Ctype  |           Access privileges           |  Size   | Tablespace |                Description
 --------------+------------------+----------+---------+---------+---------------------------------------+---------+------------+--------------------------------------------
 tpcc         | tpcc             | UTF8     | C.UTF-8 | C.UTF-8 |                                       | --- GB  | pg_default |
           |                  |          |         |         |                                       | 160.000 |            |
 (1 row)

在 30% 快取 TPC-C 設定 (含 3200 個倉儲) 中，tpcc 資料庫的大小預計約為 300 GB。

在 100% 快取的 TPC-C 設定中 (有 576 個倉儲)，tpcc 資料庫的大小預計約為 55 GB。

執行 TPC-C 基準測試

現在可以執行 TPC-C 效能測試了。TPC-C 基準測試會使用載入步驟中填入的資料庫執行。基準測試會產生一系列模擬典型業務環境的交易，包括訂單輸入、付款處理和商品目錄管理。工作負載是以每分鐘交易次數 (TPM) 衡量，代表系統在一分鐘內可處理的完整業務交易數量。

執行步驟旨在模擬實際情況，對資料庫系統進行壓力測試，並提供標準的效能評估方式，方便您比較不同資料庫系統。供應商和使用者通常會使用 TPC-C 基準測試結果，評估不同資料庫系統和硬體設定的效能。

如要執行 TPC-C 基準測試，請按照下列步驟操作：

  1. 切換至基準主目錄：

    cd hammerdb/HammerDB-4.6

  2. 複製下列內容並貼到 run-tpcc.sh：

    #!/bin/bash -x

source ./setup.env

./hammerdbcli << EOF
dbset db pg
dbset bm tpc-c

# CONFIGURE PG HOST and PORT
# -------------------------
diset connection pg_host $PGHOST
diset connection pg_port $PGPORT

# CONFIGURE TPCC DB
# -------------------------
diset tpcc pg_superuser postgres
diset tpcc pg_superuserpass AlloyDB#123
diset tpcc pg_user postgres
diset tpcc pg_pass AlloyDB#123
diset tpcc pg_dbase tpcc

# BENCHMARKING PARAMETERS
# -------------------------
diset tpcc pg_driver timed
diset tpcc pg_rampup 10
diset tpcc pg_duration 60
diset tpcc pg_vacuum false
diset tpcc pg_partition false
diset tpcc pg_allwarehouse true
diset tpcc pg_timeprofile true
diset tpcc pg_connect_pool false
diset tpcc pg_dritasnap false
diset tpcc pg_count_ware $NUM_WAREHOUSE
diset tpcc pg_num_vu 1

loadscript
print dict
vuset logtotemp 1
vuset vu $NUM_USERS
vucreate
vurun
waittocomplete
quit
EOF

  3. 使用下列指令執行指令碼：

    chmod +x run-tpcc.sh
mkdir results
sudo nohup ./run-tpcc.sh > results/run-tpcc.out 2>&1

  4. 等待 run-tpcc.sh 指令碼完成。指令碼大約需要 1 小時 10 分鐘才能完成。指令碼執行完畢後，您可以分析結果。

分析基準測試結果

在 TPC-C 基準測試中，每分鐘新訂單數 (NOPM) 和每分鐘交易數 (TPM) 是用來評估資料庫系統效能的成效指標。

  • NOPM：測量系統在一分鐘內可處理的新訂單交易數量。新訂單交易是 TPC-C 基準中最重要的交易之一，涉及為客戶建立新訂單。

  • TPM：測量系統在一分鐘內可處理的已完成業務交易總數。交易包括新訂單交易，以及 TPC-C 基準中定義的其他交易類型，例如付款、交貨和訂單狀態。

    TPM 是 TPC-C 基準測試的主要成效指標，因為它能全面評估系統處理實際工作負載的能力。對於著重處理新訂單的系統 (例如電子商務或零售系統)，NOPM 是實用的指標。

查看在 16 個 vCPU 的機器上，快取 30% TPC-C 資料庫的結果

如要擷取這個情境的效能數據，請使用下列指令：

grep NOPM results/run-tpcc.out

預期的輸出內容如下：

Vuser 1:TEST RESULT : System achieved 252970 NOPM from 582385 PostgreSQL TPM

在 16 個 vCPU 機器 (具有 NUM_WAREHOUSE=3200 和 NUM_USERS=256) 上，使用 30% 快取 TPC-C 資料庫，您會觀察到 252,970 tpm-C (每分鐘新訂單)，累計 582,385 AlloyDB TPM。

查看在 16 個 vCPU 機器上，100% 快取 TPC-C 資料庫的結果

在 16 個 vCPU 機器 (具有 NUM_WAREHOUSE=576 和 NUM_USERS=256) 上，100% 快取的 TPC-C 資料庫中，您會觀察到 428,316 tpm-C (每分鐘新訂單)，累計 974,264 AlloyDB TPM。

如要擷取這個情境的效能數據，請使用下列指令：

grep NOPM results/tpcc-run.out

預期的輸出內容如下：

Vuser 1:TEST RESULT : System achieved 428316 NOPM from 974264 PostgreSQL TPM

16 個 vCPU 機器的效能結果摘要

下表彙整 16 個 vCPU 機器的基準測試效能結果：

TPC-C 情境 NUM_WAREHOUSE NUM_USERS NOPM 累計 TPM
30% cached 3200 256 252,970 582,385
100% 快取 576 256 428,316 974,264

觀察資料庫成效指標

如要進一步瞭解資料庫系統的行為，請使用 AlloyDB 監控工具，觀察 CPU 使用率、記憶體用量和每秒交易數等重要系統指標。詳情請參閱「監控執行個體效能」。

舉例來說，執行這項基準測試後，您可以在 Google Cloud 控制台的 AlloyDB「Overview」(總覽) 頁面中，觀察到 100% 快取 TPC-C 執行的平均 CPU 使用率接近 90%。

在 64 個 vCPU 的 AlloyDB 執行個體上執行 TPC-C 基準測試

如要在 64 個 vCPU AlloyDB 執行個體上執行 TPC-C 基準測試，請按照「執行 TPC-C 基準測試」中的相同設定步驟操作，但使用不同的機器類型。

設定 AlloyDB 和用戶端機器

  1. 建立 AlloyDB 叢集和執行個體，並將機型替換為 64 vCPU, 512GB。

  2. 佈建用戶端機器，並將 n2-standard-64 替換為機器類型。

  3. 設定基準測試驅動程式機器。

執行基準測試

  1. 如果您要連續執行多項基準測試，請清除基準測試。

  2. 設定用戶端機器，並替換下列值：

    • 將 PGHOST 設為新 64 個 vCPU AlloyDB 執行個體的私人 IP。
    • 針對 30% 快取 TPC-C 情境，請設定 NUM_WAREHOUSE=12800 和 NUM_USERS=1024。
    • 如果是 100% 快取 TPC-C 情境，請設定 NUM_WAREHOUSE=2304 和 NUM_USERS=1024。

  3. 設定並載入 TPC-C 資料庫。如要加快載入速度，請在 build-tpcc.sh 中將 pg_num_vu 的值變更為 64，如 diset tpcc pg_num_vu 64 所示。

  4. 執行 TPC-C 基準測試。

分析基準測試結果

下表摘要說明 64 個 vCPU 機器的基準測試效能結果：

基準測試模式 NUM_WAREHOUSE NUM_USERS NOPM 累計 TPM
30% cached 12800 1024 589,598 1,371,160
100% 快取 2304 1024 716,138 1,665,438

執行 pgbench TPC-B 基準測試

TPC-B (交易處理效能委員會基準 B) 是 pgbench (PostgreSQL 基準測試工具) 提供的基準模式之一。TPC-B 會模擬銀行情境，其中多位出納員會對客戶帳戶執行交易。工作負載包含下列交易類型：

  • 存款
  • 提款
  • 餘額查詢

基準測試會模擬這些交易的組合，並測量系統每秒可處理的交易數量，藉此評估資料庫系統的效能。

pgbench 的 TPC-B 模式會產生綜合資料庫，並模擬類似 TPC-B 工作負載的混合交易，但未經 TPC 組織正式認證。因此，雖然 pgbench 中的 TPC-B 模式可提供 TPC-B 效能的實用近似值，但請勿使用該模式來聲稱符合 TPC-B 標準。

評估成效的情境

本節說明如何在下列重要模式中評估 TPC-B 效能。這些模式中唯一不同的參數是 SCALE_FACTOR 參數的值。

部分快取資料庫情境

在這個情境中，您會使用 --scale= 50000 設定及初始化大型資料庫 (大小約 650 GB)。如果資料庫過大，無法放入記憶體，並導致大量磁碟 I/O，就能實際呈現許多實際工作環境工作負載。

大型資料庫會產生大量磁碟 I/O，因此資料庫設計和查詢最佳化更顯重要。大型資料庫也可能暴露與磁碟 I/O 相關的效能問題，例如磁碟存取速度緩慢或查詢效率不彰，這些問題在小型或完全常駐記憶體的資料庫中可能不明顯。

完全快取的資料庫情境

在這個情境中，您會使用 --scale=4000 設定及初始化大小約 60 GB 的資料庫，使其位於緩衝區集區中。對記憶體常駐資料庫進行基準測試非常重要，因為這可讓您在受控環境中評估資料庫系統的最大效能。

記憶體常駐資料庫會將所有資料儲存在 PostgreSQL 緩衝集區中，消除從磁碟存取資料時可能發生的 I/O 瓶頸。這個模式有助於找出與 I/O 無關的效能瓶頸，例如 CPU 使用率或鎖定問題，這些問題在基準測試依賴磁碟 I/O 的資料庫時可能不明顯。

設定資料庫伺服器和用戶端機器

如要設定基礎架構來執行 pgbench TPC-B 基準測試，請按照下列步驟操作：

  1. 建立 AlloyDB 叢集和執行個體，並將機型替換為 16 vCPU, 128GB。

  2. 佈建用戶端機器，並將機型替換為 E2-standard-16 (minimum)。

  3. 設定基準測試驅動程式機器。

  4. 執行基準測試清理作業。

執行 pgbench TPC-B 基準測試

  1. 使用下列 Google Cloud CLI 指令連線至用戶端機器：

    gcloud compute ssh --zone "PRIMARY_ZONE" "CLIENT_MACHINE_NAME" --project "GOOGLE_PROJECT"

  2. 建立 pgbench-setup.env 檔案：

    $ cat << EOF > pgbench-setup.env

# Private IP of the AlloyDB primary instance
export PGHOST=<private_ip>

# Set PGUSER to postgres as a default user.
export PGUSER=postgres

# Password set for PGUSER
export PGPASSWORD=<your pg password>

# In pgbench, the scale factor represents the size of the test database.
# and is defined as the number of 1 MB-sized data pages to be generated per client.
export SCALE_FACTOR=<scale_factor>

# Number of clients to drive the benchmark in throughput mode
export NUM_CLIENTS=<num_clients>

EOF

  3. 編輯產生的 setup.env 檔案，並將下列參數值替換為適合您環境設定的值。

    • PRIVATE_IP：AlloyDB 執行個體的私人 IP。

    請參閱下表，選擇 <scale_factor> 和 <num_clients> 值。這些值必須隨著機器類型和資料庫大小 (完全快取或部分快取) 調整。本指南中的範例使用與 n2-highmem-16 機器類型對應的 SCALE_FACTOR 和 NUM_CLIENT 值。

    完全快取 部分快取
    機型 SCALE_FACTOR NUM_CLIENTS SCALE_FACTOR NUM_CLIENTS
    n2-highmem-2 500 48 6250 32
    n2-highmem-4 1000 96 12500 64
    n2-highmem-8 2000 192 25000 128
    n2-highmem-16 4000 384 50000 256
    n2-highmem-32 8000 768 100000 512
    n2-highmem-64 16000 1536 200000 1024

  4. 建立 pgbench 資料庫。

    source ./pgbench-setup.env
psql -h $PGHOST -p 5432
postgres=> create database pgbench;
CREATE DATABASE

  5. 執行下列指令，初始化並載入 pgbench 資料庫。這個步驟可確保系統建立基準測試資料集，並填入實際資料，讓您準確模擬 pgbench 資料庫的 TPC-B 工作負載。

    source ./pgbench-setup.env
sudo nohup pgbench -i --host=$PGHOST --scale=$SCALE_FACTOR pgbench > /tmp/pgbench-tpcb-partially-cached-db-init.out 2>&1

    預期載入時間：

    • 部分快取的資料庫約需 6 小時才能載入。
    • 完整快取的資料庫約需 45 分鐘才能載入。

  6. 選用：確認 /tmp/pgbench-tpcb-partially-cached-db-init.out 檔案的內容與下列內容類似，藉此檢查載入準確度：

    generating data (client-side)...
100000 of 400000000 tuples (0%) done (elapsed 0.02 s, remaining 99.82 s)
.. .. ..
.. .. ..
399800000 of 400000000 tuples (99%) done (elapsed 534.60 s, remaining 0.27 s)
399900000 of 400000000 tuples (99%) done (elapsed 534.72 s, remaining 0.13 s)
400000000 of 400000000 tuples (100%) done (elapsed 534.85 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 1481.92 s (drop tables 0.01 s, create tables 0.04 s, client-side generate 540.93 s, vacuum 615.11 s, primary keys 325.84 s).

  7. 選用：如要進一步驗證負載的準確度，請執行下列 PostgreSQL 指令，測量所有 pgbench 資料表的大小：

    1. 連線至 pgbench 資料庫：

      source ./pgbench-setup.env
psql -h $PGHOST -p 5432 -U postgres -d pgbench

    2. 執行下列 SQL 指令：

      pgbench=> SELECT nspname AS schema_name, relname AS table_name, pg_size_pretty(pg_total_relation_size(C.oid)) AS size FROM pg_class C
LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
WHERE nspname NOT LIKE 'pg_%' AND nspname != 'information_schema'
ORDER BY pg_total_relation_size(C.oid) DESC;

    3. 比較前一個指令的輸出內容，與部分快取資料庫執行作業 (SCALE_FACTOR=50000) 的輸出內容。

       schema_name |                table_name                 |  size
 -------------+-------------------------------------------+---------
 public      | pgbench_accounts                          | 731 GB
 public      | pgbench_accounts_pkey                     | 105 GB
 public      | pgbench_tellers                           | 32 MB
 public      | pgbench_tellers_pkey                      | 11 MB
 public      | pgbench_branches                          | 2952 kB
 public      | pgbench_branches_pkey                     | 1112 kB
 .. .. ..
 public      | pgbench_history                           | 0 bytes
 .. .. ..
 (29 rows)

  8. 執行下列指令，模擬財務會計系統工作負載，方法是執行一系列涉及存款、轉帳和付款的交易，以便評估資料庫在繁重工作負載下的效能。

    source ./pgbench-setup.env
mkdir -p ~/results/alloydb/pgbench
sudo nohup pgbench --host=$PGHOST --builtin=tpcb-like --time=3900 --jobs=$NUM_CLIENTS --client=$NUM_CLIENTS --scale=$SCALE_FACTOR --protocol=prepared --progress=1 pgbench > ~/results/alloydb/pgbench/pgbench.run.out 2>&1

分析基準測試結果

在 ~/results/alloydb/pgbench/pgbench.run.out 檔案中查看前一個指令的輸出內容。TPS 數量應接近完全快取資料庫和部分快取資料庫情境中顯示的數量。

資料庫完全快取時的結果

執行 pgbench TPC-B 基準測試中最後一個指令的輸出內容應與下列內容類似，其中 --scale=4000：

transaction type: <builtin: TPC-B (sort of)>
scaling factor: 4000
query mode: prepared
number of clients: 384
number of threads: 384
duration: 3900 s
number of transactions actually processed: 84819501
latency average = 17.654 ms
latency stddev = 6.963 ms
tps = 21747.831164 (including connections establishing)
tps = 21750.579718 (excluding connections establishing)

如要進一步瞭解資料庫系統的行為，您可以使用 Google Cloud 控制台監控系統指標，例如 CPU 用量、記憶體用量和每秒交易數。詳情請參閱「監控執行個體」。

使用部分快取資料庫的結果

「執行 pgbench TPC-B 基準測試」中最後一個指令的輸出內容應與下方類似，其中 --scale=50000：

pgbench: warning: scale option ignored, using count from pgbench_branches table (50000)
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>

scaling factor: 50000
query mode: prepared
number of clients: 384
number of threads: 384
duration: 3900 s
number of transactions actually processed: 68073405
latency average = 21.992 ms
latency stddev = 29.272 ms
tps = 17453.913041 (including connections establishing)
tps = 17460.373303 (excluding connections establishing)

pgbench TPC-B 基準測試的效能結果摘要

下表摘要列出 pgbench TPC-B 基準測試的效能結果：

TPC-B 情境 SCALE_FACTOR TPS CPU 使用率 (%)
部分快取 50000 17,460 96%
完全快取 4000 21,750 94%

執行僅插入索引基準測試

「僅插入索引」基準測試是高度並行、寫入密集的情境，本節會自訂這項測試，展示 AlloyDB 對大多數 OLTP 應用程式的效能優勢。如要執行這項基準測試，請在 pgbench_history 資料表上建立多個索引，然後從多個用戶端連線，在 pgbench_history 資料表上重複執行 INSERT 作業。

「僅限索引插入」基準會評估將資料插入資料庫資料表的效能，特別著重於索引對寫入作業的影響。這項基準測試可讓您瞭解，在有和沒有索引的情況下，將新資料列新增至資料表的速度有多快，並突顯在插入期間維護索引可能導致速度變慢。

AlloyDB 可提升 PostgreSQL 寫入效能，進而改善 OLTP 工作負載。為提升寫入密集型 OLTP 情境的效能，AlloyDB 提供架構創新功能，包括可協助讀取的分層快取層，以及可寫入的分散式且高度可擴充的儲存引擎技術。

設定 AlloyDB 和用戶端機器

如要設定基礎架構來執行「僅限索引插入」基準測試，請按照下列步驟操作：

  1. 建立 AlloyDB 叢集和執行個體，並將機型替換為 16 vCPU and 128 GB RAM。

  2. 佈建用戶端機器，並將機型替換為 E2-standard-16 (minimum)。

  3. 設定基準測試驅動程式機器。

  4. 執行基準測試清理作業。

執行 Index Insert Only 基準測試

  1. 使用下列範例指令連線至用戶端機器：

    gcloud compute ssh --zone "<primary zone>" "<client machine name>" --project "<google-project>"

  2. 執行下列指令來設定環境：

    export PGHOST=<private_ip>

  3. 請按照下列範例建立 pgbench 資料庫。如果資料庫已存在，請捨棄資料庫並重新建立。

    psql -h $PGHOST -p 5432 -U postgres -c "DROP DATABASE IF EXISTS pgbench"
psql -h $PGHOST -p 5432 -U postgres -c "CREATE DATABASE pgbench"

  4. 初始化並載入 pgbench 資料庫，確保基準測試資料集已建立，並填入實際資料。編輯醒目顯示的參數，然後執行下列指令：

    sudo nohup pgbench -i  --host=$PGHOST --user=postgres --scale=25000 pgbench > /tmp/pgbench-index-insert-only-init.out 2>&1
...

postgres=> create database pgbench;
CREATE DATABASE pgbench

  5. 確認前一個指令的輸出內容與下列內容相似：

    dropping old tables...
creating tables...
generating data (client-side)...
100000 of 2500000000 tuples (0%) done (elapsed 0.03 s, remaining 636.43 s)
200000 of 2500000000 tuples (0%) done (elapsed 0.05 s, remaining 649.12 s)
.. .. ..
.. .. ..
2499900000 of 2500000000 tuples (99%) done (elapsed 3425.42 s, remaining 0.14 s)
2500000000 of 2500000000 tuples (100%) done (elapsed 3425.57 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 12851.19 s (drop tables 998.62 s, create tables 0.02 s, client-side generate 3460.33 s, vacuum 5299.93 s, primary keys 3092.29 s).

  6. 使用下列指令建立 index-init.sql 指令碼：

    cat > index-init.sql << EOF
CREATE INDEX tid ON pgbench_history(tid);
CREATE INDEX bid ON pgbench_history(bid);
CREATE INDEX aid ON pgbench_history(aid);
CREATE INDEX delta ON pgbench_history(delta);
CREATE INDEX mtime ON pgbench_history(mtime);
EOF

  7. 執行 index-init.sql 指令碼：

    psql -h $PGHOST -U postgres -d pgbench -f ./index-init.sql
Password for user postgres:
CREATE INDEX

  8. 選用：驗證資料庫結構定義和初始載入：

    psql -h $PGHOST -U postgres -d pgbench

pgbench=> \dt
           List of relations
Schema |       Name       | Type  |  Owner
--------+------------------+-------+----------
 public | pgbench_accounts | table | postgres
 public | pgbench_branches | table | postgres
 public | pgbench_history  | table | postgres
 public | pgbench_tellers  | table | postgres
(4 rows)

pgbench=> \di
                       List of relations
 Schema |         Name          | Type  |  Owner   |      Table
--------+-----------------------+-------+----------+------------------
 public | aid                   | index | postgres | pgbench_history
 public | bid                   | index | postgres | pgbench_history
 public | delta                 | index | postgres | pgbench_history
 public | mtime                 | index | postgres | pgbench_history
 public | pgbench_accounts_pkey | index | postgres | pgbench_accounts
 public | pgbench_branches_pkey | index | postgres | pgbench_branches
 public | pgbench_tellers_pkey  | index | postgres | pgbench_tellers
 public | tid                   | index | postgres | pgbench_history
(8 rows)

    載入後，資料庫大小預計約為 365 GB：

    pgbench=> \l+ pgbench
                         List of databases
Name     |      Owner       | Encoding | Collate |  Ctype  |           Access privileges           |  Size  | Tablespace |                Description
 --------------+------------------+----------+---------+---------+---------------------------------------+--------+------------+--------------------------------------------
...
 pgbench      | postgres         | UTF8     | C.UTF-8 | C.UTF-8 |                                       | 365 GB | pg_default |
...

  9. 使用下列指令建立 index-inserts-only.sql 指令碼：

    cat > index-inserts-only.sql << EOF
\set aid random(1, 1000000000)
\set bid random(1, 1000000000)
\set tid random(1, 1000000000)
\set delta random(-500000000, 500000000)
BEGIN;
INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
END;
EOF

  10. 使用下列指令執行 pgbench 基準測試：

    sudo nohup pgbench --host=$PGHOST --user=postgres --time=3900 --client=256 --jobs=256 --scale=25000 --progress=1 --file=./index-inserts-only.sql pgbench > /tmp/pgbench-index-insert-only-run.out 2>&1

分析基準測試結果

在 /tmp/pgbench-index-insert-only-run.out 檔案中，驗證前一個指令的輸出內容。在這項基準測試中，您應該會看到每秒約 52, 000 筆交易，CPU 使用率約為 88%，如以下輸出範例所示。

scaling factor: 25000
query mode: simple
number of clients: 256
number of threads: 256
duration: 3900 s
number of transactions actually processed: 201785196
latency average = 4.947 ms
latency stddev = 3.488 ms
tps = 51738.604613 (including connections establishing)
tps = 51742.459757 (excluding connections establishing)

在 64 個 vCPU 的執行個體上執行 Select Only 基準測試

pgbench 支援內建的僅限選取情境，可從多個用戶端連線，對指定資料庫重複執行 SELECT 查詢。這項基準測試用於評估資料庫的讀取效能，不會產生 INSERT、UPDATE 或 DELETE 等資料修改作業的負擔。這些 SELECT 查詢是點查詢，是最快且最有效率的選取查詢類型，因為這類查詢只會直接從索引結構存取單一資料列。

執行「僅限精選」基準測試，可協助您達成下列目標：

  • 達到最大處理量：在資料庫系統中，索引點查詢是最有效率的查詢形式，因此您可以評估 AlloyDB 可達到的最大處理量。

  • 擴充性：只選取基準測試，協助您測試 AlloyDB 的擴充性，從 2 個 vCPU 到 AlloyDB 提供的最大 vCPU 設定。

設定 AlloyDB 和用戶端機器

在 64 個 vCPU 的機型上設定 AlloyDB 和用戶端機器。

執行 Select Only 基準測試

  1. 使用下列範例指令連線至用戶端機器：

    gcloud compute ssh --zone "PRIMARY_ZONE" "CLIENT_MACHINE_NAME" --project "GOOGLE_PROJECT"

  2. 使用下列指令設定環境：

    export PGHOST=<private_ip>

  3. 使用下列範例建立 pgbench 資料庫：

    psql -h $PGHOST -p 5432 -U postgres

postgres=> create database pgbench;
CREATE DATABASE

  4. 初始化 pgbench 資料庫。下列指令會使用約 220 GB 的實際資料，初始化 pgbench 資料庫。您可以使用 --scale=15000 執行完全快取的 Select Only 基準測試。

    執行下列指令：

    sudo nohup pgbench -i --host=$PGHOST --user=postgres --scale=15000 pgbench > /tmp/pgbench-select-only-init.out 2>&1

  5. 確認前一個指令的輸出內容與下列內容相似：

    cat /tmp/pgbench-select-only-init.out
nohup: ignoring input
dropping old tables...
creating tables...
generating data (client-side)...
100000 of 1500000000 tuples (0%) done (elapsed 0.01 s, remaining 161.60 s)
200000 of 1500000000 tuples (0%) done (elapsed 0.03 s, remaining 224.35 s)
300000 of 1500000000 tuples (0%) done (elapsed 0.09 s, remaining 448.97 s)
.. .. ..
.. .. ..
1499900000 of 1500000000 tuples (99%) done (elapsed 1251.03 s, remaining 0.08 s)
1500000000 of 1500000000 tuples (100%) done (elapsed 1251.10 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 2204.62 s (drop tables 2.29 s, create tables 0.01 s, client-side generate 1271.82 s, vacuum 427.83 s, primary keys 502.66 s).

  6. 執行 pgbench。最後一個基準測試步驟需要超過一小時才能完成。

    sudo nohup pgbench --host=$PGHOST --user=postgres  --builtin=select-only --time=3900 --jobs=256 --client=256 --scale=15000 --protocol=simple --progress=1 pgbench > /tmp/pgbench-select-only-run.out  2>&1

  7. 基準測試完成後，請查看 /tmp/pgbench-select-only-run.out 檔案，瞭解最終結果。

分析基準測試結果

在這項基準測試中，您應該會觀察到每秒約 46.7 萬筆交易，以及約 95% 的 CPU 使用率，如下方輸出範例所示。

cat /tmp/pgbench-select-only-run.out
transaction type: <builtin: select only>
scaling factor: 15000
query mode: simple
number of clients: 256
number of threads: 256
duration: 3900 s
number of transactions actually processed: 1823506174
latency average = 0.547 ms
latency stddev = 0.267 ms
tps = 467563.144333 (including connections establishing)
tps = 467583.398400 (excluding connections establishing)

AlloyDB 基準測試結果摘要

下表根據本文執行的測試，彙整 AlloyDB 基準測試結果。

HammerDB TPC-C 成效摘要

AlloyDB 機型 TPC-C 工作負載情境 NUM_WAREHOUSE NUM_USERS 每分鐘新訂單數 (NOPM) 累計 TPM 轉換為 TPS
16 個 vCPU 30% cached 3200 256 252,970 582,385 9,706
16 個 vCPU 100% 快取 576 256 428,316 974,264 16,238
64 個 vCPU 30% cached 12800 1024 589,598 1,371,160 22,853
64 個 vCPU 100% 快取 2304 1024 716,138 1,665,438 27,757

pgbench 成效摘要

AlloyDB 機型 pgbench 工作負載情境 縮放比例係數 TPS CPU %
16 個 vCPU 類似 TPC-B，完全快取 4000 20,359 96%
16 個 vCPU 類似 TPC-B，部分快取 50000 14,060 94%
16 個 vCPU 僅限索引插入 25000 51,742 88%
64 個 vCPU 最大處理量 (僅限選取) 15000 467,583 95%

在 PostgreSQL 適用的 Cloud SQL 執行 OLTP 基準測試

您可以在 PostgreSQL 適用的 Cloud SQL 中，使用 16 個 vCPU 的機型測試 PostgreSQL 的同等 OLTP 效能，以便進行比較分析。本節說明如何設定 PostgreSQL 適用的 Cloud SQL (或部署在所選基礎架構上的任何 PostgreSQL 伺服器)，其與本指南中用於基準測試 OLTP 效能的 AlloyDB 設定相當。在這個情境中，包括選擇 16vCPU SKU、啟用高可用性 (HA)，以及預先設定儲存空間。

事前準備

  1. 登入 Google Cloud 帳戶。如果您未曾使用過 Google Cloud，歡迎 建立帳戶，親自體驗實際使用我們產品的成效。新客戶還能獲得價值 $300 美元的免費抵免額，用於執行、測試及部署工作負載。

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

  4. Enable the AlloyDB, Compute Engine, and Resource Manager APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  5. Install the Google Cloud CLI.

  6. If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  7. To initialize the gcloud CLI, run the following command: 

    gcloud init

  8. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  9. Verify that billing is enabled for your Google Cloud project.

  10. Enable the AlloyDB, Compute Engine, and Resource Manager APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  11. Install the Google Cloud CLI.

  12. If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  13. To initialize the gcloud CLI, run the following command: 

    gcloud init
  14. 確認您的使用者帳戶具備 Cloud SQL 管理員和 Compute 檢視者角色。

    前往「IAM」頁面

    進一步瞭解角色和權限。

佈建 PostgreSQL 適用的 Cloud SQL 執行個體

  1. 建立 PostgreSQL 執行個體，並替換下列值：

    • 資料庫版本：PostgreSQL 14
    • 選擇初始設定：正式版群組
    • 選擇區域和可用區可用性：選取「us-central1」做為區域。
    • 可用區可用性：多可用區 (可用性高)
      • 主要可用區：us-central1-c
      • 次要可用區：us-central-1-f
    • 機型：高記憶體 16 個 vCPU，104 GB 機器。在 PostgreSQL 適用的 Cloud SQL 中，這部機器最接近您在本文件 AlloyDB 基準測試一節建立的相符 AlloyDB 執行個體。
    • 儲存空間容量：自訂，1500 GB
      • 啟用自動增加儲存空間
    • 加密： Google-owned and Google-managed encryption key
    • 連線：私人 IP
      • 網路：default
      • 公開 IP：已啟用

  2. 點選「建立執行個體」。

  3. 建立 PostgreSQL 執行個體後，請記下私人 IP 位址。您可以使用 IP 做為 PGHOST，與基準建立連線。

佈建用戶端機器

  1. 佈建 PostgreSQL 適用的 Cloud SQL 執行個體。如要執行您選擇的 OLTP 基準測試，您需要一部 CPU 效能強大的用戶端機器，且該機器必須與 Cloud SQL 中 PostgreSQL 適用的 Cloud SQL 主要執行個體位於相同可用區。

  2. 選用：您也可以不執行上一個步驟，改用為 AlloyDB 基準測試設定的相同用戶端機器，但必須符合下列條件：

    • 用戶端機器與新的 PostgreSQL (PostgreSQL 適用的 Cloud SQL) 主要執行個體位於相同可用區。
    • 用戶端機器符合 CPU、RAM 和磁碟大小的最低需求。

    在本基準指南中，您在用戶端機器與主要執行個體位於相同可用區，且用戶端機器足以讓伺服器達到完整容量時，重複使用用戶端機器。

  3. 如果您建立了新的用戶端機器，請設定基準測試驅動程式機器。否則，請按照本指南中的操作說明，執行您感興趣的基準測試。

後續步驟