Add explanation for eagerScalingStrategy

content/docs/2.15/concepts/scaling-jobs.md

@@ -18,6 +18,69 @@ For example, if you wanted to use KEDA to run a job for each message that lands
 1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.
 1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.`
 
+Select a Scaling Strategy. Possible values are `default`, `custom`, `accurate`, or `eager`. The default value is `default`.
+
+```yaml
+customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.
+customScalingRunningJobPercentage: "0.5"  # Optional. A parameter to optimize custom ScalingStrategy.
+```
+
+_The number of the scale_
+
+```go
+min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)
+```
+
+**accurate** 
+If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.
+
+```go
+if (maxScale + runningJobCount) > maxReplicaCount {
+		return maxReplicaCount - runningJobCount
+	}
+	return maxScale - pendingJobCount
+```
+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.
+
+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.
+  ###
+  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.
 
 # Pausing autoscaling
 
@@ -28,6 +91,9 @@ This is preferable to deleting the resource because it removes the instances it
 You can pause autoscaling by adding this annotation to your `ScaledJob` definition:
 
 ```yaml
+scalingStrategy:
+    multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.
+=======
 metadata:
   annotations:
     autoscaling.keda.sh/paused: true
@@ -41,7 +107,6 @@ metadata:
     autoscaling.keda.sh/paused: false
 ```
 
-
 ## Example
 
 An example configuration for autoscaling jobs using a RabbitMQ scaler is given below.