Question

In this Node app I'm working on, it's possible for users to book appointments. When an appointment is booked, the users will later get a reminder by mail X hours before the actual appointment.

I'm thinking about using Node-schedule for this task.

For each appointment: Set up a future Date, send the reminder mail once and the delete this particular scheduled job

But... there might be ALOT of appointments booked when the app grows, and this means there will be ALOT of Node-schedule processes simultaneously sleeping and waiting to fire...

On a regular day, lets pretend we have 180 appointments booked for the future per clients, and lets pretend the app right now has 50 clients. This gives us around 9000 scheduled tasks sleeping and waiting to fire.

Question: Is this perfectly OK? ... or will all these simultaneously scheduled task be to much/many?

Was it helpful?

Solution

Short answer: 9000 is not a lot, you're good to go. However, I would advise you to write a benchmark to see for yourself.

I checked node-schedule's source and sure enough, it delegates scheduling to setTimeout for date-based tasks. This means that your jobs are scheduled using node.js internal event loop.

This code is very efficient, as node.js is tailored to handle several thousands of requests simultaneously.

Regardless of the number of pending jobs, node.js will only care about the next task and sleep until its date (unless an async I/O interrupts it), so scheduling a task is essentially O(1).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top