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
Mite's current job scheduling model is based on maintaining a certain number of jobs active at once. This means that our jobs need to have sleeps in them (boilerplate); it also means that there is no good way to schedule a very-occasional request without a long sleep (which causes problems for the controller teardown). We also model the work that runners are doing by the number of jobs scheduled on them. A job that is sleeping doesn't represent load in the same way that a job doing network I/O does (even though both are in an identical "waiting" state, one consumes network resources and the other doesn't). That means that our distribution of work across runners won't be optimal.
We should also support a job scheduling model that gives an interval over which jobs should run (each second, run 5 of this journey). The advantage to this model is that it generalizes easily to occasional journeys (every sixty seconds, run one copy of this journey) and one-shot jobs (at 1:00 into the test, run this journey). I think we can do this, on the controller end, with a token-bucket model: for each journey, we have an asyncio queue. One coroutine in a forever-loop does { deposit N tokens; sleep M seconds }. Another blocks on the queue, and whenever it can take tokens out, kicks off the jobs. The existing model might be adaptable into this framework as well: instead of depositing tokens on a time basis, we'd deposit them back into the bucket when the job completed.
The text was updated successfully, but these errors were encountered:
Mite's current job scheduling model is based on maintaining a certain number of jobs active at once. This means that our jobs need to have sleeps in them (boilerplate); it also means that there is no good way to schedule a very-occasional request without a long sleep (which causes problems for the controller teardown). We also model the work that runners are doing by the number of jobs scheduled on them. A job that is sleeping doesn't represent load in the same way that a job doing network I/O does (even though both are in an identical "waiting" state, one consumes network resources and the other doesn't). That means that our distribution of work across runners won't be optimal.
We should also support a job scheduling model that gives an interval over which jobs should run (each second, run 5 of this journey). The advantage to this model is that it generalizes easily to occasional journeys (every sixty seconds, run one copy of this journey) and one-shot jobs (at 1:00 into the test, run this journey). I think we can do this, on the controller end, with a token-bucket model: for each journey, we have an asyncio queue. One coroutine in a forever-loop does { deposit N tokens; sleep M seconds }. Another blocks on the queue, and whenever it can take tokens out, kicks off the jobs. The existing model might be adaptable into this framework as well: instead of depositing tokens on a time basis, we'd deposit them back into the bucket when the job completed.
The text was updated successfully, but these errors were encountered: