You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pabot has a great feature of shards splitting, but currently does alphabetical order first, splits suites to shards and then orders the suites with ordering file per shard. However, this causes the ordering to be not preserved equally.
E. g.
ABCD -> 2 nodes, order by ACDB -> [AB],[CD] instead of [AC],[DB]. The more suites you have the worse it is. Unfortunately, this is a significant perf problem since you want to end up running all shards equally, which is currently not possible due to the behavior explained (each suite has different duration). This minor change should do the trick #558, but it is not clear to me why the current behavior is as it is and who might benefit that.
The text was updated successfully, but these errors were encountered:
The idea is that the shards should execute in the nearly in the same duration. That way all the shards should complete in the fastest combined execution time.
So it picks the shortest test and the longest test into the same pairing.
Pabot has a great feature of shards splitting, but currently does alphabetical order first, splits suites to shards and then orders the suites with ordering file per shard. However, this causes the ordering to be not preserved equally.
E. g.
ABCD -> 2 nodes, order by ACDB -> [AB],[CD] instead of [AC],[DB]. The more suites you have the worse it is. Unfortunately, this is a significant perf problem since you want to end up running all shards equally, which is currently not possible due to the behavior explained (each suite has different duration). This minor change should do the trick #558, but it is not clear to me why the current behavior is as it is and who might benefit that.
The text was updated successfully, but these errors were encountered: