Currently the storage WG is experiencing a rapid requirement to grow, and one of the limitations is the maximum number of workers. There are some other avenues of improving this already (such as allowing storage workers to increase the number of servers that they can run as one worker). Regardless, it seems like considering an increase to the maxWorkerNumberLimit is worth considering for the next runtime upgrade.
And although there are no current issues with the Distributor WG, it would seem prudent to also consider this WG along the same lines.
Solution
The current maxWorkerNumberLimit for both Storage + Distributors is 30
Increase it to 50? maybe even as high as 100?
I'm not sure what the scaling limitations are here, but it could be that some of the operations WGs have their maxWorkerNumberLimit decreased to balance this since those groups do not have distinct on-chain permissions like Storage + Distribution--they also have the option of paying non-workers using discretionary spending from their WG.
Problem
Currently the storage WG is experiencing a rapid requirement to grow, and one of the limitations is the maximum number of workers. There are some other avenues of improving this already (such as allowing storage workers to increase the number of servers that they can run as one worker). Regardless, it seems like considering an increase to the
maxWorkerNumberLimit
is worth considering for the next runtime upgrade. And although there are no current issues with the Distributor WG, it would seem prudent to also consider this WG along the same lines.Solution
maxWorkerNumberLimit
for both Storage + Distributors is30
maxWorkerNumberLimit
decreased to balance this since those groups do not have distinct on-chain permissions like Storage + Distribution--they also have the option of paying non-workers using discretionary spending from their WG.┆Issue is synchronized with this Asana task by Unito