How many System.Timers.Timer instances can I create? How far can I scale?

Question

I have an application which makes use of System.Timers.Timer objects to do expirations and email notifications and such. Currently the system has a couple hundred timers al

Answer 1

You should be fine using a lot of them. But like pdiddy says, you really should consider changing your code, if you can. 1 vs 10.000 timers makes a difference. ;-)

Answer 2

How about using only one timer? The timer will expired on the first expiration and do the appropriate logic upon expiration. Then reset it's interval to the next expiration? Just maybe another way to handle expiration using only one timer.

Answer 3

A little late on this, I know, but . . .

System.Timers.Timer is a wrapper around System.Threading.Timer, which in turn is a .NET wrapper around Windows' Timer Queues. Timer queue timers are very lightweight--use few system resources. I've not scaled to thousands of timers, but hundreds of timers works just fine. From what little I've been able to glean of the implementation, I can't imagine that there would be any trouble with thousands of timers.

There's probably some limit on the number of timers you can have in any particular timer queue. I don't know what that limit is. When I investigated these timers a year or so ago, it looked like the .NET Framework creates one timer queue per process (or maybe it was per app domain), and all the timers you create are put into that one queue.

It probably doesn't make sense to duplicate the timer queue functionality by creating your own system that uses a single timer and some type of priority queue mechanism to control what's called next. That's what the timer queue does for you already.

It seems like you could easily build a test program that creates 10,000 timers. Set each one to tick one second after the last, and set its period to 10,000 seconds. Then sit back and watch it tick. Or have your program keep track of who should tick next and who actually ticks next.