A couple of days ago I showed a method for finding a module on another page. Néstor Sánchez pointed out that on a large site, this could cause a significant performance issue. He suggested, instead, registering the location of the module with the database when it is created on the page it is on.
I was looking for a way that would allow the module to move around, and had initially thought that a module-centric method would require the end user to do something. Ah well, that’s one of the problems of working alone. (And one of the advantages of blogging about what you’ve done.)
So, let me show you the way I did solve the performance problem. It isn’t quite as efficient as what Néstor recommends, but it is usable in other situations and it is a performance solution you need to know about.
In the old days of ASP, when we wanted to store something across sessions, we’d put this information in the Application object. It was a solution, but had memory issues.
When ASP.NET was introduced, the Cache object was introduced, which allows us to store information in memory. But if that memory is needed for something else, the memory is swapped out. Meaning, we can use the memory for caching, but we always need to make sure that what is cached has the information we are looking for before we try to use it since it may have been swapped out.
The problem with ASP.NET caching is that it just isn’t practical in a shared hosting environment. Multiple applications running on the same server means the memory is almost always needed and nothing is cached.
DotNetNuke has its own caching mechanism that overcomes this limitation. You can choose to store the cache in memory, if you are running your application in an environment where this makes sense, or you can have it use hard drive space.
You will need to use a couple static methods hanging off of the DataCache class located in the DotNetNuke.Common.Utilities namespace.
To put something in the cache, you can call SetCache() using any of the 12 overloaded methods. To pull something out, you can call GetCache().
The various methods allow you to set dependencies just like you can with the .NET caching model. But, unlike the .NET caching model, you can tell the object to persist an application restart.
I’ve been able to use this throughout my code to avoid otherwise time-consuming operations in several locations including caching code-generated images. In this case, as I changed the source image, I needed to clear the cache. I did this by using the RemoveCache method.
By setting the sliding expiration to one day, I can take the performance hit for the lookup once a day and otherwise have the same performance I would have by storing the value forever in a table in the database.
Other post in DotNetNuke - Module Development
- Creating DotNetNuke Modules - May 20th, 2008
- Creating DNN Modules - The Tools - May 22nd, 2008
- DotNetNuke Modules - Foundational Concepts - May 26th, 2008
- DotNetNuke Modules - Creating Base Modules - May 28th, 2008
- DotNetNuke Modules - Registering Your Module - May 29th, 2008
- DotNetNuke Modules - Where Stuff Shows Up - June 3rd, 2008
- DotNetNuke Modules - Anatomy of the View - June 9th, 2008
- DotNetNuke Modules - Adding Actions - June 11th, 2008
- DotNetNuke Modules - DNN Controls - Label - June 18th, 2008
- DotNetNuke - Internationalization - June 25th, 2008
- DotNetNuke Modules - Internationalization (part 2) - June 30th, 2008
- DotNetNuke Modules - Labels w/ no Help - July 9th, 2008
- DotNetNuke Modules - LinkButtons - July 14th, 2008
- DotNetNuke Modules - Collapsible Panels - July 16th, 2008
- DotNetNuke - The Data Layer - Installing CodeSmith - July 22nd, 2008
- DotNetNuke - Modules - Creating The Tables - July 24th, 2008
- DotNetNuke - Modules - Creating Stored Procs - July 29th, 2008
- DotNetNuke - Modules - Portal Specific Modules - July 31st, 2008
- DotNetNuke Modules - Data Access Layer - August 5th, 2008
- DotNetNuke Modules - Data Access Layer - August 7th, 2008
- DotNetNuke - Data Access Layer Alternative - August 12th, 2008
- DotNetNuke - Modules - Linking within the module - August 14th, 2008
- DotNetNuke - Make Your Module Searchable - August 19th, 2008
- DotNetNuke Modules - Making Content Portable - August 25th, 2008
- DotNetNuke Modules - Exceptions the DNN Way - September 2nd, 2008
- DotNetNuke Modules - PortalModuleBase - September 4th, 2008
- DotNetNuke Modules - Inter Module Communication - September 9th, 2008
- DotNetNuke Modules - Finding The Page a Module is On - September 15th, 2008
- DotNetNuke Modules - Caching - September 17th, 2008
- DotNetNuke Modules - Module Settings - September 22nd, 2008
- DotNetNuke Modules - Retrieving Settings - September 24th, 2008
- DotNetNuke Modules - Advanced Architecture - October 20th, 2008
- DotNetNuke Modules - Creating the PA - October 30th, 2008
- DotNetNuke Modules - Automating the PA - November 5th, 2008
- DotNetNuke - FileUploadControl Danger! - February 26th, 2009
- Changing an Existing DNN Module - March 4th, 2010
- Facebook App using DotNetNuke - January 19th, 2012
- DotNetNuke Modules - Install DNN into VS 2008 - June 19th, 2012
- DotNetNuke SecurityException AspnetHostingPermission - February 19th, 2013
- DotNetNuke Modules - Benefits of Architecture - April 9th, 2013
- Debugging TypeScript Under DotNetNuke - May 8th, 2013