Summary

There are currently no benchmarks for FLE/QE performance. We should add some benchmarks analogous to the existing non-encryption ones so that we can have a uniform way of assessing the impact of encryption on driver operations and also guard against regression in the FLE/QE APIs.

Motivation

Who is the affected end user?

FLE/QE users.

How does this affect the end user?

We haven't gotten any complaints yet, but it's better to start collecting performance data sooner rather than later.

How likely is it that this problem or use case will occur?

N/A

If the problem does occur, what are the consequences and how severe are they?

N/A

Is this issue urgent?

No, but it aligns with the Q3 performance emphasis from the product side.

Is this ticket required by a downstream team?

No

Is this ticket only for tests?

Yes

Acceptance Criteria

To provide a comparison between drivers, specify benchmarks for all drivers to implement:

• Benchmark explicit encryption using the CSFLE algorithm: AEAD_AES_256_CBC_HMAC_SHA_512-Random
• Benchmark explicit encryption using the QE algorithm: Indexed

To guard against regression in the CSFLE/QE APIs, test with one driver in the libmongocrypt project:

• Benchmark explicit encryption with each supported algorithm.
• Benchmark explicit decryption with each supported algorithm.
• Benchmark automatic encryption with each supported algorithm.
• Benchmark automatic decryption with each supported algorithm.

Benchmark only with the local KMS provider. libmongocrypt caches the decrypted Data Encryption Key (DEK). There is no expected benefit to testing other KMS providers.

Consider specifying these benchmarks alongside the benchmark defined in DRIVERS-2581. DRIVERS-2581 adds a benchmark for automatic decrypting of decrypting documents with many (e.g. 1500) encrypted fields using the algorithm AEAD_AES_256_CBC_HMAC_SHA_512-Deterministic.