Overview

DNN performance issues can be broken down into troubleshooting steps to identify what may be degrading the performance in a DNN environment. This article goes into the process and explains the steps to troubleshoot a performance issue whether it is client-side or server-side.

Introduction

Performance problems in DNN are generally all reported in the same way. A user states that the "site is slow." In some cases, you know changes that were made recently, or that the slowness only happens at certain times, but in many cases, we only know it is not running correctly. To narrow down the source of the performance problem efficiently, you must ask specific questions to rule-out or confirm possible root causes.

Performance problems generally manifest as one of two symptoms. Either something takes a lot longer than it should, or it does not work at all, and there is an error message. The second case is just the first one with a timeout occurring somewhere in the process. Often you can avoid the error message by increasing the timeout value, but this is rarely the correct way to resolve the issue as it does not address the underlying problem with elapsed time.

Description

How to Isolate the Cause of a DNN Performance Problem

This section provides the known root causes of performance problems split into categories and the questions to aid your diagnosis.

Start by asking these general questions to get the basic facts:

1. Does it happen at certain times or all the time?
2. Does it affect all users or just some?
3. When did it start happening, and were there any changes made recently?
4. Is it reproducible by doing anything specific?
5. Can you provide:
   1. Log4net files from the time when the issue occurred.
   2. IIS logs from the time when the issue occurred.
   3. A Fiddler trace of the page when the issue occurs.
   4. Site_Evaluation.sql script results.

Once you have the basic facts, you progress through a decision tree to narrow down the options.

• Is it occurring server-side or client-side? To answer this question, check the Fiddler trace and the log4net files. Server-side issues usually show up as the default.aspx file taking a long time to be served (known as time-to-first-byte, TTFB). Client-side problems are related to individual resources on the page interacting with the browser.
  
  
  • If the issue is occurring client-side, is it due to a request taking too long, or too many requests occurring? This answer comes from the Fiddler trace.
    
    
    • If the requests are taking too long, go to RC #1 - Client Requests Timeout.
    • If there are too many requests occurring, go to RC #2 - Client Requests Spam.
      
      
      
  • If the issue is occurring server-side, is it a hardware or software problem? This answer is confirmed by looking at the server performance monitor and log4net files.
    
    
    •  If it is a hardware issue, is it due to system resources or network related?
      
      
      • If the application or database server is running low on memory or CPU, go to RC #3 - Hardware Resource Bottleneck.
      • If there are problems with network connectivity or latency, go to RC #4 - Network Infrastructure or Configuration.
        
        
    • If it is a problem with the software, is it the database, the DNN application, or something else?
      
      
      • If the issue is with the database, is it due to processing time or the amount of data?
        
        
        • If it is due to how long it takes for a query or stored procedure to complete, go to RC #5 - Database Processing Speed.
        • If one or more of the tables has far too many rows, go to RC #6 - Database Table Size.
          
          
      • If the problem is in the DNN application codebase, is it due to the code itself, the configuration, or lack of maintenance?
        
        
        • For issues with slow running code, go to RC #7 - DNN Code Optimization.
        • To check all the recommended settings, go to RC #8 - DNN Application Settings.
        • For a list of regular maintenance tasks, go to RC #9 - DNN Regular Maintenance.
          
          
          •  If something else, is it related to a required or accessory application?
            
            
            • For required applications like IIS, the .NET framework, and Windows, go to RC #10 - Required Environmental Software.
            • For any other software which happens to be running on the server, go to RC #11 - Accessory Software.

Root Cause Index

1. Client Requests Timeout

• Regarding local files on the server, confirm that downloaded files are optimized. For example, large images or un-minified CSS.
• Use CDNs wherever possible.
• The most common area with these problems is the skin/theme.
• External files that the client needs to download, for example, hosted JavaScript files, should not be render-blocking. If it is unavoidable, consider a solution such as prerender.io.

2. Client Requests Spam

