diff --git a/daprdocs/content/en/concepts/faq/faq.md b/daprdocs/content/en/concepts/faq/faq.md index c2fb33457fb..9e96c91eed0 100644 --- a/daprdocs/content/en/concepts/faq/faq.md +++ b/daprdocs/content/en/concepts/faq/faq.md @@ -10,7 +10,7 @@ description: "Common questions asked about Dapr" Dapr is not a service mesh. While service meshes focus on fine-grained network control, Dapr is focused on helping developers build distributed applications. Both Dapr and service meshes use the sidecar pattern and run alongside the application. They do have some overlapping features, but also offer unique benefits. For more information please read the [Dapr & service meshes]({{%ref service-mesh%}}) concept page. ## Performance Benchmarks -The Dapr project is focused on performance due to the inherent discussion of Dapr being a sidecar to your application. See [here]({{% ref perf-service-invocation %}}) for updated performance numbers. +The Dapr project is focused on performance due to the inherent discussion of Dapr being a sidecar to your application. See [performance results](https://github.com/dapr/dapr/tree/release-1.16/tests/perf/report/charts) for updated performance numbers. ## Actors diff --git a/daprdocs/content/en/developing-applications/building-blocks/service-invocation/service-invocation-overview.md b/daprdocs/content/en/developing-applications/building-blocks/service-invocation/service-invocation-overview.md index ab3f93bee72..4f391c03e51 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/service-invocation/service-invocation-overview.md +++ b/daprdocs/content/en/developing-applications/building-blocks/service-invocation/service-invocation-overview.md @@ -156,6 +156,6 @@ For quick testing, try using the Dapr CLI for service invocation: ## Next steps - Read the [service invocation API specification]({{% ref service_invocation_api %}}). This reference guide for service invocation describes how to invoke methods on other services. -- Understand the [service invocation performance numbers]({{% ref perf-service-invocation %}}). +- Understand the [service invocation performance numbers](https://github.com/dapr/dapr/tree/release-1.16/tests/perf/report/charts/). - Take a look at [observability]({{% ref observability %}}). Here you can dig into Dapr's monitoring tools like tracing, metrics and logging. - Read up on our [security practices]({{% ref security-concept %}}) around mTLS encryption, token authentication, and endpoint authorization. diff --git a/daprdocs/content/en/operations/performance-and-scalability/perf-actors-activation.md b/daprdocs/content/en/operations/performance-and-scalability/perf-actors-activation.md deleted file mode 100644 index e463ae6c8bf..00000000000 --- a/daprdocs/content/en/operations/performance-and-scalability/perf-actors-activation.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -type: docs -title: "Actors activation performance" -linkTitle: "Actors activation performance" -weight: 20000 -description: "" ---- -This article provides service invocation API performance benchmarks and resource utilization for actors in Dapr on Kubernetes. - -## System overview - -For applications using actors in Dapr there are two aspects to be considered. First, is the routing of actor invocations handled by Dapr sidecar. Second, is the actors runtime that is implemented and handled on the application side and depends on the SDK. For now, the performance tests are using the Java SDK to provide an actors runtime in the application. - -### Kubernetes components - -* Sidecar (data plane) -* Placement (required for actors, control plane mapping actor types to hosts) -* Operator (control plane) -* Sidecar Injector (control plane) -* Sentry (optional, control plane) - -## Performance summary for Dapr v1.0 - -The actors API in Dapr sidecar will identify which hosts are registered for a given actor type and route the request to the appropriate host for a given actor ID. The host runs an instance of the application and uses the Dapr SDK (.Net, Java, Python or PHP) to handle actors requests via HTTP. - -This test uses invokes actors via Dapr's HTTP API directly. - -For more information see [actors overview]({{% ref actors-overview.md %}}). - -### Kubernetes performance test setup - -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](https://github.com/fortio/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: - -* 500 requests per second -* 1 replica -* 1 minute duration -* Sidecar limited to 0.5 vCPU -* mTLS enabled -* Sidecar telemetry enabled (tracing with a sampling rate of 0.1) -* Payload of an empty JSON object: `{}` - -### Results - -* The actual throughput was ~500 qps. -* The tp90 latency was ~3ms. -* The tp99 latency was ~6.2ms. -* Dapr app consumed ~523m CPU and ~304.7Mb of Memory -* Dapr sidecar consumed 2m CPU and ~18.2Mb of Memory -* No app restarts -* No sidecar restarts - -## Related links -* For more information see [overview of Dapr on Kubernetes]({{% ref kubernetes-overview.md %}}) \ No newline at end of file diff --git a/daprdocs/content/en/operations/performance-and-scalability/perf-results.md b/daprdocs/content/en/operations/performance-and-scalability/perf-results.md new file mode 100644 index 00000000000..ac9aaa86a60 --- /dev/null +++ b/daprdocs/content/en/operations/performance-and-scalability/perf-results.md @@ -0,0 +1,14 @@ +--- +type: docs +title: "Performance results" +linkTitle: "Performance results" +weight: 10000 +description: "Performance benchmarks and charts for Dapr APIs" +--- + +For performance results, please see the [Dapr performance test suite](https://github.com/dapr/dapr/tree/release-1.16/tests/perf/report/charts) in the dapr/dapr repository, where you can +view performance charts and numbers per Dapr version and API available. + +Visit the [performance charts directory](https://github.com/dapr/dapr/tree/release-1.16/tests/perf/report/charts) to view detailed performance metrics, including latency, throughput, and +resource utilization per API across different Dapr versions. + diff --git a/daprdocs/content/en/operations/performance-and-scalability/perf-service-invocation.md b/daprdocs/content/en/operations/performance-and-scalability/perf-service-invocation.md deleted file mode 100644 index fc0816e8620..00000000000 --- a/daprdocs/content/en/operations/performance-and-scalability/perf-service-invocation.md +++ /dev/null @@ -1,92 +0,0 @@ ---- -type: docs -title: "Service invocation performance" -linkTitle: "Service invocation performance" -weight: 10000 -description: "" ---- -This article provides service invocation API performance benchmarks and resource utilization for the components needed to run Dapr in different hosting environments. - -## System overview - -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. - -### Self-hosted components - -* Sidecar (data plane) -* Sentry (optional, control plane) -* Placement (optional, control plane) - -For more information see [overview of Dapr in self-hosted mode]({{% ref self-hosted-overview.md %}}). - -### Kubernetes components - -* Sidecar (data plane) -* Sentry (optional, control plane) -* Placement (optional, control planee) -* Operator (control plane) -* Sidecar Injector (control plane) - -For more information see [overview of Dapr on Kubernetes]({{% ref kubernetes-overview.md %}}). - -## 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. - -For more information see [service invocation overview]({{% ref service-invocation-overview.md %}}). - -### Kubernetes performance test setup - -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](https://github.com/fortio/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) -* Payload of 1KB - -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 component. -When running in a highly available production setup, the Dapr control plane consumes ~0.02 vCPU and 185 Mb. - -| Component | vCPU | Memory -| ------------- | ------------- | ------------- -| Operator | 0.001 | 12.5 Mb -| Sentry | 0.005 | 13.6 Mb -| Sidecar Injector | 0.002 | 14.6 Mb -| Placement | 0.001 | 20.9 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. - -| Component | vCPU | Memory -| ------------- | ------------- | ------------------------ -| Operator | Number of pods requesting components, configurations and subscriptions | -| Sentry | Number of certificate requests | -| Sidecar Injector | Number of admission requests | -| Placement | Number of actor rebalancing operations | Number of connected actor hosts - -### Data plane performance - -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 diagram]({{% ref service-invocation-overview.md %}}). - -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. - -Latency for 90th percentile - -
- -Latency for 99th percentile diff --git a/daprdocs/static/images/perf_invocation_p90.png b/daprdocs/static/images/perf_invocation_p90.png deleted file mode 100644 index 71327a80dd6..00000000000 Binary files a/daprdocs/static/images/perf_invocation_p90.png and /dev/null differ diff --git a/daprdocs/static/images/perf_invocation_p99.png b/daprdocs/static/images/perf_invocation_p99.png deleted file mode 100644 index 5d840e3d9dd..00000000000 Binary files a/daprdocs/static/images/perf_invocation_p99.png and /dev/null differ