評估 AlloyDB for PostgreSQL 的 OLTP 效能

本文說明如何設定 AlloyDB for PostgreSQL 和用戶端電腦，使用 OLTP 基準規格 TPC-C 評估 AlloyDB 的效能。本文也說明如何執行自訂的讀取和寫入密集型 OLTP 情境，例如「僅插入索引」和「僅選取」。

本文中的操作說明是以 AlloyDB 和用戶端機器的特定設定為基礎。請使用基準化說明中每個步驟提供的數值。

AlloyDB 工作負載功能

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

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

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

AlloyDB 會預先設定各機型的最佳化設定。AlloyDB 內建高 OLTP 效能，因此您不需要在資料庫層級調整旗標。

注意： 結果的準確度可能因多項因素而異，包括 AlloyDB 執行個體類型、執行基準測試的用戶端機器類型、地區、可用區，以及測試時的網路頻寬。

支援的基準類型

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

OLTP 基準驅動程式	用途
HammerDB	HammerDB 會以每分鐘交易數 (TPM) 衡量系統效能，並產生包含詳細統計資料和效能指標的報表。 HammerDB 支援自訂基準參數，可讓您調整資料庫大小、倉庫數量和其他工作負載特徵，模擬不同情境。 HammerDB 包含 TPC-C 基準實作，可評估 OLTP 系統的效能。您可以使用 HammerDB TPC-C 實作項目，模擬類似 TPC-C 基準的工作負載，包括模擬批發供應商環境行為的交易組合。
pgbench	pgbench 是 PostgreSQL 隨附的基準化工具。pgbench 可模擬交易工作負載，例如插入、更新及選取資料，並以每秒交易數 (TPS) 衡量資料庫系統的效能。 使用 pgbench 時，您可以自訂資料庫大小、用戶端數量和交易組合，模擬實際工作環境工作負載，並深入瞭解系統在不同情境下的行為。 pgbench 包含 TPC-B 實作項目。pgbench TPC-B 實作方式與 TPC-B 基準類似。

事前準備

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

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

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

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

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

1. 啟用建立及連線至 PostgreSQL 適用的 AlloyDB 時所需的 Cloud API。

   啟用 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 專案的 VPC 網路，設定 AlloyDB 的網路連線，則必須使用 Compute Engine API 和 Cloud Resource Manager API。

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

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

建立 AlloyDB 叢集和執行個體

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

   前往「Clusters」(叢集)

2. 點選「建立叢集」。

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

4. 在「Zonal availability」(區域可用性) 中，為叢集類型選取「Multiple zones (Highly Available)」(多區域 (可用性高))。

5. 選取預設網路。

6. 在「資料庫版本」欄位中，選取「PostgreSQL 16」。

7. 記下主要區域的位置和私人 IP 位址。 請勿建立讀取集區。

   注意： 這項基準化作業是在沒有讀取集區的情況下進行。 執行個體必須是多可用區高可用性執行個體。

8. 點選「建立叢集」。

佈建用戶端電腦

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

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

重要事項： 如要執行本文所述的 OLTP 基準測試，您必須在與 AlloyDB 主要執行個體相同的區域、可用區和 VPC 中，佈建 Debian Linux 用戶端。基準化工具會透過私人 IP 存取 AlloyDB 執行個體。

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

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

   前往 VM 執行個體

2. 選取含有要連線 AlloyDB 執行個體的專案。
3. 點選「建立執行個體」。
4. 按一下「機器設定」區段。
5. 輸入執行個體的「名稱」。
6. 設定要建立執行個體的區域。區域必須與 AlloyDB 主要執行個體的區域相同。
7. 選取「e2-standard-32」機器類型。
8. 保留「OS 和儲存空間」專區的預設值。
9. 按一下「網路」部分，然後將「網路介面」設為已為 AlloyDB 私人服務存取權設定的虛擬私有雲網路。
   如果「網路介面」未設為已設定私人服務存取權的虛擬私有雲網路，請展開該介面，然後將「網路」設為虛擬私有雲網路。
