8

For my webapp I'm going to need to have many timeouts running at once at any given point, possibly around 10,000-100,000. What I'm wondering is how well this function scales.

I don't need it to be that accurate, mostly accurate within 10-100 ms. Would it be better to have a single function run on an interval (say, to run every 50 ms), that checks the current datetime compared to the saved datetime and invokes the function if so?

Does anyone have any insight in to the underlying implement of setTimeout and can shed some light as to how well it can be used en-masse?

More questions I had: Does anyone know of a limit to how many timeouts can be running at once? Also, with both approaches I'm concerned about there not being enough time to process each timeout per interval and it getting "behind" in terms of triggering the timeout function in time.

Lawrence Douglas
  • 667
  • 1
  • 7
  • 15
  • There's a great article ( Although not exactly written with node.js in mind ) by John Resig which I really liked: http://ejohn.org/blog/how-javascript-timers-work/ – elad.chen Jun 26 '16 at 07:11
  • 1
    It depends on whether the persistence needed. Looks you need scheduler level solution like this: https://github.com/rschmukler/agenda P.S. About limit: http://stackoverflow.com/a/12173835/4989460 – stdob-- Jun 26 '16 at 08:20
  • "Does anyone know of a limit to how many timeouts can be running at once? " --- 1. – zerkms Jun 26 '16 at 08:43
  • As with all performance issues, the key is to test it yourself under your load and doing your processing. There is no one silver bullet answer to this except, "load test it" – Liam Jan 19 '22 at 16:16
  • *Does anyone have any insight in to the underlying implement of setTimeout* The only [hard facts would be whatever the spec says](https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html). Beyond that the Js engine is open to interpretation – Liam Jan 19 '22 at 16:17

2 Answers2

1

Actually you cannot determine the exact interval between timeouts, because all it does is it pushes your callback to the callback queue after the threshold and when the event loop will get that callback, push to the call stack and execute it - is non-deterministic. The same is with intervals. You may appear in a situation, when, for example, 5 callbacks will be executed one after another without a delay. This is javascript ))

David Gabrielyan
  • 227
  • 2
  • 12
0

This is too long for a comment.

possibly around 10,000-100,000

Let's consider what this means. Say that each queued callback takes ~10ms to run, and you queue up 50,000 of them to run in 50ms. Only one of them can run at a time. So by the time the event loop even checks to see if it's time to run the 1000th callback, 10 whole seconds have passed. By the time you get to the 50,000th callback it will have been ten whole minutes! Now obviously if your queued callbacks take fractions of a millisecond that two order-of-magnitude dropoff makes the math a little less dismal, but if they have to do any I/O this probably isn't going to work and it probably won't work no matter what, at least not for a webapp that also has to serve clients.

Jared Smith
  • 19,721
  • 5
  • 45
  • 83
  • This is all guess work. Really you have no idea if this is true or not. – Liam Jan 19 '22 at 16:15
  • @Liam yes, I know, which is why I opened with "this is too long for a comment", otherwise I would have just posted it as a comment. – Jared Smith Jan 19 '22 at 16:16