CODEWITHSUNDEEP
javascriptnode.jsmongodbsettimeoutpolling
mitmath514
mitmath514

Reputation: 427

Is polling a better option than setting multiple setTimeout()

I'm developing an email reminder system to ping users 24, 8, 3, and 1 hour before a task is due.

I have a server that runs on Node.js. My first idea was to set four separate setTimeout() each time a user is assigned a task. However, I assume that having hundreds of setTimeout() idling on a server wouldn't be best performance-wise.

As such, would I be better off polling for incomplete tasks every five minutes and sending reminders to users who have tasks with approaching deadlines? The downside here is that I would be reading an entire MongoDB collection every five minutes.

Upvotes: 3

Views: 233

Answers (1)

jfriend00
jfriend00

Reputation: 707836

Nodejs is very efficient with lots and lots of timers. You can easily have tens of thousands of timers with no meaningful ramifications. It uses a sorted, linked list that takes only a tiny amount of time to insert a new timer and costs nothing once inserted.

Only the next timer to fire at the start of the list is regularly compared in the event loop. When it fires, it's removed from the front of the linked list and the next timer in the list is now at the head. Because it's a linked list, the time to fire a timer and remove it from the start of the linked list is independent of how long the list is (e.g. it's not an array that has to be copied down).

So, for your specific application, it is far, far more important to be efficient with your database (as few requests as possible) than it is to minimize the number of timers. So, whichever timer design/implementation optimizes your database load is what I would recommend.

FYI, if you want to remind a user 4 times about an approaching due task, you can still only have one timer live at a time per task. Set the first timer to fire, then when it fires to notify, you do a little time calculation on the due date/time that you previously saved and see when to set the next timer for. That would leave you with just one timer per task rather than four.

But, the main point here is still that you should first optimize the design for efficient use of the database.

And, timers are not persistent so if your server restarts, you need a mechanism for recreating the appropriate timers upon server startup (probably a database query that provides you any tasks pending within a certain time).

Upvotes: 3

Related Questions