10. 保留「可觀測性」部分中的預設值。
11. 按一下「安全性」專區。
12. 在「Identity and API access」(身分及 API 存取權) 中，將「Access scopes」(存取權範圍) 設為「Allow full access to all Cloud APIs」(允許所有 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. 使用下列指令安裝包含 psql 應用程式的 PostgreSQL 用戶端，然後確認您能夠連線。

      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 執行個體使用的 RAM 約為 128 GB，包括緩衝區快取。

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

設定用戶端電腦

1. 設定基準驅動程式電腦。

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

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

   cd hammerdb/HammerDB-4.6

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

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

   注意： 如果您使用受管理連線集區，請將通訊埠號碼從 5432 變更為 6432。套用至本頁面的所有範例。

   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

   注意： 使用者 (或用戶端) 人數會設為 256。這個使用者人數經過調整，可為部分和完整快取設定提供最佳輸送量，並維持可接受的延遲時間。

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

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

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

將 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 基準測試結果，評估不同資料庫系統和硬體設定的效能。

注意： 下列指令碼會先暖機約 10 分鐘，然後執行 TPC-C 基準測試約 1 小時。

如要執行 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) 是用來評估資料庫系統效能的效能指標。

• 每分鐘新訂單數：衡量系統在一分鐘內可處理的新訂單交易數量。新訂單交易是 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 的機器上，如果 TPC-C 資料庫有 30% 的資料已快取 (使用 NUM_WAREHOUSE=3200 和 NUM_USERS=256)，您會發現累計 582,385 個 AlloyDB TPM 中，有 252,970 個 tpm-C (每分鐘新訂單數)。

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

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

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

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% 已快取	3200	256	252,970	582,385
100% 快取	576	256	428,316	974,264

觀察資料庫效能指標

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

舉例來說，執行這項基準測試後，您可以在 Google Cloud 控制台的 AlloyDB「總覽」頁面中觀察到，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% 已快取	12800	1024	589,598	1,371,160
100% 快取	2304	1024	716,138	1,665,438

執行 pgbench TPC-B 基準測試

TPC-B (交易處理效能委員會基準 B) 是 PostgreSQL 基準化工具 pgbench 提供的基準化模式之一。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. 執行基準清理。

執行「僅插入索引」基準測試

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

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

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

   export PGHOST=<private_ip>
   

   重要事項： 請在同一個用戶端終端機中，執行這個程序中的所有其餘指令。接著，您只需要匯出 PGHOST 環境變數一次，並將其指派給 AlloyDB 執行個體的私人 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 的執行個體上執行「僅選取」基準測試

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

執行「僅選取」基準測試有助於達成下列目標：

• 達到最大總處理量：由於索引上的點查閱是資料庫系統中最有效率的查詢形式，因此您可以測量 AlloyDB 可達到的最大總處理量。

• 延展性：只選取基準測試，有助於測試 AlloyDB 的延展性，從 2 個 vCPU 到 AlloyDB 提供的最大 vCPU 設定。

設定 AlloyDB 和用戶端機器

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

執行「僅選取」基準測試

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

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

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

   export PGHOST=<private_ip>
   

   重要事項： 請在同一個用戶端終端機中，執行這個程序中的所有其餘指令。接著，您只需要匯出 PGHOST 環境變數一次，並將其指派給 AlloyDB 執行個體的私人 IP 即可。如果將多個終端機連線至用戶端電腦，請在所有終端機上匯出下列環境變數。

3. 請按照下列範例建立 pgbench 資料庫：

   psql -h $PGHOST -p 5432 -U postgres
   
   postgres=> create database pgbench;
   CREATE DATABASE
   

4. 初始化 pgbench 資料庫。下列指令會初始化 pgbench 資料庫，其中包含約 220 GB 的實際資料。您可以使用 --scale=15000，取得完全快取「僅選取」基準。

   執行下列指令：

   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% 已快取	3200	256	252,970	582,385	9,706
16 個 vCPU	100% 快取	576	256	428,316	974,264	16,238
64 個 vCPU	30% 已快取	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 Like，完全快取	4000	20,359	96%
16 個 vCPU	TPC-B Like, Partially Cached	50000	14,060	94%
16 個 vCPU	僅插入索引	25000	51,742	88%
64 個 vCPU	最大總處理量 (僅限選取)	15000	467,583	95%

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

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

事前準備

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

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

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Install the Google Cloud CLI.

如果您使用外部識別資訊提供者 (IdP)，請先 使用聯合身分登入 gcloud CLI。

如要初始化 gcloud CLI，請執行下列指令：

gcloud init

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

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Install the Google Cloud CLI.

如果您使用外部識別資訊提供者 (IdP)，請先 使用聯合身分登入 gcloud CLI。

如要初始化 gcloud CLI，請執行下列指令：

gcloud init

1. 請確認使用者帳戶具備 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. 如果您建立了新的用戶端電腦，請設定基準測試驅動程式電腦。否則，請按照本指南中的操作說明，執行您感興趣的基準測試。

後續步驟

• 監控 AlloyDB 執行個體效能。