Skip to content

Latest commit

 

History

History
103 lines (75 loc) · 5.97 KB

README.md

File metadata and controls

103 lines (75 loc) · 5.97 KB

ironcore-alloy Kotlin Benchmarks

This directory contains a benchmark suite for the Kotlin version of ironcore-alloy. To build and run the benchmark, just execute the following commands from this directory:

docker compose up -d
../../gradlew bench

Tenant Security Proxy

In order to run the benchmarks, ironcore-alloy 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 ironcore-alloy Kotlin, 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 ironcore-alloy, 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 ironcore-alloy is a library that interacts with a back-end service (TSP), the benchmark results are not always straightforward to interpret. Most API calls in ironcore-alloy 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 Kotlin 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 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 the benchmark long enough you can overwhelm the TSP. In a real application, you would scale-out the TSP at this point. See the TSP documentation for more details.

Other Languages

There are also benchmarks available in Rust, Java, and Python.

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
SaasShieldBenchmark.batchEncrypt10DocsOf100B          avgt    5   545.626 ±  19.272  us/op
SaasShieldBenchmark.tspDecrypt100B                    avgt    5   148.846 ±  11.811  us/op
SaasShieldBenchmark.tspDecrypt10KB                    avgt    5   242.892 ±   2.902  us/op
SaasShieldBenchmark.tspDecrypt1B                      avgt    5   141.517 ±   7.603  us/op
SaasShieldBenchmark.tspDecrypt1MB                     avgt    5  9104.683 ±  74.820  us/op
SaasShieldBenchmark.tspEncrypt100B                    avgt    5   142.432 ±   5.696  us/op
SaasShieldBenchmark.tspEncrypt10KB                    avgt    5   246.627 ±   5.616  us/op
SaasShieldBenchmark.tspEncrypt1B                      avgt    5   139.817 ±   5.732  us/op
SaasShieldBenchmark.tspEncrypt1MB                     avgt    5  9322.918 ± 136.650  us/op
StandaloneBenchmark.standaloneRoundtripStandard100Kb  avgt    5   117.444 ±  56.447  us/op
StandaloneBenchmark.standaloneRoundtripStandard10B    avgt    5   112.489 ±  56.958  us/op
StandaloneBenchmark.standaloneRoundtripStandard10Kb   avgt    5   113.051 ±  51.750  us/op