Skip to content

Commit d3a4b6c

Browse files
committed
update subscriptionName
Signed-off-by: Hannah Hunter <[email protected]>
1 parent 454b368 commit d3a4b6c

File tree

1 file changed

+10
-10
lines changed

1 file changed

+10
-10
lines changed

articles/container-apps/dapr-keda-scaling.md

Lines changed: 10 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -10,19 +10,19 @@ ms.date: 04/11/2023
1010

1111
# Scale Dapr applications with KEDA scalers
1212

13-
Using [KEDA scalers](https://keda.sh/), you can scale your application and its [Dapr](https://docs.dapr.io/) sidecar when it has scaled to zero with inbound events and messages. In this guide, we demonstrate scaling a Dapr pub/sub application by setting up a KEDA scaler to watch for messages coming into the queue and triggers the app to scale up and down as needed.
13+
Using [KEDA scalers](https://keda.sh/), you can scale your application and its [Dapr](https://docs.dapr.io/) sidecar when it has scaled to zero with inbound events and messages. In this guide, we demonstrate scaling a Dapr pub/sub application by setting up a KEDA scaler to watch for messages coming into the topic and triggers the app to scale up and down as needed.
1414

1515
In the following scenario, we examine the Bicep for:
16-
1. A `checkout` publisher container app continuously publishes messages via the Dapr pub/sub API to the `orders` topic in Azure Service Bus.
16+
1. A `checkout` publisher container app that continuously publishes messages via the Dapr pub/sub API to the `orders` topic in Azure Service Bus.
1717
1. The Dapr Azure Service Bus component.
18-
1. An `order-processor` subscriber container app subscribed to the `orders` topic receives and processes messages as they arrive.
19-
1. The scale rule for Azure Service Bus, which is responsible for scaling up the `order-processor` service and its Dapr sidecar when messages start to arrive to the`orders` topic.
18+
1. An `order-processor` subscriber container app subscribed to the `orders` topic that receives and processes messages as they arrive.
19+
1. The scale rule for Azure Service Bus, which is responsible for scaling up the `order-processor` service and its Dapr sidecar when messages start to arrive to the `orders` topic.
2020

2121
## Publisher container app
2222

2323
The `checkout` publisher is a headless service that runs indefinitely and never scales down to zero.
2424

25-
Below, we've set the `minReplicas` to "1", which ensures the container app doesn't follow the default behavior of scaling to zero with no incoming HTTP traffic.
25+
By default, [Container Apps assigns an http-based scale rule to applications](./scale-app.md), scaling apps based on the number of incoming HTTP requests. Below, we've set the `minReplicas` to "1", which ensures the container app doesn't follow the default behavior of scaling to zero with no incoming HTTP traffic.
2626

2727
```bicep
2828
resource checkout 'Microsoft.App/containerApps@2022-03-01' = {
@@ -113,7 +113,7 @@ resource daprComponent 'daprComponents' = {
113113

114114
## Subscriber container app
115115

116-
By default, [Container Apps assigns an http-based scale rule to applications](./scale-app.md), scaling apps based on the number of incoming HTTP requests. In the `order-processor` subscriber, we've added a custom scale rule on the resource for the type `azure-servicebus`. With this scale rule, KEDA can scale up the container app and its Dapr sidecar, allowing incoming messages to be processed.
116+
In the `order-processor` subscriber, we've added a custom scale rule on the resource for the type `azure-servicebus`. With this scale rule, KEDA can scale up the container app and its Dapr sidecar, allowing incoming messages to be processed.
117117

118118
```bicep
119119
resource orders 'Microsoft.App/containerApps@2022-03-01' = {
@@ -186,8 +186,8 @@ resource orders 'Microsoft.App/containerApps@2022-03-01' = {
186186
type: 'azure-servicebus'
187187
metadata: {
188188
topicName: 'orders'
189-
subscriptionName: 'orders'
190-
messageCount: '30'
189+
subscriptionName: 'membership-orders'
190+
messageCount: '1'
191191
}
192192
auth: [
193193
{
@@ -209,11 +209,11 @@ Behind the scenes, KEDA scales our `order-processor` appropriately (even down to
209209
```bicep
210210
metadata: {
211211
//...
212-
messageCount: '30'
212+
messageCount: '1'
213213
}
214214
```
215215

216-
This property tells KEDA how many messages each instance of our application can process at the same time. Since the application is single-threaded, we'd normally set this value to 1, resulting in KEDA scaling up our application to match the number of messages waiting in the queue. For example, if five messages are waiting, KEDA scales our app up to five instances. In our scenario, we set a `maxReplicas` value of 10, so KEDA scales up the `order-processor` container app to a max of 10 replicas.
216+
This property tells KEDA how many messages each instance of our application can process at the same time. Since the application is single-threaded, we set this value to 1, resulting in KEDA scaling up our application to match the number of messages waiting in the queue. For example, if five messages are waiting, KEDA scales our app up to five instances. In our scenario, we set a `maxReplicas` value of 10, so KEDA scales up the `order-processor` container app to a max of 10 replicas.
217217

218218
## Next steps
219219

0 commit comments

Comments
 (0)