Skip to content

Commit

Permalink
add explanation for eagerScalingStrategy
Browse files Browse the repository at this point in the history
Signed-off-by: June Han <[email protected]>
  • Loading branch information
junekhan authored Jun 18, 2024
1 parent af1e81e commit d72e79b
Showing 1 changed file with 6 additions and 1 deletion.
7 changes: 6 additions & 1 deletion content/docs/2.15/concepts/scaling-jobs.md
Original file line number Diff line number Diff line change
Expand Up @@ -159,7 +159,7 @@ scalingStrategy:
strategy: "default" # Optional. Default: default. Which Scaling Strategy to use.
```

Select a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`.
Select a Scaling Strategy. Possible values are `default`, `custom`, `accurate`, or `eager`. The default value is `default`.

> 💡 **NOTE:**
>
Expand Down Expand Up @@ -230,6 +230,11 @@ if (maxScale + runningJobCount) > maxReplicaCount {
```
For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).

**eager**
When adopting the **default** strategy, you are likely to come into a subtle case where messages need to be consumed by spawning jobs but remain in the queue, even when there are available slots between `runningJobCount` and `maxReplicaCount`. The **eager** strategy comes to the rescue. It addresses this issue by utilizing all available slots up to the maxReplicaCount, ensuring that waiting messages are processed as quickly as possible.

To better understand the scenario, you may refer to [this issue](https://github.com/kedacore/keda/issues/5114).

---

```yaml
Expand Down

0 comments on commit d72e79b

Please sign in to comment.