Performance impact of enabling audit logs - ApsaraDB for MongoDB

Test conclusions

Enabling audit logs affects ApsaraDB for MongoDB instance performance as follows:

Write-only workloads (pure insert or update operations): CPU usage increases by approximately 3 percentage points (a relative increase of 15% to 20%), with no significant change in response time or throughput.
Mixed read/write workloads: CPU usage shows no significant change, but overall read/write performance decreases by approximately 15% to 20%. Specifically, the average write response time increases by 500–700 μs and the average read response time by 150–300 μs, while throughput drops by 15% to 20%.

Test environment

Parameter	Stress test ECS instance	MongoDB instance
Region and zone	China (Hangzhou) Zone J	China (Hangzhou) Zone J
Network type	VPC	VPC
Instance type family	Compute-optimized c8i	dedicated
Instance type	ecs.c8i.4xlarge (16 vCPU, 32 GB)	mdb.shard.8x.16xlarge.d (64 vCPU, 512 GB)
Storage type	ESSD PL0 cloud disk (system disk), no data disk	ESSD PL1 cloud disk
Bandwidth	100 Mbps	350 Mbps
Storage space	40 GiB (system disk)	470 GB
Topology	-	Standard replica set instance (3 nodes: 1 primary node, 1 secondary node, and 1 hidden node)
Image version	CentOS 7.8 64-bit	-
Instance kernel version	-	MongoDB 6.0 (minor kernel version 7.0.23)
Read/Write Concern	-	Default read/write concern

Note

The stress test ECS instance and the ApsaraDB for MongoDB instance are in the same region and zone. The Round-Trip Time (RTT) between them is approximately 0.104 ms.

Test tool

The benchmark tests use the open-source YCSB (Yahoo! Cloud Serving Benchmark) 0.17.0 tool.

Note

YCSB is a Java-based benchmark tool that supports multiple databases. For installation and usage instructions, see YCSB.

Test procedure

Add the primary private IP address of the ECS instance to the IP whitelist of the ApsaraDB for MongoDB instance. For instructions, see Modify IP whitelist.

Note
Log on to the ECS console and find the primary private IP address of the ECS instance in the Network Information section of the Instance Details page.
Connect to the ECS instance remotely. For instructions, see Connect to an ECS instance.
Use the YCSB tool to load test data.
```
./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
```
Modify the following parameters as needed:
- recordcount=10000000: The total number of records to load into the MongoDB instance. This test loads 10 million records.
- mongodb.url="mongodb://root:xxx@dds-bp1be0f4f3bbdxxxx.mongodb.rds.aliyuncs.com:3717,dds-bp1be0f4f3bbdxxxx.mongodb.rds.aliyuncs.com:3717/admin?replicaSet=mgset-xxxx": The connection string of the MongoDB instance. This test connects to the admin database by using the root account.
  
  Note
  Find the connection string in the Database Connections section on the Internal Connections page of the ApsaraDB for MongoDB console.
- threads=300: The number of concurrent threads for the client.
Run the following command to perform the benchmark test. The following example shows the command for a 100% update workload:
```
./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
```
Modify the following parameters:
- recordcount=10000000: The total number of records loaded into the MongoDB instance. This value must be the same as the value from Step 3.
- operationcount=500000000: The total number of read and write operations to perform. This test performs 500 million operations.
- insertproportion=0: The proportion of insert operations. The value ranges from 0 to 1, where 1 represents 100%.
- readproportion=0: The proportion of read operations. The value ranges from 0 to 1.
- updateproportion=1: The proportion of update operations. The value ranges from 0 to 1.
- mongodb.url="mongodb://root:xxx@dds-bp1be0f4f3bbdxxxx.mongodb.rds.aliyuncs.com:3717,dds-bp1be0f4f3bbdxxxx.mongodb.rds.aliyuncs.com:3717/admin?replicaSet=mgset-xxxx": The connection string of the MongoDB instance. Obtain this value as described in the previous step.
- threads=300: The number of concurrent threads for the client.
- target=100000: The target throughput in operations per second (ops/sec). The target for this test is 100,000 ops/sec.

Test results

Environment

Instance type	MongoDB version	recordcount	threads
64 vCPU, 512 GB (dedicated)	MongoDB 6.0 (minor kernel version 7.0.23)	10000000	300

Test scenarios

insert:read:update=100:0:0: A pure insert workload. The audit log is enabled for insert operations.
insert:read:update=0:0:100: A pure update workload. The audit log is enabled for update operations.
insert:read:update=50:50:0: 50% inserts and 50% reads. The audit log is enabled for insert and query operations.
insert:read:update=0:50:50: 50% reads and 50% updates. The audit log is enabled for query and update operations.
insert:read:update=30:70:0: 30% inserts and 70% reads. The audit log is enabled for insert and query operations.
insert:read:update=0:70:30: 70% reads and 30% updates. The audit log is enabled for query and update operations.

Metrics

CpuUsage: The CPU utilization of the instance.
MongoDB_RT: The average response time of the instance, including writes_avg_rt (average write response time) and reads_avg_rt (average read response time).
MongoDB_Opcounters: The number of query, insert, and update operations per second.

Test results

The following table summarizes performance changes after enabling audit logs for each scenario.

Test scenario	CpuUsage	MongoDB_RT	MongoDB_Opcounters
Pure insert (100:0:0)	Increase of 3 percentage points (+15%)	No significant change	No significant change
Pure update (0:0:100)	Increase of 3 percentage points (+20%)	No significant change	No significant change
50% insert + 50% read (50:50:0)	No significant change	writes_avg_rt: +700 μs (+20%); reads_avg_rt: +300 μs (+250%)	query: -5,000 (-20%); insert: -5,000 (-20%)
50% read + 50% update (0:50:50)	No significant change	writes_avg_rt: +500 μs (+18%); reads_avg_rt: +150 μs (+200%)	query: -5,000 (-15%); update: -5,000 (-15%)
30% insert + 70% read (30:70:0)	No significant change	writes_avg_rt: +600 μs (+20%); reads_avg_rt: +300 μs (+270%)	query: -12,000 (-20%); insert: -5,000 (-20%)
70% read + 30% update (0:70:30)	No significant change	writes_avg_rt: +500 μs (+20%); reads_avg_rt: +150 μs (+150%)	query: -10,000 (-15%); update: -5,000 (-15%)

Analysis

Write-only workloads: CPU usage increases slightly, but response time and throughput remain stable. Enabling audit logs for write-only scenarios has minimal overhead.
Mixed read/write workloads: CPU usage remains unchanged, but overall throughput drops by 15% to 20%, and both read and write response times increase noticeably.

Note

The percentage increase for reads_avg_rt appears high (150% to 270%) because the baseline is low (about 100 μs). The absolute increase is only 150 to 300 μs.