Skip to content

Latest commit

 

History

History
108 lines (78 loc) · 5.86 KB

README.md

File metadata and controls

108 lines (78 loc) · 5.86 KB
Raw

TSC Benchmarks

This directory contains a benchmark suite for the Java version of the Tenant Security Client (TSC). To build and run the benchmark, just execute the following commands in this directory:

To show single threaded latency of a roundtrip (encrypt/decrypt):

mvn clean install
java -Xms1024m -Xmx1024m -jar target/benchmarks.jar -f 0 -wi 1

A variation that will show throughput instead:

mvn clean install
java -Xms1024m -Xmx1024m -jar target/benchmarks.jar -f 0 -wi 1 -bm thrpt -tu s

You have to benchmark an actual version of the TSC, though this can be a SNAPSHOT version published locally. Update the pom.xml to whatever version you'd like to test.

Tenant Security Proxy

In order to run the benchmarks, the TSC needs to connect to a Tenant Security Proxy (TSP). This service is provided as a Docker container, so it is easy to run the proxy on any computer that has Docker installed. IronCore Labs hosts the Docker container on a publicly accessible container registry, so you can pull the image from there and run it locally.

In addition to the Docker containers, you need a configuration file that specifies how the TSP should communicate with the IronCore Labs Configuration Broker and Data Control Platform, which work together to enable the end-to-end encryption that keeps all of the tenant KMS configuration information secure. To simplify the process of running these examples, we have created a demo vendor and tenants that you can use for the examples; all the necessary configuration information is included in the demo-tsp.conf file in this directory.

NOTE: Normally, the file containing the configuration would be generated by the vendor and loaded into a Kubernetes secret or similar mechanism for securely loading the configuration into the docker container. We have included this configuration in the repository as a convenience. Also note that these accounts are all created in IronCore's staging infrastructure.

Production TSPs will often be accompanied by one or more Tenant Security Logdriver instances. Because the purpose of this benchmark is to demonstrate the capabilities of the Tenant Security Client, we have chosen to not include Logdriver in it. If you wish to modify the Docker Compose file to include Logdriver, be sure to consult its Deployment page to learn how to properly configure it based on the resources you have available.

The following docker compose command will get a TSP running on your computer with the provided configuration:

docker compose up

This starts the TSP locally listening on port 32804. The benchmark expects to connect to the TSP at that address.

To connect with and use the TSP, you need to supply a couple more configuration values: the first is the API key that the TSP uses to authenticate requests from the TSC, and the second is the tenant ID to use.

The API key value is specified in the demo-tsp.conf file. You can just set the environment variable to the same value:

export API_KEY=0WUaXesNgbTAuLwn

The benchmark can be run using a different cloud KMS by selecting a different tenant configured for our demo SaaS vendor. There are six tenants defined; their IDs are the following:

  • tenant-gcp
  • tenant-aws
  • tenant-azure
  • tenant-gcp-l
  • tenant-aws-l
  • tenant-azure-l

The last three are similar to the first three, but they have key leasing enabled.

By default, the benchmark will use the tenant-gcp-l tenant. If you would like to experiment with a different tenant, just do:

export TENANT_ID=<select tenant ID>

before running the benchmark.

Interpreting Results

Since TSC-java is a library that interacts with a back-end service (TSP), the benchmark results are not always straightforward to interpret. Most API calls in the TSC make a round-trip to the TSP, and the TSP also does some computation. If testing on a single machine, it is good to monitor the CPU/RAM usage of the TSP processes in addition to the Java benchmark process to make sure you aren't resource constrained.

In general, operation latency is a function of latency to the TSP + latency to the tenant's KMS (if key-leasing is disabled).

The TSP's tenant logging mechanism has some tunable limits. By default, a TSP should be able to sustain 500 ops/sec/tenant, with the ability to burst higher for a limited time. The benchmark is using a single tenant, and (depending on your machine and benchmark config) can easily be executing a few thousand ops/sec. If you run a benchmark long enough you will overwhelm the TSP. In a real application, you would scale-out the TSP at this point. See the TSP documentation for more details.

Results

The following benchmarking run was done on May 7, 2024 on a MacBook Pro (2023) with an Apple M2 Max chip. It uses a locally-built TSP running with the configuration from demo-tsp.conf.

Benchmark                                      Mode  Cnt      Score     Error  Units
IntegrationBenchmark.batchEncrypt10DocsOf100B  avgt    5    844.824 ±   3.801  us/op
IntegrationBenchmark.decrypt100B               avgt    5    103.031 ±   1.749  us/op
IntegrationBenchmark.decrypt10KB               avgt    5    286.778 ±   1.356  us/op
IntegrationBenchmark.decrypt1B                 avgt    5    101.443 ±   0.560  us/op
IntegrationBenchmark.decrypt1MB                avgt    5  15066.330 ± 295.535  us/op
IntegrationBenchmark.encrypt100B               avgt    5    103.365 ±   0.600  us/op
IntegrationBenchmark.encrypt10KB               avgt    5    287.138 ±   2.928  us/op
IntegrationBenchmark.encrypt1B                 avgt    5    102.163 ±   0.403  us/op
IntegrationBenchmark.encrypt1MB                avgt    5  15193.096 ± 280.676  us/op