• Excess requests can come in two forms, completely unneeded requests, and repetitive requests. Fix the former by removing whatever is calling these. Errant redirects commonly cause the latter.
• A rare, but serious, cause of request spam is denial-of-service attacks. Diagnose these by viewing active requests in IIS. If a site experiences repeated attacks, a solution such as Cloudflare might be needed.

3. Hardware Resource Bottleneck

• Since sites can contain any number of custom extensions and other added functionality, there are no hardware-specific DNN minimum requirements. A site needs to have enough capacity to handle the peak volume of visitors.
• If a resource bottleneck is suspected, using the Windows Performance Monitor is an easy first step. 
• Consider the resources on both the application server and the SQL server. If this is the same thing, that can be a problem. Microsoft SQL Server is prone to eating all available memory, so it should be on a dedicated server.
• When a single application server is not enough to handle the peak volume, a web farm configuration can help. It requires extensive configuration and additional licenses, so it is not always feasible as a solution.

4. Network Infrastructure or Configuration

• Network issues happen more commonly when the topology is more complicated. For example, a web farm environment with four nodes, the load balancer in the DMZ, a file cluster with replication, SQL server with disaster recovery, and a hardware firewall can introduce many points of failure.
• Something as simple as extended latency between the file server and application server can have catastrophic performance implications, as many small files are continuously requested, and the latency impacts each one.

5. Database Processing Speed

• The primary tool for diagnosing database query processing speeds is SQL Profiler. SQL Profiler allows you to pinpoint the exact stored procedure called and parameter values.
• Default DNN stored procedures and tables are all indexed and optimized, but third-party database objects might not be.

6. Database Table Size

• Several tables can grow to the point that they impact site performance. The site evaluation script is a safe way to quickly check if any of the typical tables are too large. If any are, you can take a backup of the database and then remove the unneeded data.

7. DNN Code Optimization

• It is rare for code-related problems to occur in the core DNN source, but for custom and third-party code, there are some recommendations. The most impactful is to utilize DNN cache mechanisms as much as possible.
• When trying to determine if the performance problem exists in DNN core or not, tools like ANTS Performance Profiler and reading the stack trace in the logs make it clear.
• If you are unable to profile the site in real-time, getting a memory dump using DebugDiag can be helpful to take a closer look.

8. DNN Application Settings

• Misconfigured application settings are one of the most common causes of performance problems.
• Configure server cache and output cache to cache as much as possible for as long as feasible.
• Configure the scheduler only to run the tasks you need, and only as often as is needed. Some tasks are more taxing than others, such as the search crawlers.
• Use file combination and minification, although the performance benefit might not outweigh the headache of misbehaving files.
• Ensure that the event log is not logging irrelevant information and that the log4net level is not set too high.

9. DNN Regular Maintenance

• Recommend an upgrade to the latest DNN version. Newer versions are universally faster than older ones.
• Remove unused extensions and turn off unused functions.
• Remove "soft-deleted" tabs and users. The Site Evaluation script contains the counts of these.
• Compare the web.config file to a default web.config and remove anything which is no longer needed. Lines can remain after an upgrade or uninstallation.

10. Required Environmental Software

• IIS is the required software with the most performance impacting settings.
• When possible, make sure Windows and SQL Server are using the newest versions with all updates installed.

11. Accessory Software

• Antivirus programs can impact performance if they lock files or scan during peak hours.
• Some software that monitors traffic or other metrics can negatively impact performance by adding latency.
• If resource allocation is a problem, remove software that is unrelated to the DNN site, as it may be consuming shared resources.

DNN performance optimization is a topic that has been around for years. There are many third-party guides and tools which can help in addition to the list above. Once you have narrowed down the root cause, use all available resources to find or construct your solution. 

Also note that performance issues tend to be cumulative, in that if you improve performance in enough areas, other unrelated performance problems go away because a bottleneck was removed. It is very common to have multiple root causes simultaneously. 

Back to top