December 30, 2015

DNN/Evoq Scheduler: Setting Expectations

One of the fundamental features of the DNN/Evoq platform is the the internal "Scheduler" system.  Creating a Scheduled Job is an easy process, and something I have blogged about in the past.  However, I have been seeing more questions recently around what exactly is meant by the "5 Minute" Interval or other settings regarding the scheduler jobs.  The root cause is the differences in expectations versus what is possible.

Expectations

Developers and site administrators alike see the scheduler options for frequency, such as every 5 minutes, as absolutes.  The scheduler interface also helps encourage this by showing "Next Execution Time" values with a 100% absolute time set, all the way down to the millisecond.  This isn't necessarily an unjust expectation, as we have other solutions that result in this level of frequency.  You can schedule jobs within Windows to run on absolute frequencies, or you can create a windows service and expect that things work as you set them

Reality

The reality is that the DNN Scheduler system is going to take the best efforts to execute your jobs at the proper time.  However, there are certain circumstances that can impact the scheduler.  The default configuration for current release Evoq/DNN is to use the "Timer" mode for the scheduler.  (Those on older versions should ensure that they are also running in this mode.)  The timer mode is implemented using a background thread what is started for the Scheduler when the DNN application starts.  This works well, and most of the times the jobs will execute at the proper time.  However, there are two situations that can cause major discrepancies in execution.

Application Shutdown

The most common cause for the scheduler to seem "unreliable" would be situations where the application shuts down due to in-activity.  This is common for those lower traffic sites, or the situations where you might be working on a development or staging server.  Given that the thread is part of the worker process, if the application shuts down it will no longer be able to execute the jobs.  If you have jobs that are important to execute on a set schedule, you might consider using a keep-alive service, or other means to prevent the application from shutting down.  

Long Running Jobs

The other common situation that I encounter is a situation where the scheduler system is held back due to the number of threads and the length of time that a job takes to execute.  By default the DNN Scheduler will use one thread, if a job executes and takes a long time, it can delay processing of other jobs.  Normally this is not a big deal as your standard job executes in less than 60 seconds, but longer running jobs are possible, such as the Search Indexer.  To work around this situation you can look at allowing an additional thread, or focusing on optimizing your job execution.

Conclusion

The DNN/Evoq scheduler is a great feature.  But it is something that when used for "business critical" items, a better understanding of how it works is important to ensure that nothing slips through the cracks.

tags: DNN, DNN Administration, DNN Development
comments powered by Disqus

Content provided in this blog is provided "AS-IS" and the information should be used at your own discretion.  The thoughts and opinions expressed are the personal thoughts of Mitchel Sellers and do not reflect the opinions of his employer.

Content Copyright

Content in this blog is copyright protected.  Re-publishing on other websites is allowed as long as proper credit and backlink to the article is provided.  Any other re-publishing or distribution of this content is prohibited without written permission from Mitchel Sellers.