DotNetNuke Scheduler Explained 

I have found that many people that work with DotNetNuke sites are often unfamiliar with the various scheduled tasks that are implemented within DotNetNuke.  Is this a bad thing?  It depends, by default the configuration of scheduled tasks will work just fine, but as your site grows there are specific tasks that can become problematic due to the size of the site, resulting in increased resources being used or worse site failure/errors.  This article will discuss each of the default tasks that are included in DotNetNuke, I will describe the function of each and discuss the default schedule and when you should change the schedule.

DotNetNuke.Entities.Users.PurgeUsersOnline

This task is one that is used by the Users Online module within DotNetNuke.  When this task executes it will remove users from the listing of online users that are no longer active in your site.  When using this module the time frequency for this module is something that you want to take into careful consideration, more details will be discussed in the "When to change" section

Standard Schedule

By default this task is NOT ENABLED by DotNetNuke, if you enable users online it will execute every 1 minute to purge the users

When to Change

Typically the default values for this functionality is ok if you are using the module, if you run an incredibly high activity site though you might consider adjusting this to run every 5 minutes or so, just to reduce the minimal load that it does add to your site

DotNetNuke.Services.Log.SiteLog.PurgeSiteLog

This task if it is enabled will purge the records in the site log that are older than the specified history time.  This task is highly important as when using the site log this will prevent the log table from growing too large

Standard Schedule

By default this task is NOT ENABLED by DotNetNuke, if you enable this task the default run frequency is once per day.

When to Change

This task is one that by the nature of how it works is best to leave at a 1 per day schedule as it only cleans records based on a daily basis

DotNetNuke.Services.Scheduling.PurgeScheduleHistory

This task is used to purge records from the Schedule History table.  This is an important task because if your schedule history is left alone it is very possible for your database size to grow in a very rapid manner due to the sheer number of items that are completed by the scheduler.

Standard Schedule

By default this task is ENABLED by DotNetNuke and will execute once per day.

When to Change

This is another task that due to the nature of the action it performs changes to the schedule are not needed

DotNetNuke.Services.Log.EventLog.PurgeLogBuffer

This task is used to purge records from the Event Log queue to the database.  This is an important feature of DotNetNuke as this task is what ensures that all actions are successfully recorded to the EventLog table.

Standard Schedule

By default this task is ENABLED by DotNetNuke and will execute once per minute

When to Change

You can modify this task to run less frequently on a highly active site and it might have minimal performance modifications.  For example if it runs every minute and takes 5 seconds, you could schedule it to run every 5 minutes and it would take 25 seconds.  However, in my experience with DotNetNuke it is not ever necessary to modify this task.

DotNetNuke.Services.Log.EventLog.SendLogNotifications

This task is responsible for sending e-mail notifications to the administrator from the event log system. 

Standard Schedule

By default this task is NOT ENABLED by DotnetNuke, if enabled it will execute once every 5 minutes by default. 

When to Change

Due to the nature of urgent updates to the administrator, if this task is enabled I would not recommend changing the interval.

DotNetNuke.Services.Search.SearchEngineScheduler

This task is responsible for the population of the search engine within DotNetNuke.  When this task is executed all modules that support ISearchable will be polled for index information and if any exists it will be added to the search index.

Standard Schedule

By default this task is ENABLED by DotNetNuke and will execute once every 30 minutes

When to Change

This task is typically the one that causes the most problems.  Due to the nature of the search engine and how it queries modules for information it can take an INCREDIBLY long time for this code to run on large DNN sites (I have noticed times of over 15 hours for some clients).  Therefore if you have a large site you might want to change this for two reasons.

The first being the additional errors that will be thrown if the process runs for more than 30 minutes.  If the scheduler is still executing the index process when it tries to start again a "cannot insert duplicate key" error will be encountered.  This adds to the number of entries in your event log and is an overall bad practice.

The second being the server resources that are being used.  The search indexing process is very database intensive and depending on your setup could cause noticable performance reductions to your visitng clients.  If you can get away with it I would highly recommend having this run no more than once per 6-8 hours.  If you have a more active site you can leave it as is, however, keep an eye on your event log for errors.

DotNetNuke.Modules.Admin.ResourceInstaller.InstallResources

This task is responsible for the automatic installation of modules that have been placed in the various /Install folders in your DotNetNuke installation.

Standard Schedule

By default this task is NOT ENABLED by DotnetNuke, if enabled it will execute once every 30 minutes by default.

When to Change

You can enable this task if you want to automatically install modules, however, I personally recommend NOT using this feature

DotNetNuke.Services.FileSystem.SynchronizeFileSystem

