From d72e79b7d0d32ab14f7a96978c9c672540787daa Mon Sep 17 00:00:00 2001 From: June Han Date: Tue, 18 Jun 2024 22:41:03 +0900 Subject: [PATCH 1/3] add explanation for eagerScalingStrategy Signed-off-by: June Han --- content/docs/2.15/concepts/scaling-jobs.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/content/docs/2.15/concepts/scaling-jobs.md b/content/docs/2.15/concepts/scaling-jobs.md index 9a5c58595..3bba1354f 100644 --- a/content/docs/2.15/concepts/scaling-jobs.md +++ b/content/docs/2.15/concepts/scaling-jobs.md @@ -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:** > @@ -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 From 4e974b3541f7be5a29f588be26f6859f097975ae Mon Sep 17 00:00:00 2001 From: June Han Date: Thu, 27 Jun 2024 10:21:40 +0900 Subject: [PATCH 2/3] Add illustration Signed-off-by: June Han --- content/docs/2.15/concepts/scaling-jobs.md | 37 +++++++++++++++++++++- 1 file changed, 36 insertions(+), 1 deletion(-) diff --git a/content/docs/2.15/concepts/scaling-jobs.md b/content/docs/2.15/concepts/scaling-jobs.md index 3bba1354f..6f99f2562 100644 --- a/content/docs/2.15/concepts/scaling-jobs.md +++ b/content/docs/2.15/concepts/scaling-jobs.md @@ -233,7 +233,42 @@ For more details, you can refer to [this PR](https://github.com/kedacore/keda/p **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). +For example, let's assume we configure a ScaleJob in a cluster as below: +```yaml + ### + # A job that runs for a minimum of 3 hours. + ### + pollingInterval: 10 # Optional. Default: 30 seconds + maxReplicaCount: 10 # Optional. Default: 100 + triggers: + - type: rabbitmq + metadata: + queueName: woker_queue + hostFromEnv: RABBITMQ_URL + mode: QueueLength + value: "1" +``` +We send 3 messages to the Rabbitmq and wait longer enough than the `pollingInterval`, then send another 3. + +With the `default` scaling strategy, we are supposed to see the metrics changes in the following table: + +| | initial | incoming 3 messages | after poll | incoming 3 messages | after poll | +|-------------|---------|---------------------|------------|---------------------|------------| +| queueLength | 0 | 3 | 3 | 6 | 6 | +| runningJobs | 0 | 0 | 3 | 3 | 3 | + + +If we switch to `eager`, the result becomes: + +| | initial | incoming 3 messages | after poll | incoming 3 messages | after poll | +|-------------|---------|---------------------|------------|---------------------|------------| +| queueLength | 0 | 3 | 3 | 6 | 6 | +| runningJobs | 0 | 0 | 3 | 3 | 6 | + +We can identify the difference in their final states. + + +You may also refer to [this original issue](https://github.com/kedacore/keda/issues/5114) for more information. --- From 1e4ca05e7a15ec8e8f8d295236510bcb358d8cad Mon Sep 17 00:00:00 2001 From: June Han Date: Fri, 28 Jun 2024 16:54:05 +0900 Subject: [PATCH 3/3] chore: fix typo Signed-off-by: June Han --- content/docs/2.15/concepts/scaling-jobs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/2.15/concepts/scaling-jobs.md b/content/docs/2.15/concepts/scaling-jobs.md index 6f99f2562..e60370613 100644 --- a/content/docs/2.15/concepts/scaling-jobs.md +++ b/content/docs/2.15/concepts/scaling-jobs.md @@ -233,7 +233,7 @@ For more details, you can refer to [this PR](https://github.com/kedacore/keda/p **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. -For example, let's assume we configure a ScaleJob in a cluster as below: +For example, let's assume we configure a ScaledJob in a cluster as below: ```yaml ### # A job that runs for a minimum of 3 hours.