DefaultOptimalSizeExploringResizer
Related Doc:
package routing
Is it time for resizing.
Is it time for resizing. Typically implemented with modulo of nth message, but could be based on elapsed time or something else. The messageCounter starts with 0 for the initial resize and continues with 1 for the first message. Make sure to perform initial resize before first message (messageCounter == 0), because there is no guarantee that resize will be done when concurrent messages are in play.
CAUTION: this method is invoked from the thread which tries to send a message to the pool, i.e. the ActorRef.!() method, hence it may be called concurrently.
Report the messageCount as well as current routees so that the it can collect metrics.
Report the messageCount as well as current routees so that the it can collect metrics. Caution: this method is not thread safe.
Decide if the capacity of the router need to be changed.
Decide if the capacity of the router need to be changed. Will be invoked when isTimeForResize
returns true and no other resize is in progress.
Return the number of routees to add or remove. Negative value will remove that number of routees. Positive value will add that number of routees. 0 will not change the routees.
This method is invoked only in the context of the Router actor.
This resizer resizes the pool to an optimal size that provides the most message throughput.
This resizer works best when you expect the pool size to performance function to be a convex function.
For example, when you have a CPU bound tasks, the optimal size is bound to the number of CPU cores. When your task is IO bound, the optimal size is bound to optimal number of concurrent connections to that IO service - e.g. a 4 node elastic search cluster may handle 4-8 concurrent requests at optimal speed.
It achieves this by keeping track of message throughput at each pool size and performing the following three resizing operations (one at a time) periodically:
* Downsize if it hasn't seen all routees ever fully utilized for a period of time. * Explore to a random nearby pool size to try and collect throughput metrics. * Optimize to a nearby pool size with a better (than any other nearby sizes) throughput metrics.
When the pool is fully-utilized (i.e. all routees are busy), it randomly choose between exploring and optimizing. When the pool has not been fully-utilized for a period of time, it will downsize the pool to the last seen max utilization multiplied by a configurable ratio.
By constantly exploring and optimizing, the resizer will eventually walk to the optimal size and remain nearby. When the optimal size changes it will start walking towards the new one.
It keeps a performance log so it's stateful as well as having a larger memory footprint than the default Resizer. The memory usage is O(n) where n is the number of sizes you allow, i.e. upperBound - lowerBound.
For documentation about the parameters, see the reference.conf - akka.actor.deployment.default.optimal-size-exploring-resizer