Simple DotNetNuke Performance Improvements 

I have been seeing a large number of questions recently regarding DotNetNuke performance and things that can be done to help improve the performance of the site.  Typically these questions surround the SiteLog and EventLog tables so I thought I would post a few simple queries that you can run to help keep your database lean which will keep your DotNetNuke site running at peak performance.

Site Log

I will start with the Site Log table, the site log functionality is not one that I actually utilize in my site, however for those of you who use it in yours you will want to keep an eye on it, I have noticed that after the log has grown to over about 4-5 thousand records that you can start to notice some performance decreases. Additionally if you are like myself and have turned off the site log I found out that it does not necessarily clean itself up if you turned it off, therefore in my case I had 1000 lingering records, which just unnecessarily increased the size of my database.

To check the number of records in your Site Log use the following query

SELECT Count(*)
FROM SiteLog

To find the oldest record in the site log use the following.

SELECT MIN([DateTime])
FROM SiteLog

After you have viewed this information you can determine your needed course of action. In my case since the site log is disabled on all portals I simply deleted all records from the table using a simple delete statement. In your case you might only want to purge specific records but that determination is outside the scope of this article.

Event Log

The Event log stores portal specific event information such as logins, invalid login attempts and actual errors. If you have a fairly active portal this table can grow very large quite quickly. For my sites with their traffic of about 100-120 visitors per day I have noticed an EventLog of over 2000 records in a 2.5 month period. Now unless you are auditing logins or doing specific tracking you can typically rid yourself of these records without much effect. You can purge these portal by portal via the "Event Viewer" within DotNetNuke, or you can view and modify records via the database. Below I will provide you two helpful queries.

To identify the number of records, and the number of records per portal. Note, in the results of the per portal query, you will find many entries listed with a NULL portal id, this is for DNN installation wide items, such as scheduler and application events.

--Overall total
SELECT COUNT(*)
FROM EventLog

--Total by portal (null is not portal specific)
SELECT LogPortalId, COUNT(*)
FROM EventLog
GROUP BY logPortalId

To identify the oldest records you can use one of the following queries, again an overall minimum and a per portal minimum will be found.

SELECT MIN(LogCreateDate)
FROM EventLog

SELECT LogPortalId, MIN(LogCreateDate)
FROM EventLog
GROUP BY logPortalId

Again for deleting these records the decision really depends on your portals use of the Event Log and any need for user login auditing. In my case I again do not need this information and currently I have resolved all of my routine errors that were happening, therefore I removed all records in my listing across all sites. I try to complete this at least once as month to ensure that the table size has been reduced.

Viewing DB Size

If you would like to view the size of your database files you can use the query below to view the size of each file for the current database.

SELECT *
from SYSFILES

Using these tips you can start to get a better understanding of your database size and you can help manage it and keep your DotNetNuke site running at peak performance!

Please share your thoughts and concerns below.

Posted by Mitchel on Tuesday, April 24, 2007
 

Comments

Also, page weight is something that you should keep an eye on. Skins that are very beautiful can often go over 300K total page weight, and involve many objects that browsers must manage in memory.

A tool I use to check out page weight, load times, and object complexity is

http://www.websiteoptimization.com/services/analyze/

HTH!

By bonder on Friday, June 22, 2007 at 4:29 AM

This is a VERY valid point!

By mitchel.sellers@gmail.com on Friday, June 22, 2007 at 8:58 AM

What if our log viewer isn't appearing as an option? Is there a simple setting we can fix to see it?

By amahannah on Monday, October 15, 2007 at 10:23 AM

Amanda,

If you can't see it as a menu option in the 'Admin" menu, then you have some other issues going on with your site.

If you need some assistance please let me know, but that is beyond the scope of what can be answered here.

By mitchel.sellers@gmail.com on Monday, October 15, 2007 at 8:16 PM

Hey all,
When I run a SQL query in the Host/SQL on DNN for SELECT *
from SYSFILES everything is fine however when I try to run a query for the event log or the site log I receive this error message.

There is an error in your query!

Any ideas?

By Brian on Thursday, March 27, 2008 at 7:59 PM

Brian,

If you have an object qualifier specified in your web.config you will need to append that to the beginning of your table name...

By mitchel.sellers@gmail.com on Friday, March 28, 2008 at 11:04 AM

Use the gzip compression, keep your page size and image sizes down, we tend to schedule and restart the app pools for our really large websites about twice a day. We tend to turn off the logging for our large sites, it is pretty rough. Caching, we run high cache. On our dedicated boxes where we host DNN sites for our clients we don't give everyone there own app pool even though we should. We just see too much of a performance hit when doing 50+ sites.
Module called pageblaster is worth looking at.

By Michigan DotNetNuke Expert on Saturday, April 05, 2008 at 5:57 PM

For anyone wanting to try out PageBlaster you can find a free edition here:
http://www.snapsis.com/PageBlaster-Community-Edition.aspx

The free edition may be all you need for performance and automatic web optimization, but if you decide to upgrade to professional then you can use the following coupon code for a 25% discount: Sellers

