Service invocation performance

Dapr consists of a data plane, the sidecar that runs next to your app, and a control plane that configures the sidecars and provides capabilities such as cert and identity management.

• Sidecar (data plane)
• Sentry (optional, control plane)
• Placement (optional, control plane)

For more information see overview of Dapr in self-hosted mode.

Kubernetes components

• Sidecar (data plane)
• Sentry (optional, control plane)
• Operator (control plane)
• Sidecar Injector (control plane)

For more information see overview of Dapr on Kubernetes.

Performance summary for Dapr v1.0

The service invocation API is a reverse proxy with built-in service discovery to connect to other services. This includes tracing, metrics, mTLS for in-transit encryption of traffic, together with resiliency in the form of retries for network partitions and connection errors.

For more information see service invocation overview.

The test was conducted on a 3 node Kubernetes cluster, using commodity hardware running 4 cores and 8GB of RAM, without any network acceleration. The setup included a load tester () pod with a Dapr sidecar injected into it that called the service invocation API to reach a pod on a different node.

Test parameters:

• 1000 requests per second
• Sidecar limited to 0.5 vCPU
• Sidecar mTLS enabled
• Sidecar telemetry enabled (tracing with a sampling rate of 0.1)

The baseline test included direct, non-encrypted traffic, without telemetry, directly from the load tester to the target app.

Control plane performance

There are a number of variants that affect the CPU and memory consumption for each of the system components. These variants are shown in the table below.

The Dapr sidecar uses 0.48 vCPU and 23Mb per 1000 requests per second. End-to-end, the Dapr sidecars (client and server) add ~1.40 ms to the 90th percentile latency, and ~2.10 ms to the 99th percentile latency. End-to-end here is a call from one app to another app receiving a response. This is shown by steps 1-7 in .

This performance is on par or better than commonly used service meshes.

Latency

In the test setup, requests went through the Dapr sidecar both on the client side (serving requests from the load tester tool) and the server side (the target app). mTLS and telemetry (tracing with a sampling rate of 0.1) and metrics were enabled on the Dapr test, and disabled for the baseline test.