From f572f8d74ad6e756a68c3b2789391170032fb286 Mon Sep 17 00:00:00 2001 From: Deepanshu Agarwal Date: Wed, 11 Oct 2023 20:44:56 +0530 Subject: [PATCH 1/6] Optimization Opportunities Signed-off-by: Deepanshu Agarwal --- .../building-blocks/pubsub/pubsub-bulk.md | 38 ++++++++++++++++--- 1 file changed, 33 insertions(+), 5 deletions(-) diff --git a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md index b6b592a0612..9e44faa716d 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md +++ b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md @@ -302,10 +302,10 @@ In the example above, `bulkSubscribe` is _optional_. If you use `bulkSubscribe`, - `enabled` is mandatory and enables or disables bulk subscriptions on this topic - You can optionally configure the max number of messages (`maxMessagesCount`) delivered in a bulk message. Default value of `maxMessagesCount` for components not supporting bulk subscribe is 100 i.e. for default bulk events between App and Dapr. Please refer [How components handle publishing and subscribing to bulk messages]({{< ref pubsub-bulk >}}). -If a component supports bulk subscribe, then default value for this parameter can be found in that component doc. Please refer [Supported components]({{< ref pubsub-bulk >}}). +If a component supports bulk subscribe, then default value for this parameter can be found in that component doc. - You can optionally provide the max duration to wait (`maxAwaitDurationMs`) before a bulk message is sent to the app. Default value of `maxAwaitDurationMs` for components not supporting bulk subscribe is 1000 i.e. for default bulk events between App and Dapr. Please refer [How components handle publishing and subscribing to bulk messages]({{< ref pubsub-bulk >}}). -If a component supports bulk subscribe, then default value for this parameter can be found in that component doc. Please refer [Supported components]({{< ref pubsub-bulk >}}). +If a component supports bulk subscribe, then default value for this parameter can be found in that component doc. The application receives an `EntryId` associated with each entry (individual message) in the bulk message. This `EntryId` must be used by the app to communicate the status of that particular entry. If the app fails to notify on an `EntryId` status, it's considered a `RETRY`. @@ -473,9 +473,37 @@ public class BulkMessageController : ControllerBase {{< /tabs >}} ## How components handle publishing and subscribing to bulk messages -Some pub/sub brokers support sending and receiving multiple messages in a single request. When a component supports bulk publish or subscribe operations, Dapr runtime uses them to further optimize the communication between the Dapr sidecar and the underlying pub/sub broker. - -For components that do not have bulk publish or subscribe support, Dapr runtime uses the regular publish and subscribe APIs to send and receive messages one by one. This is still more efficient than directly using the regular publish or subscribe APIs, because applications can still send/receive multiple messages in a single request to/from Dapr. +When talking about event publish/subscribe, there are two kind of network transfers involved. +1. From/To *App* To/From *Dapr*. +2. From/To *Dapr* To/From *Pubsub Broker*. + +And, these are the opportunities where optimization is possible for multiple Single calls v/s Bulk. Here, optimization means that Bulk calls are sent, which reduce number of overall calls and thus increased throughput ad better latency. + +On enabling Bulk Publish and/or Bulk Subscribe, Point 1 i.e. From/To *App* To/From *Dapr* is optimized for All components (depending on whether either one of Bulk Publish/ Bulk Subscribe OR Both are enabled). + +But, optimization of Point 2 i.e. From/To *Dapr* To/From *Pubsub Broker* would depend on a number of factors, i.e. if Broker inherently supports Bulk Publish/Subscribe and if Dapr component is updated to support Batching. Currently, following components are updated to support this level of optimization: + + + + + + + + + + + + + + + + + + + + + +
ComponentBulk PublishBulk Subscribe
KafkaYesYes
Azure ServicebusYesYes
Azure EventhubsYesYes
## Demos From 34f0989a10d7b885d63087d78b74be55c507f56e Mon Sep 17 00:00:00 2001 From: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com> Date: Wed, 11 Oct 2023 18:07:38 -0400 Subject: [PATCH 2/6] Update daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md Co-authored-by: Mukundan Sundararajan <65565396+mukundansundar@users.noreply.github.com> Signed-off-by: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com> --- .../building-blocks/pubsub/pubsub-bulk.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md index 9e44faa716d..854955712e9 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md +++ b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md @@ -477,7 +477,7 @@ When talking about event publish/subscribe, there are two kind of network transf 1. From/To *App* To/From *Dapr*. 2. From/To *Dapr* To/From *Pubsub Broker*. -And, these are the opportunities where optimization is possible for multiple Single calls v/s Bulk. Here, optimization means that Bulk calls are sent, which reduce number of overall calls and thus increased throughput ad better latency. +These are the opportunities where optimization is possible. When optimized, a Bulk requests are, which reduce number of overall calls and thus increase throughput and provide better latency. On enabling Bulk Publish and/or Bulk Subscribe, Point 1 i.e. From/To *App* To/From *Dapr* is optimized for All components (depending on whether either one of Bulk Publish/ Bulk Subscribe OR Both are enabled). From b5eca24317990db61b179a6b7aed1657e1b9adf9 Mon Sep 17 00:00:00 2001 From: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com> Date: Wed, 11 Oct 2023 18:07:48 -0400 Subject: [PATCH 3/6] Update daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md Co-authored-by: Mukundan Sundararajan <65565396+mukundansundar@users.noreply.github.com> Signed-off-by: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com> --- .../building-blocks/pubsub/pubsub-bulk.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md index 854955712e9..30d30944639 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md +++ b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md @@ -479,7 +479,7 @@ When talking about event publish/subscribe, there are two kind of network transf These are the opportunities where optimization is possible. When optimized, a Bulk requests are, which reduce number of overall calls and thus increase throughput and provide better latency. -On enabling Bulk Publish and/or Bulk Subscribe, Point 1 i.e. From/To *App* To/From *Dapr* is optimized for All components (depending on whether either one of Bulk Publish/ Bulk Subscribe OR Both are enabled). +On enabling Bulk Publish and/or Bulk Subscribe, the communication between the App and Dapr sidecar (Point 1 above) is optimized for **all components**. But, optimization of Point 2 i.e. From/To *Dapr* To/From *Pubsub Broker* would depend on a number of factors, i.e. if Broker inherently supports Bulk Publish/Subscribe and if Dapr component is updated to support Batching. Currently, following components are updated to support this level of optimization: From 1a2f5673b788f0a486ce1c40620921f6b9fc0e63 Mon Sep 17 00:00:00 2001 From: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com> Date: Wed, 11 Oct 2023 18:07:56 -0400 Subject: [PATCH 4/6] Update daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md Co-authored-by: Mukundan Sundararajan <65565396+mukundansundar@users.noreply.github.com> Signed-off-by: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com> --- .../building-blocks/pubsub/pubsub-bulk.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md index 30d30944639..ef994f4328d 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md +++ b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md @@ -481,7 +481,11 @@ These are the opportunities where optimization is possible. When optimized, a Bu On enabling Bulk Publish and/or Bulk Subscribe, the communication between the App and Dapr sidecar (Point 1 above) is optimized for **all components**. -But, optimization of Point 2 i.e. From/To *Dapr* To/From *Pubsub Broker* would depend on a number of factors, i.e. if Broker inherently supports Bulk Publish/Subscribe and if Dapr component is updated to support Batching. Currently, following components are updated to support this level of optimization: +Optimization from Dapr sidecar to the pub/sub broker would depend on a number of factors, for example: +- If the broker inherently supports Bulk pub/sub +- If the Dapr component is updated to support the use of bulk APIs provided by the broker. + +Currently, the following components are updated to support this level of optimization:
From 5146413dda5b96feb55f1931a5cd39e8ae374152 Mon Sep 17 00:00:00 2001 From: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com> Date: Wed, 11 Oct 2023 18:08:34 -0400 Subject: [PATCH 5/6] Update daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md Signed-off-by: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com> --- .../building-blocks/pubsub/pubsub-bulk.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md index ef994f4328d..05bc1bc59c1 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md +++ b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md @@ -475,7 +475,7 @@ public class BulkMessageController : ControllerBase When talking about event publish/subscribe, there are two kind of network transfers involved. 1. From/To *App* To/From *Dapr*. -2. From/To *Dapr* To/From *Pubsub Broker*. +1. From/To *Dapr* To/From *Pubsub Broker*. These are the opportunities where optimization is possible. When optimized, a Bulk requests are, which reduce number of overall calls and thus increase throughput and provide better latency. From c47d29df084cdf75a7ccd3eed3b0367776af305b Mon Sep 17 00:00:00 2001 From: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com> Date: Wed, 11 Oct 2023 18:08:53 -0400 Subject: [PATCH 6/6] Update daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md Signed-off-by: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com> --- .../building-blocks/pubsub/pubsub-bulk.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md index 05bc1bc59c1..3961d37570d 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md +++ b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md @@ -473,7 +473,7 @@ public class BulkMessageController : ControllerBase {{< /tabs >}} ## How components handle publishing and subscribing to bulk messages -When talking about event publish/subscribe, there are two kind of network transfers involved. +For event publish/subscribe, two kinds of network transfers are involved. 1. From/To *App* To/From *Dapr*. 1. From/To *Dapr* To/From *Pubsub Broker*.
Component