By DNN Performance Module on Sunday, April 13, 2008 at 2:20 PM

If you are running an older version of Dotnetnuke prior to version 4.5 you have to consider upgrading to the latest version as it is a whole lot faster. Also you may consider removing dll files for modules you are not using in you web. Be sure you know what you are doing though as removing the wrong dll will cause problems running your web. Creating a backup before doing anything is always good practice.

By Dotnetnuke custom modules on Friday, May 02, 2008 at 12:23 PM

Hi Brams & All

I hosted http://www.mcpsystems.net a dotnetnuke site, but getting low performance issue.

When user visit this site they feel that browser get hanged ( showing only black screen and not refreshing etc. ) for few seconds. for low internet speed user not able to open this site, can you please guide how can I resolve this issue.

Thank you,
Prashant

By Prashant on Tuesday, January 27, 2009 at 6:59 AM

It looks like you are a victim of the standard ASP.NET shutdown.

Running a keepalive service such as Host-Tracker, Pingdom, or my newly available service MyWebKeepAlive will be your best bet overall.

I would also look at my article on "how I make my dotnetnuke sites run fast" that was posted about 1-2 weeks ago.

By mitchel.sellers@gmail.com on Tuesday, January 27, 2009 at 8:47 AM

SO... what's the story with the Admin and Host Settings pages' control over the Site Log? It seems to work or do what it's supposed to IN ONLY ONE CASE??

If you set the SiteLog History to Zero (0) then it properly does not keep any site log at all.

If you set the SiteLog to something small like 2 days or 10 days then it seems to have no power / action at all and allows the db to go on forever keeping site log!

Point(s) in case, we have a site that was set to 2 days in the Admin Site Settings (host was set to zero) so it kept the site log and gained 90K records and a 40mb size for Just the SiteLog table over a couple of months.

In another iste, we had it set to 10 days, and it kept all the site log data forever and over half a year or so, it grew to 4,741,011 records and a size of 2,643,336KB for just the SiteLog table!

SO, what's wrong/broken with DNN regarding the site log? is there a stored proceedure that's supposed to be running on a schedule to clean out those logs that's not firing off? Or a setting in SQL server that needs to be set to allow for control of this table?

By moorecreative on Wednesday, September 30, 2009 at 9:49 AM

OK... that's about 40 minutes to be able to answer my own questions (all with Mitch's help of course!)

the short answer is that the PurgeSiteLog scheduled task is NOT ENABLED by default in DNN. If you update the SiteLog History to anything other than zero then you MUST also go in and enable this job.

that begs the question, though, WHY in a modern version like DNN 5 if you make a change in the site settings or host settings location, why on earth DNN wouldn't automatically enable that job, and perhaps disable it when the history is set to zero??

-----------------------------------------
here's Mitch's page:
http://www.mitchelsellers.com/blogs/articletype/articleview/articleid/181/dotnetnuke-scheduler-explained.aspx
---------------------------
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
----------------------------------

By moorecreative on Wednesday, September 30, 2009 at 11:31 AM

Thanks for the tips posted in the article and comments here. I just deleted thousands of old record in my database and removed the event log, my site http://www.studentbees.com.au is running faster now.

By Studentbees on Sunday, April 04, 2010 at 6:30 AM

Comments from the following blog entry: Striking a Balance between Design, SEO and DNN - Part 2, located at: http://www.ralphwilliams.com/home/entryid/9/striking-a-balance-between-design-seo-and-dnn-part-2.aspx

By RalphWilliams.com on Friday, April 30, 2010 at 1:12 AM

We cleared our site log last Friday and today, Tuesday it already has 174,200 records or rows. Is this typical?

We want this information to analyze page hits and have set the Site Log History to 30 days as requested by our customer.

I read in this blog post that greater than 5K records can cause system performance issue - we have not seen any yet.

But I am wondering what the typical size is for a site log on other DNN website installations.

Do I have something to worry about here? The scheduler is enabled to purge the site log daily for records older than 30 days.

By Becky Small on Tuesday, March 15, 2011 at 1:15 PM

Becky,

Depending on traffic, that could be correct. It is a very granular method and the more traffic you have the more it will take.

By mitchel.sellers@gmail.com on Tuesday, March 15, 2011 at 2:24 PM

I had to post this.. I am the new IT guy for a company. I was looking for a way to setup a Development server for the company website and fell upon your site. I had my host backup my database file. My "Data Space" on the EvetnLog Table is 4,496.227 MB which is over 4 GB. My record or row count is 508208. The site has been very slow and timing out and my host told me I needed a dedicated server for my site. I have a feelign once I get this sorted, my site will scream and I will be a hero.. At least for a day...:)

By Mike on Thursday, April 21, 2011 at 4:20 PM

Name (required)

Email (required)

Website

CAPTCHA image
Enter the code shown above:

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.

Friend of RedGate

www.datasprings.com - DotNetNuke Modules ICG Hosting

Click here for advertising information.

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.