Archive
Monthly
Go
|
|
DNN Blog
Apr
18
Posted by:
Chris Paterra
4/18/2007
Last night, or early this morning depending on your view of today/yesterday, I had to do a production push for a client. Since the time I was able to do this was limited, for good reason being its a very active site, I had a couple hours of down time waiting for it. So, I decided to take Shaun's advice and do some SQL Profiling of the previous forum release vs. the current one (going through the process) using a copy of dnn.com data.
My initial results were pretty good. The time it took to view a previously viewed group page, then view the aggregated forum, then view a specific post was about 11 seconds in database execution time for 3.20.8-.9. In the forum 4.4 version this time was drastically reduced to 6 seconds. While I was quite happy with this, Shaun pointed out to me that reducing the db calls is what he typically focuses on. Since forums are very user specific when it comes to things such as forum and thread reads, I knew my options were somewhat limited.
Since the module has its own form of permissions (to handle permissions forum by forum) I knew there should be some focus here. The module permissions grid was originally copied then slightly modified to serve as the permissions grid at the forum level. Changing one of the method signatures to retrieve from cache, reduced the average number of db hits to a page by 1 db call per forum. (On dnn.com this can amount to 100 fewer db hits). The next item was to eliminate db hits for unauthenticated users for forum and thread reads. Since users are not logged in, all forum and thread read status should be disabled. Changing this saved an additional db hit per forum (in group view) and an additional db hit per thread (in thread view). The number of hits depends ultimately on the number of forums or threads in the view.
The time it took to run the tests and change the code? About 1 hour. So, for the 1 hour I spent doing this I reduced database calls from the previous version and reduced the 11 seconds it took originally down to 4. (Remember, this is 3 seperate views) Just an FYI, I had already used ANTS Profiler (a Red-Gate product) previously to analyze and reduce code calls where necessary.
7 comment(s) so far...
Re: Forum 04.04.00 Performance Enhancements
Very Cool Chris!
Just goes to show you that profilers can take you part of the way, but in the end, careful analysis and consideration of "code-flow" can produce even more significant efficiencies...
Thanks for taking the time to look at it...
We're all looking forward to this release... Cheers!
By Rob Poretti on
4/19/2007
|
Re: Forum 04.04.00 Performance Enhancements
Hi Chris,
Thats Super! Thats a HUGE (HUGE) increase in performance. I've done quite a bit of DB work (not MS based really) over the years. Some specialized such as terrain and playfield graphics etc. for game software as well as stuff on just enormous DB's such as financial collections which are gruesome and must respond FAST. In Games when one can shave off numerous milliseconds it can result in big gains. At the sametime with games and collections DB's (not so much) the next data sequence the user is to see is often known ahead of time (especially in many a game) so we can prefetch.
I really have not looked at the forum code much so I dont know what's going on under the hood. If you are not doing prefetch it might be something to look into as well. I am reading a thread with 5 pages of posts. It's logical to think after I read page 1 I may well go to page 2 so can prefetch that, cache it. At the sametime if I click "my posts" more than likely I will want see the most current replies, another area where prefetch might be applicable.
I've not even looked at the Table format for the forums. But one way in collections DB's that better performance was achieved is compounding data fields to a singular field and parsing it out at display time. Effectively with alot of DB data its static info in the DB and queries result in fields assigned to variables and then said variables accessed for display purposes or static computational purposes (then to be assigned to a dynamic field). Overhead can often be saved by slapping all such data in a singular DB field and then processing the results of said field as a structured stream of data. If the data lengths are constants that makes things simple, if they are variable then one need determine whether a forward only linked list might suffice from embedded field to embedded field etc. The collections stuff I'd worked on used a balanced tree but the amount of data was just enormous. A singular record if handled as multiple records of the data within could easily be 100-1000 records, so, 1 query vs 1000 and all the info pretty much static data. Loans, debts, non-payments on and on.
Just some food for thought. :)
Again, those are GREAT results.
I'm a strange type of programmer in that I LOVE optimizing.
By rgtss on
4/20/2007
|
Re: Forum 04.04.00 Performance Enhancements
Because each user can select their own page size and things such as My Posts are technically a custom search I think prefetching and caching the data would be inefficient. You never want to cache data specific to a user because in a high load environment (such as dotnetnuke.com) you are consuming valueable memory that will only be cleared when the Garbage collector runs.
By Crispy on
4/20/2007
|
Re: Forum 04.04.00 Performance Enhancements
Is there newer documentation than the 3.20.01 version?
Or do the basics apply?
Thanks for the good work!
JMç
By jmcgarey on
9/24/2007
|
Re: Forum 04.04.00 Performance Enhancements
how long does it typically take for a core module to go through the DNN release process? maybe you could optimise that while you're at it :)
By nsmeaton on
9/24/2007
|
Re: Forum 04.04.00 Performance Enhancements
Where is download link.............Before using I can't say anything !
By ramesh0 on
9/24/2007
|
Re: Forum 04.04.00 Performance Enhancements
where does download it ?
By hoangtutm on
9/24/2007
|
|