.NET Answers

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.