Introduction

Transparent data encryption (TDE) is an optional feature supported by version 15 of EDB Postgres Advanced Server and EDB Postgres Extended Server.

It encrypts any user data stored in the database system. This encryption is transparent to the user. User data includes the actual data stored in tables and other objects, as well as system catalog data such as the names of objects.

For more information about EDB’s TDE implementation: https://www.enterprisedb.com/docs/tde/latest/

In this blog post, we will go through 2 benchmarks that were performed by EDB’s Performance and Architecture Team (PEAT) to evaluate the impact of using EDB’s Transparent Data Encryption. We will then be able to answer the following questions:

• What is the impact of TDE on performance during a transactional workload?
• What is the impact of TDE on the upgrade process when upgrading an unencrypted database cluster to an encrypted database cluster?

 

Impact on Performance

 

Benchmark Description

The workload used in this benchmark is TPROC-C (HammerDB) with a database populated by 2000 warehouses (~200GB of data). The target database engine is EDB Advanced Server version 15.

Two tests are executed in this benchmark:

1. ramping up tests with a growing number of virtual users
2. long-run test (1 hour) executed with a high (75) number of virtual users.

For each test, we are measuring the Number of Orders Per Minute (NOPM), returned by HammerDB, for both a database cluster using TDE as well as another database cluster not using TDE.

The same performance tuning is applied to both database clusters.

System Characteristics

AWS instance type	c5d.18xlarge
Operating System	Rocky8
vCPU	72
Memory	144GB
$PGDATA	XFS / 900GB NVMe SSD
$PGWAL	XFS / 900GB NVMe SSD

 

PostgreSQL Tuning

The following PostgreSQL settings have been applied on all database clusters:

shared_buffers='36GB'
max_connections=1000
checkpoint_completion_target='0.93'
checkpoint_timeout='30min'
max_wal_size='300GB'
effective_cache_size='100GB'
random_page_cost=1
seq_page_cost=1
effective_io_concurrency=200

 

Benchmark Results

Test #1: Ramping Up

In this test, HammerDB is executed with a growing number (5 by 5) of virtual users, from  five to 95. For each number of virtual users, the test duration is 20 minutes. This test is executed against both TDE enabled and no-TDE EPAS instances.

 

Observations:

• From 0 to 60 virtual users, TDE and no-TDE NOPM rates are very close.
• From 60 to 95 virtual users, no-TDE NOPM rate is a bit higher. When using TDE, transactions are processed 2.5% slower than when not using TDE.

 

Test #2: Steady State

In this test, HammerDB is configured to use 75 virtual users. The test duration is set to 1 hour, with a ramp-up duration set to 5 minutes. This test is executed against both TDE-enabled and no-TDE EPAS instances.

CPU usage - No-TDE

 

CPU usage - TDE

Memory usage

 

PGDATA Read throughput (kB/s)

 

 

PGDATA Write throughput (kB/s)

 

 

PGWAL Write throughput (kB/s)

 

 

New-Orders per minute (NOPM)

No-TDE	TDE-enabled	Added Overhead
1447296	1341344	7.3%

Impact on the Upgrade Process, using pg_upgrade

 

Benchmark Description

Data encryption has a cost. In this benchmark, we are evaluating that cost when upgrading an unencrypted EPAS cluster in version 14 to both encrypted and not encrypted EPAS clusters in version 15. Thus, we will be able to measure encryption costs in terms of duration and CPU usage that the pg_upgrade operation takes.

The data set used in this benchmark is generated by HammerDB. Database size is 300GB (3000 TPROC-C warehouses).

The CPU usage and elapsed time the pg_upgrade process is taking are tracked and measured with the help of the time tool.

The Page checksum feature is enabled for both database clusters.

 

Table Sizes

 

Table name	Table size	Indexes size
stock	95 GB	8671 MB
order_line	78 GB	27 GB
customer	51 GB	7728 MB
history	6892 MB	1960 kB
orders	5170 MB	5423 MB
new_order	1140 MB	813 MB
item	10 MB	2240 kB
district	3760 kB	808 kB
warehouse	2208 kB	120 kB

 

pg_upgrade Commands

The following pg_upgrade commands are executed, depending if TDE is enabled or not.

When TDE is not enabled:
 

$ /usr/edb/as15/bin/pg_upgrade \
  -d /pgdata/data \
  -D /pgdata/data_15 \
  -b /usr/edb/as14/bin \
  -B /usr/edb/as15/bin \
  --copy-by-block

 

When TDE is enabled:

$ /usr/edb/as15/bin/pg_upgrade \
  -d /pgdata/data \
  -D /pgdata/data_15 \
  -b /usr/edb/as14/bin \
  -B /usr/edb/as15/bin \
  --copy-by-block \
  --key-unwrap-command "cat /pgdata/data_15/pg_encryption/key.bin"

Note: using --copy-by-block is necessary when upgrading to an encrypted database cluster.

 

System Characteristics

AWS instance type	c5d.12xlarge
Operating System	Rocky8
vCPU	48
Memory	96 GB
$PGDATA	XFS - 1 x 900GB NVMe SSD
$PGWAL	XFS - 1 x 900GB NVMe SSD

Benchmark Results

System and User CPU time

The following chart shows System and User CPU time elapsed during the upgrade process.

 

Overall CPU usage

CPU usage of the pg_upgrade process.

 

 

Elapsed Time

Time elapsed during pg_upgrade execution.

 

 

Conclusion

Performance Benchmark

The performance benchmark highlights the following outcomes:

• When the system CPU is not overloaded, using a low number of virtual users, the impact of enabling TDE on performance is not significant.
• When the system CPU usage is intense, with a high number of virtual users, the impact of TDE has been measured to a 7.3% drop in terms of transaction rate that the database system can handle.
• In this TPC-C-like (TPROC-C) context, according to the PGWAL Write throughput chart, enabling TDE does not seem to lead to a higher database page rate or a bigger database size.

pg_upgrade benchmark

In the context of this benchmark, upgrading 300GB of data to an encrypted database cluster (using TDE) does not significantly increase the overall upgrade process duration.

Even if the upgrade process to the encrypted cluster takes 11% more CPU, this does not really affect the overall duration.

Compared to upgrading to an unencrypted database cluster, the time overhead is only 0.3%.

The benchmarks described in this article indicate that the use of EDB's TDE extension does not have a significant impact on transaction performance (<7.5%) or database upgrade times (0.3%).