For the last couple of years we have run into issues where clients have found the DNN scheduler will run constantly or multiple schedule instances at one time. A couple years ago this was a huge issue as as Opt In Email would always pull in subscribers that were supposed to be sent newsletters and if the schedule kicked off 3 times the routine would run 3 times (very bad). We added in extra precautions to avoid this but even still, it was frustrating because we couldn't ever figure out why this was happening... We can control what happens after a scheduled instance of DNN runs but we can't control when DNN kicks off a scheduled instance. I started seeing this around DNN 4.8 but the more I researched the more I found it wasn't consistent between DNN versions etc...
So - Fast forward a couple years :)
What are the symptoms?
The symptoms are pretty easy to test. Take a look at your DNN scheduled tasks, find one that is supposed to run maybe every 30 minutes. Check the task 'history', is this task really running every 30 minutes? If so then you are good to go. If there is a problem what you will typically find is that the scheduler is kicking off multiple times and that the schedule history might be running every couple of minutes instead of when its supposed to run.
Solution?
I was on a support call recently with a customer and DNN Corp related to some issues they were having with the scheduler and learned from one of the developers (Patrick Santry) that the reason this can happen is if you setup multiple web applications/app pools within IIS for the same DNN site/directory. Basically DotNetNuke is designed to run as a single web application but with each portal alias defined under the web application. I think in IIS 6 this is under Web Site/Advanced/Identifies and in IIS7 this is under Bindings. I have also been told that this can happen if you have your application pool set to have more then 1 thread which is set under the application pool properties, performance, web garden, maximum number of worker processes. I think that there is a setting in the web.config related to maximum threads as well.
I thought this was very valuable information... Sometimes you might want to setup separate web applications to isolate a performance issue (with multiple application pools) or just for organization, but don't! :)
Hopefully someone finds this useful!
Thanks,
Chad