This task is responsible for updating the File Manager by syncronizing the DNN file system with your physical file system.  This is needed if you add many files to your site via FTP and not using one of the "DNN ways" of uploading

Standard Schedule

By default this task is NOT ENABLED by DotnetNuke, if enabled it will execute once every hour by default.

When to Change

If you use FTP to upload files to your /Portals/<portalId> folder you might enable this option, however, I personally recommend just using the "Recursive" sync option within file manager whenever I have an issue.  My reasons for this are that if you have a large number of files, this task can take a very long time to execute.

DotNetNuke.Services.Cache.PurgeCache

This scheduled task is responsible for purging cache files from the hard drive when using the "Disk" method of caching.  If you are using the "Disk" caching method this is a key scheduled task.

Standard Schedule

By default this task is ENABLED by DotNetNuke and will execute once per 2 hours.

When to Change

You can disable this task if you are working with "Memory" caching (which I highly recommend).

Disclaimer/Conclusion

This guide has been provided as a quick reference to explain some of the "default" scheduled tasks that are available to you in DotNetNuke.  It is your responsibility to determine which tasks if any need to be modified from the default configuration.  Without a detailed look at the entire DNN solution it is impossible to provide a blanket set of "rules" for setting scheduled tasks.  If you have any specific questions about this article please ask them below, if you need techical assistance please visit my forum for assistance.

Posted by Mitchel on Wednesday, February 13, 2008
 

Comments

Good article covers a lot.
You might want to add the Host->Other Setting -> "Scheduler Mode" choices.

I forget who recommend that I change to "Timer Mode"

Another article in the same area that you might want to consider is how to setup the "Event Log Setting" so that you get a reasonable mix of troubleshooting info and also have a self-managed log size.

I have always been amazed that DNN's defaults in these area will get the novice into trouble.

/Dave Snow

By Dave Snow on Thursday, February 14, 2008 at 12:53 PM

Just wanted to clarify something about DotNetNuke.Services.Log.EventLog.PurgeLogBuffer. From my understanding this task takes the event log entries from memory and writes them to the database. This, it is only needed if "Host Settings > Advanced Settings > Other Settings > Enable Event Log Buffer?" is checked. In recent versions of DNN, this setting has not been checked and the PurgeLogBuffer scheduled task has been disabled. Hope this helps!

By Spence Hackney on Friday, February 29, 2008 at 3:23 AM

Spence,

That is a very valid point, I forgot that I tweaked the log settings on my default installation thus it was enabled on that site.

By mitchel.sellers@gmail.com on Friday, February 29, 2008 at 3:45 AM

Thanks.
As Dave says. I could use some extra info about the Time/Request option for the scheduler on the host settings. Any tips?

By Jaap on Thursday, March 13, 2008 at 12:23 AM

Long story short, I recommend the timer method as it uses a separate thread to handle operations...I'll get a detailed tutorial up soon!

By mitchel.sellers@gmail.com on Thursday, March 13, 2008 at 2:39 AM

I'm also keen to know more about the timer mode - my portal freezes up when I switch to it and the only way to get it back is to change the mode back in the database.

By Rob on Friday, August 29, 2008 at 3:36 AM

Hi Mitch,

Great post as usual - are you 100% sure that the PurgeCache task is nothing to do with MEmoryCaching? I assumed it was the task that checked the expiry times on cached items and deleted them, but perhaps the core .NET framework does this automatically...

By Rodney Joyce on Tuesday, November 04, 2008 at 2:09 PM

Rodney,

Yes I am quite sure, I remember checking it back in the day, but I also verified that I am not running that service on ANY dnn installs that I manage. With no negative effects.

By mitchel.sellers@gmail.com on Tuesday, November 04, 2008 at 2:15 PM

Thanks for the clear descritpion of all this schedular things.
One question:
About the ResourceInstaller... You personally recommend not using this feature. Could you explain why?

By Anton Maters on Monday, November 17, 2008 at 5:52 AM

Anton,

I do not like anything installing items for me without me acutally doing the installation....thus why I don't enable it.

By mitchel.sellers@gmail.com on Monday, November 17, 2008 at 6:26 AM

Hello ! Can any one help me out???

What is the purpose of PurgeCache()????
what this method do????

By Raheel Shahid on Tuesday, November 18, 2008 at 12:14 AM

This is explained in the article, it purges disk based cache files when needed.

By mitchel.sellers@gmail.com on Tuesday, November 18, 2008 at 3:45 AM
Click here to post a comment

Donate

Show your appreciation for the content/modules made available by MitchelSellers.com by making a donation. Donations are used to assist with dedicating time to creating free content.