Measuring Percona Server for MySQL On-Disk Decryption Overhead

Percona Server for MySQL 8.0 comes with enterprise grade total data encryption features. However, there is always the question of how much overhead – or performance penalty – comes with the data decryption. As we saw in my networking performance post , SSL under high concurrency might be problematic. Is this the case for data decryption?

To measure any overhead, I will start with a simplified read-only workload, where data gets decrypted during read IO.

During query execution, the data in memory is already decrypted so there is no additional processing time. The decryption happens only for blocks that require a read from storage.

For the benchmark I will use the following workload:

sysbench oltp_read_only -- mysql - ssl = off -- tables = 20 -- table - size = 10000000 -- threads = $i -- time = 300 -- report - interval = 1 -- rand - type = uniform run

The datasize for this workload is about 50GB, so I will use innodb_buffer_pool_size = 5GB to emulate a heavy disk read IO during the benchmark. In the second run, I will use innodb_buffer_pool_size = 60GB so all data is kept in memory and there are NO disk read IO operations.

I will only use table-level encryption at this time (ie: no encryption for binary log, system tablespace, redo-  and undo- logs).

The server I am using has AES hardware CPU acceleration. Read more at https://en.wikipedia.org/wiki/AES_instruction_set

Benchmark N1, heavy read IO

Threads encrypted storage no encryption encryption overhead 1 389.11 423.47 1.09 4 1531.48 1673.2 1.09 16 5583.04 6055 1.08 32 8250.61 8479.61 1.03 64 8558.6 8574.43 1.00 96 8571.55 8577.9 1.00 128 8570.5 8580.68 1.00 256 8576.34 8585 1.00 512 8573.15 8573.73 1.00 1024 8570.2 8562.82 1.00 2048 8422.24 8286.65 0.98

Benchmark N2, data in memory, no read IO

Threads Encryption No encryption 1 578.91 567.65 4 2289.13 2275.12 16 8304.1 8584.06 32 13324.02 13513.39 64 20007.22 19821.48 96 19613.82 19587.56 128 19254.68 19307.82 256 18694.05 18693.93 512 18431.97 18372.13 1024 18571.43 18453.69 2048 18509.73 18332.59

Observations

For a high number of threads, there is no measurable difference between encrypted and unencrypted storage. This is because a lot of CPU resources are spent in contention and waits, so the relative time spend in decryption is negligible.

However, we can see some performance penalty for a low number of threads: up to 9% penalty for hardware decryption. When data fully fits into memory, there is no measurable difference between encrypted and unencrypted storage.

So if you have hardware support then you should see little impact when using storage encryption with MySQL. The easiest way to check if you have support for this is to look at CPU flags and search for ‘aes’ string:

> lscpu | grep aes Flags : . . . tsc_deadline_timer aes xsave avx f16c . . .