-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add determinism #145
base: main
Are you sure you want to change the base?
Add determinism #145
Conversation
By queuing requests per host we now provide deterministic behavior of calls. Signed-off-by: Jacob Weinstock <jakobweinstock@gmail.com>
Version was old. Signed-off-by: Jacob Weinstock <jakobweinstock@gmail.com>
Fixes issue where the task is not found. This was happening because I was creating the record in the DB in a goroutine and mocking the action to immediately fail. This caused the worker to complete and close before any record could be created. Signed-off-by: Jacob Weinstock <jakobweinstock@gmail.com>
Codecov Report
@@ Coverage Diff @@
## main #145 +/- ##
==========================================
- Coverage 81.33% 79.38% -1.95%
==========================================
Files 9 11 +2
Lines 466 587 +121
==========================================
+ Hits 379 466 +87
- Misses 74 104 +30
- Partials 13 17 +4
... and 1 file with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Signed-off-by: Jacob Weinstock <jakobweinstock@gmail.com>
Signed-off-by: Jacob Weinstock <jakobweinstock@gmail.com>
Signed-off-by: Jacob Weinstock <jakobweinstock@gmail.com>
Signed-off-by: Jacob Weinstock <jakobweinstock@gmail.com>
The goroutine (in worker) dequeuing tasks was a blocking call. This meant that after there were no tasks in the queue, this dequeue call would sit waiting. This meant that when the rest of the worker exited this goroutine did not and was orphaned. Workers are per host id so depending on unique hosts that requested tasks this would grown and stay at that number. The resolution was to make the dequeue call non-blocking. Signed-off-by: Jacob Weinstock <jakobweinstock@gmail.com>
Signed-off-by: Jacob Weinstock <jakobweinstock@gmail.com>
Signed-off-by: Jacob Weinstock <jakobweinstock@gmail.com>
Plumb these through to the cli flags. Also fixed a channel close so that when workers are done the goruntimes drops back down to original levels. Signed-off-by: Jacob Weinstock <jakobweinstock@gmail.com>
Signed-off-by: Jacob Weinstock <jakobweinstock@gmail.com>
The ingestor was single threaded. After adding metrics and watching the queues and processing happen, running the ingestor process with a max goroutine cap yielded better performance. The per ID queues filled up faster and allowed processing of BMC interactions faster. Signed-off-by: Jacob Weinstock <jakobweinstock@gmail.com>
Signed-off-by: Jacob Weinstock <jakobweinstock@gmail.com>
This keeps the goroutines from growning uncontrollably. Signed-off-by: Jacob Weinstock <jakobweinstock@gmail.com>
This made processing significantly faster. Signed-off-by: Jacob Weinstock <jakobweinstock@gmail.com>
Update the metric server to handle slow loris attacks. Signed-off-by: Jacob Weinstock <jakobweinstock@gmail.com>
It was too big and made memory consumption way too high. Also, the typical/general use-case will be high number of hosts and low number of tasks that are requested close together. Signed-off-by: Jacob Weinstock <jakobweinstock@gmail.com>
@jacobweinstock curious if you intend to have these changes merged? |
Hey @joelrebel , It's on my list. I don't know if i'll get to it anytime soon though :( |
Description
Add deterministic behavior for calls against a single host. By queuing requests per host we now provide deterministic behavior of calls.
Why is this needed
Fixes: #130
How Has This Been Tested?
How are existing users impacted? What migration steps/scripts do we need?
Checklist:
I have: