4 ms·

This honestly sounds like a job for the BEAM (Erlang/Elixir). The preemptive scheduler would cover almost every need mentioned in the article.

• darwin67 3y ago
  Which part of BEAM are you talking about? I know some cases can be solved by it already, but not almost every need. The fairness of the BEAM scheduler is not the same as multi-tenant fairness. I'm aware of lcnt in Erlang that helps with contention, but that will have a hit in throughput like any other locks. Unless I'm missing something?
  • brightball 3y ago
    The way the BEAM scheduler works you get max runtime per process before it switches over to another, which lets you run potentially millions of concurrent processes without having to worry about 1 taking it over because it was heavier. Your big stuff takes longer, but your response times across the board will remain very consistent. If you wanted to make it truly fair you could spin up a GenServer per tenant and you would have a max concurrency per tenant of 1, but still all executing equally in parallel without 1 tenant stealing CPU time from the others. Contention is a non-issue. Fairness is built in. You get the fault tolerance, isolation and observability as a by product too. That's just my first reaction on reading it.
• clarkdave 3y ago
  Not sure if this is what you're getting at, but RabbitMQ is indeed pretty great at having thousands of queues, even on modest hardware, and can be used for per-tenant queues in this way. It does have some drawbacks though: if you have thousands of mirrored or quorum queues, managing the cluster becomes more cumbersome - it can take a while to replace nodes (rebalancing thousands of queues around). Also, the management tools (the web UI especially) don't perform that well if you have 10,000s of queues and 100,000s of consumers