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
Every operation on applications that demand the (re-)creation of units (deploy, restart, start, env-set, env-unset) will start 1 goroutine for each unit.
This is a problem depending on the number of existing units in an application, in some tests we were able to starve the api process when deploying 300+ units due to the high number of threads (one for each goroutine due to being blocked on I/O).
A solution for this problem is having a maximum number of goroutines running in a pool and using channels to send workloads to them.
The text was updated successfully, but these errors were encountered:
When using numbers like 1000 containers, we do have some issues with it.
We're now introducing a setting for customizing the maximum amount of
woekrs. This isn't a pure "worker" architecture, as some workers may
work harder than others, because we just split the work across then
equally.
Related to #1149. unit-add doesn't use this code, and I also need to
document it.
Every operation on applications that demand the (re-)creation of units (deploy, restart, start, env-set, env-unset) will start 1 goroutine for each unit.
This is a problem depending on the number of existing units in an application, in some tests we were able to starve the api process when deploying 300+ units due to the high number of threads (one for each goroutine due to being blocked on I/O).
A solution for this problem is having a maximum number of goroutines running in a pool and using channels to send workloads to them.
The text was updated successfully, but these errors were encountered: