Return to Previous Page
Mitchel Sellers, Microsoft C# MVP & DNN MVP, is the CEO of IowaComputerGurus a West Des Moines Iowa based software consulting firm. Mitchel enjoys sharing his experiences with others through blogs, books, and speaking engagements all across the world. With experience in multiple industry verticals and different business sectors Mitchel has spent a lot of time focusing on application performance, stability, scalability and maintenance. When he is not coding you can find him on a motorcycle or up in the air flying about!
With a plethora of modules on the market today, it is often hard for users to select the "right one" for their solution. Help yourself, and help your customers by setting your modules apart in one of the most important ways, performance. Not all DNN sites are large; not all DNN sites are small; that's the beauty of the platform. This major difference should not be ignored by those developing modules for DNN. Lets look as some simple tips & tricks to help us set our modules apart.
Before I get into my specific recommendations I thought it would be prudent to discuss WHY I feel that this is such an important aspect to consider. For those of you that follow me on Twitter, you might remember the various posts I have been making over the past six or so months about performance tuning DNN. I've had a large number of new clients come along, and they have been looking to improve the speed of their site. In every one of these situations, from the person looking to optimize for the seconds of load time to the person looking to handle 50,000 concurrent users, the root cause of the performance issues were two fold. First was configuration of DNN, to which I've already blogged about extensively. The second was the performance of third-party modules used.
The purpose of this post is to discuss areas to help anyone developing DNN modules to allow their modules to extend the functionality of DNN without impacting site performance.
I'll start with a really simple one. This item isn't only a performance thing, but can be a site stability issue as well. Since DNN 6.0.0 and later there has been an API method to include jQuery and jQuery UI. These are used internally for DNN to handle their use for administrator functions. As a third-party module developer, if you need to use jQuery or jQuery UI in your modules, you should use the API to request it, rather than manually linking to your own copies of the libraries. This is for two major reasons. First of all, for performance we reduce 2 HTTP requests on every page load. Secondly, for site stability we avoid client-side issues that arise with having two versions of jQuery loading at the same time. This can cause site functions to become unusable.
This advice goes to Skin developers as well. Don't include jQUery in your skin, include a call to DotNetNuke.Framework.jQuery.RequestRegistration(); if you have to. Make your packages easier to manage, and become a better DNN Citizen all at once! Awesome.
Yes, it takes a bit longer, however one of the biggest things that you can do to improve the performance of your modules is to investigate the usage of cache. In this case I'm talking first about the DataCache. This is the cache strategy you can use for internal items and not directly related to the UI element. You can cache things such as web-service responses, SQL Query results etc. This can be something you manually do, or if you are using DAL2 you can get it out of the box.
The key here: reduce how much your module chatters to the database. The less calls to the database, the better!
This is a further extension to the data cache. Module cache is the ability of DNN to store the generated HTML that your module creates and sends that as part of the response for a set period of time. This allows all of your code, AND database calls to be bypassed for the configured amount of time. This is only used when the page is viewed by a non-authenticated user and should only be used if the users do not interact with the page, but can be very helpful for performance.
This has to be the biggest and most important of all items. Don't just throw your module out there, go out there and test it with some users. Look at the things that it does and how it impacts the site performance. Does your module chew CPU? Does it abuse the database? Does it leave lots of open SQL Connections? Test it under stress and know how it goes. Then, once armed with that information use it to your advantage, share the results and brag about it!
The biggest point of this article is this: if as a module developer you are concerned about performance and the rest of the ecosystem is also concerned about performance, we can make DNN a truly unique platform, with a collection of modules that not only accomplish a goal, but that can expand rapidly with a site to handle sites of all shapes and sizes!
This post has been cross posted to my Personal Blog.