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.

Using service invocation you can call from HTTP to HTTP, HTTP to gRPC, gRPC to HTTP, and gRPC to gRPC. Dapr does not use HTTP for the communication between sidecars, always using gRPC, while carrying over the semantics of the protocol used when called from the app. Service invocation is the underlying mechanism of communicating with Dapr Actors.

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 (Fortio) 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

The Dapr control plane uses a total of 0.009 vCPU and 61.6 Mb when running in non-HA mode, meaning a single replica per system compoment. When running in a highly available production setup, the Dapr control plane consumes ~0.02 vCPU and 185 Mb.

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.

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.