Before I begin, I know this can be handled in different ways, e.g., invoking an external script with a low CPU priority, or spinning up a separate server or even using AWS Lambda (or equivalent). I’m interested in this more from a hypothetical standpoint. I’m also aware that fibers don’t block the event queue.
Let’s say I have a Meteor call which takes a “long” time to run, for example 35-45 seconds. The user needs to be told when the method completes (if they are still online), but it doesn’t really matter how long it takes, it could take 30 seconds uninterrupted, or it could be delayed by upto 5 minutes if required.
Could one use Fiber.yield/run to frequently pause and resume a fiber and thus ensure responsiveness of other meteor methods being executed on the same server.
A use case here would be a server is running at ~50% CPU, still responsive, but then a user kicks off a job that is not time critical, but if left to run alone would push the CPU to 95/100% CPU, at which point all other users would notice their pages become less responsive. I ask because 99% of the time our CPU load is < 25%, but occasionally it spikes to around 60% when one of these jobs starts, 60% is fine, but if lots of people trigger jobs like this at the same time, it would cause trouble.
I’m thinking of a package that allows a Meteor method to “queue” up a non time-sensitive job and the server would pause and resume jobs to maintain a target CPU load, e.g., > 60% pause all jobs, < 60% start resuming jobs. It could then also consider the user who is logged in (e.g., a payed users job would get paused last.
- Are there already packages which accomplish this?
- Am I worrying about nothing? How un-responsive does an app that is running at 99% CPU (i.e., not quite full capacity, but really close) become, in the case where all the CPU usage is coming from fibers?