I have read at various times in various places that the DNN site log can hinder site performance. People often say to clear the site log to speed the site up again.

Given a fast server and no other bottlenecks, can someone tell me exactly what sort of load the site log adds and to what aspect of the site?

Is a 60 day log twice as bad as a 30 day log?

How about having a 30 day log for each of ten child portals.. is that a nasty hit? I was planning on having 30 days per portal for any number of child portals.. 100.. 200? Is that possible or will it kill the site?

Are there any performance tweaks that would make the site log faster... in the scheduler perhaps?

How about the site log buffer where I can enter a number.. which is presumably a ram buffer before writing to the db on disk? how big is an item?.. if they're just a few bytes, then is it worth putting a high number in there... what if I put 100 in there?.. What if I put zero?

I'm running a single instance with lots of sub-portals on a VPS account and I really can't tell where any bottlenecks are just by using the site/s... things generally run very well, but I don't want to work my way up to a performance issue long-term.

And another one.. the Users-online setting... which is not enabled by default.. what is the issue with that? Is that another performance hit and if so, how big - again, given no other bottlenecks.

And ifnally, the Event Log Buffer setting.. another ram buffer? What's the performance issue that this assists.. what are the caveats of enabling it? I note that it is also not enabled by default.

Lots of questions I know, but I'm hoping for a good response from someone who knows the real deal, and then there'll be a good thread here permanently for people to find this information.

Thanks heaps for any information about these things.

Rob

I am going to just respond on the basic database perspective on this issue, I am not 100% sure if there are other implications than these that I list so this might not be a comprehensive listing.

Keeping the site log is like keeping your IIS logs showing user activity, you are inserting records after each page request to indicate the users information, page location, and other items.  Each time you do this you are inserting to the one table and it begins to grow record by record.  As the table gets larger with indexes on it you can notice that insertions can start to take longer to execute and again the DB continues to grow.  As the number of records increase it will take even longer to query the tables for results.

If you have 30 days of site logs for 200 active portals it could grow to a VERY large size quite quickly, it all depends on the user load.  Now, the actual end user performance hit comes primarily from the inserting of records into the databse and as time progresses and the table grows you will start to notice a bigger performance hit.

If you must keep the data for reporting needs, you could possibly look at exporting the data to a secondary table for reporting purposes to keep the record counts low on the DNN table but then you wouldn't be able to view reports via the DNN interface.

I personally have the site log disabled for all portals on my DNN installation and utilize Google Analytics for my referral tracking.

---

-Mitchel Sellers
Microsoft MVP, ASPInsider, DNN MVP
CEO/Director of Development - IowaComputerGurus Inc.


Visit mitchelsellers.com for my mostly DNN Blog and support forum.

Visit IowaComputerGurus.com for free DNN Modules, DNN Performance Tips, DNN Consulting Quotes, and DNN Technical Support Services

Rob,

First of all yes, some actions are more costly than others, and the site log entries are more costly than a read as they are inserts.  WHen you are inserting especially to a table with indexes and other items it takes more time to load.  How much time specifically I am not sure.  The hit for the site log is I believe once every postback, or once every page.  As for the number of other database queries that are going on, I am not 100% sure how many go on, as it also depends GREATLY on which modules are on the site, their database requirements, their caching model and many other outside influences.

In regards to the overhead added, you first of all notice increased overhead with database size.  This overhead makes the insert process slower as more records exist, this is again due to indexes and other constraints on the DB that must be checked prior to insertion.  From my experience this is a VERY exponential curve and as the number of records goes up the impact becomes much greater.  For example with my site at 5000 records I was seeing page load times of 2-3 seconds, which wasn't bad.  At 6000 records I was looking at about 3-4 seconds, but at 7000 records I was well oveer 4.5 seconds minimum, so the difference didn't stay the same.  This issue would be much bigger in m y opinion running multiple portals.

You are correct that the "buffer" helps, but it doesn't do a lot on an active site, instead of doing individual inserts at every request you will do a "bulk insert" every 20 records.  So then every 20 page requests you will encounter a large insert statement against the database.

In my personal opinion I do not use the site log as I have access to a statistics tool from my hosting provider based on IIS log information and I also use Google analytics thus I don't need the performance hit on my sites.

---

-Mitchel Sellers
Microsoft MVP, ASPInsider, DNN MVP
CEO/Director of Development - IowaComputerGurus Inc.


Visit mitchelsellers.com for my mostly DNN Blog and support forum.

Visit IowaComputerGurus.com for free DNN Modules, DNN Performance Tips, DNN Consulting Quotes, and DNN Technical Support Services