ApsaraDB for MongoDB支援審計日誌功能。本文通過基準測試，量化分析開啟審計日誌對執行個體效能的影響，協助您評估開啟審計日誌的效能開銷。
測試結論
根據測試結果，開啟審計日誌對ApsaraDB for MongoDB執行個體的效能影響如下：
-
純寫情境（純插入或純更新）：CPU 使用率上漲約 3 個百分點（15%~20%），回應時間和輸送量無明顯變化。
-
讀寫混合情境：CPU 使用率無明顯變化，但讀寫效能下降約 15%~20%。具體表現為寫操作平均回應時間增加 500~700 μs，讀操作平均回應時間增加 150~300 μs，輸送量下降 15%~20%。
測試環境
|
配置項 |
壓測ECS執行個體 |
MongoDB執行個體 |
|
地區及可用性區域 |
華東1（杭州）可用性區域J |
華東1（杭州）可用性區域J |
|
網路類型 |
Virtual Private Cloud |
Virtual Private Cloud |
|
執行個體規格類型系列 |
計算型執行個體 c8i |
獨享型 |
|
執行個體規格 |
ecs.c8i.4xlarge（16核 32 GB） |
mdb.shard.8x.16xlarge.d（64核512GB） |
|
儲存類型 |
ESSD PL0雲端硬碟（系統硬碟），無資料盤 |
ESSD PL1 雲端硬碟 |
|
頻寬 |
100Mbps |
350Mbps |
|
儲存空間 |
40 GiB（系統硬碟） |
470 GB |
|
拓撲結構 |
- |
標準複本集執行個體（三節點，一個主節點、一個從節點和一個隱藏節點） |
|
鏡像版本 |
CentOS 7.8 64位 |
- |
|
執行個體核心版本 |
- |
MongoDB 6.0（核心小版本 7.0.23） |
|
讀寫關注層級（Read/Write Concern） |
- |
Default read/write concern |
壓測ECS執行個體和ApsaraDB for MongoDB執行個體在同一地區及可用性區域，RTT（Round-Trip Time，往返時延）約為0.104 ms。
測試載入器
本文使用開源基準測試載入器 YCSB（Yahoo! Cloud Serving Benchmark）0.17.0 版本進行測試。
YCSB 是一款 Java 編寫的支援多種資料庫的效能基準測試載入器。安裝和使用方法，請參見YCSB。
測試方案
-
將 ECS 執行個體的主私網IP添加到ApsaraDB for MongoDB 執行個體的白名單中。添加方法，請參見修改白名單。
說明您可以登入ECS 控制台，在執行個體詳情 頁面的網絡資訊地區查看 ECS 執行個體的主私網IP。
-
遠端連線 ECS 執行個體。串連方法，請參見串連ECS執行個體。
-
使用YCSB工具載入測試資料。
./bin/ycsb load mongodb -s -p workload=site.ycsb.workloads.CoreWorkload -p recordcount=10000000 -p mongodb.url="mongodb://root:xxx@dds-bp1be0f4f3bbdxxxx.mongodb.rds.aliyuncs.com:3717,dds-bp1be0f4f3bbdxxxx.mongodb.rds.aliyuncs.com:3717/admin?replicaSet=mgset-xxxx" -threads 300請根據實際情況修改以下參數：
-
recordcount=10000000：載入至 MongoDB 執行個體的資料總量。本次測試載入 1000 萬條資料。 -
mongodb.url="mongodb://root:xxx@dds-bp1be0f4f3bbdxxxx.mongodb.rds.aliyuncs.com:3717,dds-bp1be0f4f3bbdxxxx.mongodb.rds.aliyuncs.com:3717/admin?replicaSet=mgset-xxxx"：MongoDB 執行個體的串連地址。本文使用 root 帳號串連 admin 資料庫。說明您可以登入ApsaraDB for MongoDB控制台，在資料庫連接頁面的私網串連地區查看串連地址。
-
threads=300：用戶端的並發線程數。
-
-
執行以下命令進行效能基準測試。以下樣本為純更新情境（update 100%）的測試命令：
./bin/ycsb run mongodb -s -p workload=site.ycsb.workloads.CoreWorkload -p recordcount=10000000 -p operationcount=500000000 -p insertproportion=0 -p readproportion=0 -p updateproportion=1 -p requestdistribution=zipfian -p mongodb.url="mongodb://root:xxx@dds-bp1be0f4f3bbdxxxx.mongodb.rds.aliyuncs.com:3717,dds-bp1be0f4f3bbdxxxx.mongodb.rds.aliyuncs.com:3717/admin?replicaSet=mgset-xxxx" -threads 300 -target 100000您需要修改如下參數值：
-
recordcount=10000000：已載入到 MongoDB 執行個體的資料總量。需與步驟三中的值一致。 -
operationcount=500000000：執行讀寫測試的總操作次數。本次測試為 5 億次。 -
insertproportion=0：插入操作比例。取值範圍為 0~1，其中 1 表示 100%。 -
readproportion=0：讀操作比例。取值範圍為 0~1。 -
updateproportion=1：更新操作比例。取值範圍為 0~1。 -
mongodb.url="mongodb://root:xxx@dds-bp1be0f4f3bbdxxxx.mongodb.rds.aliyuncs.com:3717,dds-bp1be0f4f3bbdxxxx.mongodb.rds.aliyuncs.com:3717/admin?replicaSet=mgset-xxxx"：MongoDB 執行個體的串連地址，與上一步擷取方式一致。 -
threads=300：用戶端的並發線程數。 -
target=100000：目標輸送量（ops/sec）。本次測試目標為每秒 10 萬次操作。
-
測試結果
環境說明
|
執行個體規格 |
MongoDB版本 |
recordcount |
threads |
|
64核512GB（獨享型） |
MongoDB 6.0（核心小版本 7.0.23） |
10000000 |
300 |
情境說明
-
insert:read:update=100:0:0：純插入情境。為 insert 操作開啟審計日誌。 -
insert:read:update=0:0:100：純更新情境。為 update 操作開啟審計日誌。 -
insert:read:update=50:50:0：50% 插入 + 50% 讀。為 insert、query 操作開啟審計日誌。 -
insert:read:update=0:50:50：50% 讀 + 50% 更新。為 query、update 操作開啟審計日誌。 -
insert:read:update=30:70:0：30% 插入 + 70% 讀。為 insert、query 操作開啟審計日誌。 -
insert:read:update=0:70:30：70% 讀 + 30% 更新。為 query、update 操作開啟審計日誌。
指標說明
-
CpuUsage：執行個體 CPU 使用率，反映業務負載。 -
MongoDB_RT：執行個體平均回應時間，包含 writes_avg_rt（寫平均回應時間）和 reads_avg_rt（讀平均回應時間）。 -
MongoDB_Opcounters：執行個體操作輸送量（ops/sec），統計 query、insert、update 等操作的每秒計數。
測試結果
下表展示各情境下開啟審計日誌前後的效能變化。
|
測試情境 |
CpuUsage |
MongoDB_RT |
MongoDB_Opcounters |
|
純插入（100:0:0） |
上漲 3 個百分點（+15%） |
無明顯變化 |
無明顯變化 |
|
純更新（0:0:100） |
上漲 3 個百分點（+20%） |
無明顯變化 |
無明顯變化 |
|
50% 插入 + 50% 讀（50:50:0） |
無明顯變化 |
writes_avg_rt +700 μs（+20%）；reads_avg_rt +300 μs（+250%） |
query 降低 5000（-20%）； insert 降低 5000（-20%） |
|
50% 讀 + 50% 更新（0:50:50） |
無明顯變化 |
writes_avg_rt +500 μs（+18%）；reads_avg_rt +150 μs（+200%） |
query 降低 5000（-15%）； update 降低 5000（-15%） |
|
30% 插入 + 70% 讀（30:70:0） |
無明顯變化 |
writes_avg_rt +600 μs（+20%）；reads_avg_rt +300 μs（+270%） |
query 降低 12,000（-20%）； insert 降低 5000（-20%） |
|
70% 讀 + 30% 更新（0:70:30） |
無明顯變化 |
writes_avg_rt +500 μs（+20%）；reads_avg_rt +150 μs（+150%） |
query 降低 10,000（-15%）；update 降低 5000（-15%） |
測試結果分析
-
純寫情境（純插入或純更新）：開啟審計日誌後，CPU 使用率上漲約 3 個百分點，但回應時間和輸送量均無明顯變化。審計日誌對純寫操作的效能影響較小。
-
讀寫混合情境：開啟審計日誌後，CPU 使用率無明顯變化，但讀寫效能整體下降 15%~20%。其中寫操作的平均回應時間增加 500~700 μs，讀操作的平均回應時間增加 150~300 μs。
reads_avg_rt 的百分比增長較高（150%~270%），是因為讀操作的基準回應時間較低（約 100 μs 層級），絕對增量僅為 150~300 μs。