perf: DDataShardCoordinator stashed GetShardHome handling #32743
Conversation
akka-cluster-sharding/src/main/scala/akka/cluster/sharding/ShardCoordinator.scala
Outdated
Show resolved
Hide resolved
akka-cluster-sharding/src/main/scala/akka/cluster/sharding/ShardCoordinator.scala
Outdated
Show resolved
Hide resolved
| @@ -1848,13 +1850,29 @@ private[akka] class DDataShardCoordinator( | |||
| override protected def unstashOneGetShardHomeRequest(): Unit = { | |||
| if (getShardHomeRequests.nonEmpty) { | |||
| // unstash one, will continue unstash of next after receive GetShardHome or update completed | |||
| val requestTuple = getShardHomeRequests.head | |||
| val requestTuple = { | |||
There was a problem hiding this comment.
Could capture both nicely val requestTuple @ (ref, _) = ... instead of having to use the _1 syntax which is less clear.
…d to no-op" This reverts commit ce7ffd6.
|
Wondering if it makes sense to make the stash even better prioritized... with this it will probabilistically tend to choose the shard with the greatest demand from the regions, but maybe better to have parallel stashes for self-generated and from-region |
|
Added the refactor to more deterministically choose the next shard to allocate in response to a GetShardHome (deterministic when there is a unique shard with maximum number of regions demanding its home; otherwise it will choose (in iteration order) one of the shards with said maximum). Iterating through when unstashing should be OK: even if there are many shards with requests with none having requests from multiple shard regions, the time spent iterating pales in comparison to the time waiting for ddata to update, and as soon as we get a second request for an unallocated shard (which it's reasonable to expect is more likely the longer this takes) we can immediately handle all requests for that shard (which is a win). |
|
relevant to #30315 |
Two optimizations intended to reduce latency for shard allocation dissemination:
GetShardHomes for that shard by unstashing them firstGetShardHomes, prefer ones that have demand fromShardRegions (and thus buffered messages)