Hi Nathaniel ... Let me share my thoughts regarding your response
It sounds like a more precise description of your scheduler would be "hierarchical FIFO"? i.e., there's a top-level scheduler that selects between "child" schedulers in round-robin/FIFO fashion, and each child scheduler is round-robin/FIFO within its schedulable entities? [1] Generally I would think of a "fair" scheduler as one that notices when e.g. one task is blocking the event loop for a long time when it runs, and penalizing it by not letting it run as often.
Agree with the controversial meaning of fair scheduling, I would rename my title as Fair Queuing [1]. Regarding your notes, pretty interesting, and your thoughts about how the current lack could be tackled in the near future. But, I would say that these notes are more about flow control at the network level, where mine was more oriented on business logic. I'm more inclined to think that both works at different level and different granularity, and are not excluding. The draft that I presented is keen on allow the user - in a way of pattern - to split and isolate resources from top to bottom. Yes, I was thinking about different strategies that might give more granularity and fine control to the user such as weighted partitions, or even have just two queues LOW and HIGH. But these last ones didn't appeal to me for the following reasons: - Give to the user the chance to mix partitions and weights might end up having some code difficult to understand. - The LOW and HIGH priority was too much restrictive. Give control to the user to configure what is LOW and what is HIGH might end up also having an overall performance worst than it was expected. The idea behind the Fair queuing is: Give enough control to the user but without taking the chance to screw up the whole thing.
But also... isn't part of the point of a healthcheck that it *should* get slow if the system is overloaded?
Not really, the response of a health-check is dichotomic: Yes or No. The problem on sharing resources between the health-check and the user flow is when the last one impacts on the first one having, as a result, false negatives. The dynamic allocation of resources to scale up horizontally to suit more traffic and reduce the pressure to the main flow is run by other actors, that of course can rely on metrics that are sent out by the user flow. [1] https://en.wikipedia.org/wiki/Fair_queuing -- --pau