Users supervision tree #175
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
NelsonVides
force-pushed
the
users/pool_supervision_tree
branch
from
d2554fa
to
bc98fd8
Compare
NelsonVides
force-pushed
the
controller/interarrival_of_zero
branch
from
433ef34
to
bd0690a
Compare
NelsonVides
force-pushed
the
users/pool_supervision_tree
branch
from
bc98fd8
to
9c4e2ce
Compare
NelsonVides
force-pushed
the
controller/interarrival_of_zero
branch
from
bd0690a
to
56da56b
Compare
NelsonVides
force-pushed
the
users/pool_supervision_tree
branch
from
1aa771e
to
9df2ea3
Compare
NelsonVides
changed the base branch from
controller/interarrival_of_zero
to
master
NelsonVides
force-pushed
the
users/pool_supervision_tree
branch
from
b663b82
to
58e461c
Compare
In the original implementation, the process is monitored by two supervisors, the original amoc_users_sup, and the amoc_controller one. But this means that bursts of ups and downs overflow the mailbox of _two_ processes, one of them being actually the very critical controller. With this reimplementation, only the amoc_users_sup tracks the processes, and all requests from the controller are asynchronous. This ensures the controller does not get blocked and can remain responsive to control requests.
Useful if for example we want to spawn a big pool of users all at once. Optimised by not setting any timers, but simply looping new user requests.
If users go up and down too fast, amoc_users_sup becomes a bottleneck as it can’t keep up with the requests. Improve the performance by creating a pool of supervisors whose size is proportional to the number of schedulers, and ensure distribution of users among them by for example hashing on the user_id. We do this by creating a pool of supervisors and having the whole API through `amoc_users_sup_sup` choose supervisors according to requests.
Have the user supervisors loop over the users start instead of the controller.
NelsonVides
force-pushed
the
users/pool_supervision_tree
branch
from
9578920
to
d775663
Compare
NelsonVides
force-pushed
the
users/pool_supervision_tree
branch
from
d775663
to
30e7646
Compare
NelsonVides
force-pushed
the
users/pool_supervision_tree
branch
from
30e7646
to
037dc05
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #175 +/- ##
==========================================
+ Coverage 73.44% 75.00% +1.55%
==========================================
Files 29 31 +2
Lines 1043 1160 +117
==========================================
+ Hits 766 870 +104
- Misses 277 290 +13 ☔ View full report in Codecov by Sentry. |
DenysGonchar
requested changes
Feb 18, 2024
There was a problem hiding this comment.
this new implementation sufferrs from the same issues as the existing one. removal operation is async and if we call amoc_controller:remove_users/2 two times in a row, it may select the same users for removal. so it won't remove the expected amount of users (the number returned by amoc_controller:remove_users/2). I don't think that we need to worry about it, but we must to add a note in the documentation about this behaviour.
src/users/amoc_user.erl
Outdated
| stop(Pid, false) when is_pid(Pid), Pid =/= self() -> | ||
| proc_lib:stop(Pid, shutdown, ?SHUTDOWN_TIMEOUT); | ||
| stop(Pid, true) when is_pid(Pid), Pid =/= self() -> | ||
| proc_lib:stop(Pid, kill, ?SHUTDOWN_TIMEOUT). |
There was a problem hiding this comment.
this implementation is not acceptable, we should never kill the user without giving it a chance to finalize its jobs. this interface must be based on some amoc_users_worker_sup API. The code must be unified, SHUTDOWN_TIMEOUT must be defined at amoc_users_worker_sup only.
NelsonVides
force-pushed
the
users/pool_supervision_tree
branch
5 times, most recently
from
7effd57
to
29d9ea2
Compare
NelsonVides
force-pushed
the
users/pool_supervision_tree
branch
2 times, most recently
from
b55455c
to
8ad85c5
Compare
NelsonVides
force-pushed
the
users/pool_supervision_tree
branch
from
c74f00f
to
11ffbba
Compare
NelsonVides
force-pushed
the
users/pool_supervision_tree
branch
from
f9c95c4
to
2d16cf7
Compare
NelsonVides
force-pushed
the
users/pool_supervision_tree
branch
from
2d16cf7
to
623a89f
Compare
DenysGonchar
approved these changes
Feb 21, 2024
This was referenced Feb 21, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Dedup controller and users sup #172
In the original implementation, the process is monitored by two supervisors, the original amoc_users_sup, and the amoc_controller one. But this means that bursts of ups and downs overflow the mailbox of two processes, one of them being actually the very critical controller.
With this reimplementation, only the amoc_users_sup tracks the processes, and all requests from the controller are asynchronous. This ensures the controller does not get blocked and can remain responsive to control requests.
Interarrival of zero #173
Useful if for example we want to spawn a big pool of users all at once. Optimised by not setting any timers, but simply looping new user requests.
Pool user supervision trees
If users go up and down too fast, amoc_users_sup becomes a bottleneck as it
can’t keep up with the requests. Improve the performance by creating a pool of
supervisors whose size is proportional to the number of schedulers, and ensure
distribution of users among them by for example hashing on the user_id.
We do this by creating a pool of
amoc_users_worker_supsupervisors and having the whole API throughamoc_users_supchoose supervisors according to requests.