Blogs

Module Performance; Set Yourself Apart

06 Jul

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. However, many modules & vendors ignore this major difference. Lets look as some simple tips & tricks to help us set our modules apart.

Why Performance

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.  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, and far greater impact was the quality & performance of third-party modules used.  Sadly, the solution in most cases was to abandon the modules.  

This post isn't to air dirty laundry, but to simply discuss areas to help module vendors prevent their modules from being one that has to get yanked out to keep a site performing well.

Manage jQuery & jQuery UI Properly

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 manager, and become a better DNN Citizen all at once!  Awesome.

Use DataCache If You Can

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.  Less calls to the database, the better!

Test & Support Module Cache If You Can

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.  

Test Your Module Under Load

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! 

Lets Succeed Together

The biggest point of this article is if as a module vendor your 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 the DNN Store Blog.

tags: DNN, DNN Administration, DNN Development, Performance
comments powered by Disqus

Content provided in this blog is provided "AS-IS" and the information should be used at your own discretion.  The thoughts and opinions expressed are the personal thoughts of Mitchel Sellers and do not reflect the opinions of his employer.

Connect with Mitchel

I hope the information here has been helpful. To stay connected you can also subscribe to blog updates via email, contact Mitchel about consulting services, or reach out for assistance via CodeMendor

Content Copyright

Content in this blog is copyright protected.  Re-publishing on other websites is allowed as long as proper credit and backlink to the article is provided.  Any other re-publishing or distribution of this content is prohibited without written permission from Mitchel Sellers.