Connection encryption is killing my performance! Help!

I find Encryption is blamed for a lot of performance issues so wanted to find out for myself how much of a performance hit we might be taking for common operations. There ain't no free lunch. Adding any extra processing or manipulation to an operation is going to add time to that operation.

Where can encryption be enabled when working with an Oracle database?
For Oracle there are two places to introduce encryption:
1) TDE encryption - This covers encryption of Data-at-Rest for data stored on disk drives. TDE can be applied to Tablespaces or Columns and
supports 3 types of encryption: 3DES168, AES128, AES256 [1]
2) Oracle Advanced Security Option (ASO) network Connection encryption.
This covers over-the-wire database connections from clients to servers (or servers to servers in the case of DB links). As of Oracle 12c this supports 2 types of encryption.

How much can it slow down operations?
But how much time will be added to your processing? I searched on the net. I posed the question to Oracle in a Service Request and got the Tech Support equivalent of a "No Comment". I did find one great academic paper that compared Oracle TDE encryption algorithms on 12c [2]. Give it a read, it is very interesting.

Since I didn't find anything on Connection Encryption I decided to write a Java/JDBC test harness to measure connection and row retrieval times for various configs - No connection encryption, 3DES168 connection encryption, and AES256 connection encryption. I used ojdbc8.jar against a 12c database. Here are my results:

===== Test 1 ===== SELECT * FROM NARROWTABLE; 3 columns, 38613 records
Encryption Type: NONE Connection=45ms / 1 runs of 38613 rows = 760 ms avg per exec
Encryption Type: NONE Connection=50ms / 5 runs of 38613 rows = 730 ms avg per exec
Encryption Type: NONE Connection=42ms / 10 runs of 38613 rows = 624 ms avg per exec [Baseline]
Encryption Type: 3DES168 Connection=380ms / 1 runs of 38613 rows = 796 ms avg per exec
Encryption Type: 3DES168 Connection=359ms / 5 runs of 38613 rows = 864 ms avg per exec
Encryption Type: 3DES168 Connection=364ms / 10 runs of 38613 rows = 798 ms avg per exec [27% slower than baseline]
Encryption Type: AES256 Connection=375ms / 1 runs of 38613 rows = 932 ms avg per exec
Encryption Type: AES256 Connection=352ms / 5 runs of 38613 rows = 725 ms avg per exec
Encryption Type: AES256 Connection=352ms / 10 runs of 38613 rows = 746 ms avg per exec [19% slower than baseline]

===== Test 2 - 20 cols ===== SELECT * FROM WIDETABLE; 20 columns, 34208 records
Encryption Type: NONE Connection=43ms / 1 runs of 34208 rows = 803 ms avg per exec
Encryption Type: NONE Connection=46ms / 5 runs of 34208 rows = 577 ms avg per exec
Encryption Type: NONE Connection=56ms / 10 runs of 34208 rows = 613 ms avg per exec [Baseline]
Encryption Type: 3DES168 Connection=354ms / 1 runs of 34208 rows = 672 ms avg per exec
Encryption Type: 3DES168 Connection=373ms / 5 runs of 34208 rows = 690 ms avg per exec
Encryption Type: 3DES168 Connection=354ms / 10 runs of 34208 rows = 728 ms avg per exec [18% slower than baseline]
Encryption Type: AES256 Connection=348ms / 1 runs of 34208 rows = 665 ms avg per exec
Encryption Type: AES256 Connection=354ms / 5 runs of 34208 rows = 671 ms avg per exec
Encryption Type: AES256 Connection=351ms / 10 runs of 34208 rows = 696 ms avg per exec [13% slower than baseline]

Conclusion:

  • The most noticeable time difference was connection time difference when using encryption. Observed connection initiation time was about 7X slower, averaging 350ms to initiate an encrypted connection vs 50ms for an unencrypted connection. Given the No Free Lunch hypothesis, Oracle confirms in a MOS Note [3] that this behavior is as expected. Key exchange causes the extra time and it cannot be circumvented. Originally opened as a bug and closed "As Designed".
  • Using 3DES168 or AES256 connection encryption did add some time to the retrieval of records. In my informal test of a "Narrow" and "Wide" result set I saw AES256 taking 13-19% more time and 3DES168 taking 18-27% more time to complete JDBC row retrieval.

So what can I do?


  • Well first and foremost, minimize creation of new encrypted connections. Make sure your processes establishes 1 connection and uses it over and over. A Connection Pool can be put in place to reduce the need to initiate new connections.
  • Second, there will be some overhead for moving data over an encrypted connection. Test your operations with encryption on and off to determine if the overhead is acceptable and if your security needs may be handled with other technologies (like VPN).

Footnotes:

[1] Performance Analysis of the Encryption Algorithms as Solution to Cloud Database Security by Nurtala Aminu Baba, Abdulrahman Yusuf, Aminu Ahmad, and Ladan Maijama

[2] Oracle 12.2 documentation only mentions support of AES128/AES192/AES256 as encryption algorithms for network connections.

[3] Slow Database Connection Using ASO Encryption (Doc ID 2000474.1)

Add new comment