Performance troubleshooting tips and tricks

This article applies to legacy versions of Kentico CMS. If you are using Kentico 10 or above, please refer to the updated version of the article.

• Check if the performance issue is consistent across the whole web site or for particular pages only.
• Check the Event log for any exceptions, errors or page not found events and try to eliminate them
  • Any 404 Page not found errors could indicate an issue,
  • Any other errors or exceptions deserve the attention – something is going wrong in your CMS,
• Use development tools in your browser to identify what is taking so long to load
• Use the Kentico debugging tools and check
  •  The worker threads that are taking too long to execute,
  • Which SQL queries are pulling too much data and taking long to get them,
  • If you are using caching, use the cache debug to check if the data are correctly cached,
  • You can also use SQL profiler to check the SQL queries,
• Check the CPU and Memory usage on the web and SQL server. Use the performance counters to check the environment health,
• Use the health monitor tool (EMS only) to check the Kentico application,
• Review any custom code in place, including java script, CSS, etc.,
  • Minimize number of objects allocated in memory,
  • Reuse existing objects/data

The above steps should give you some initial insight what is going on, what the bottle necks are and you can start optimizing.

• Eliminate communication between client and server,
  • Locate code (JavaScript/CSS) into external files, so that the same code is not transferred over and over, but instead it is cached on the client side,
  • Enable client cache for all possible resources,
  • Eliminate cookies, because they are sent from the client to the server with each request,
  • Reorganize the resources on the page to improve visual performance,
  • Disable ViewState,
  • Use code minification & compression,
  • Eliminate the round trips (redirects),

• Reduce data transfer and frequency retrieval between database and web server,
  • Optimize all custom SQL queries,
  • Cache data on server side,
• Eliminate resource consuming and intensive operations,
• Disable scheduled tasks which are not used or run them as external services,
• Increase execution interval of scheduled tasks,
• Disable output filter and write better code,
• Think about the best storage for your files,
• DB vs. File system,
• Content Tree vs. Media library,
• Scaling out vs. scaling up your hardware,
• Optimize SQL server and IIS settings,
• Cache output on IIS level,
• Disable features/functionality which you are not using,
• Review your environment setup,

As you can see there is a lot of work to be done.

Caching is the most powerful performance tool. Of course, it needs to be used wisely. However, this should be enabled as the last step when it comes to web site optimization. Every project differs from one another, so there is no general rule how to set up your caching plan.  The golden rule says that: caching data even if it is for a short period of time is better than no caching at all. But, enabling caching could just suppress the real symptoms, which is not the proper way to start addressing performance issues.
Let's take one of the most commonly used built-in web parts (Repeater) as an example. Usually the purpose of the repeater is to output HTML code, which is based on your custom transformation and data (stored as documents in content tree).

• In most of the cases, you don’t need to introduce the overhead of processing and the extra data transfer between the client and the server in the form of ViewState. Each web part has a general property called "Disable view state".   By setting this property to true (checked), you will eliminate the size of the page ViewState.

• The real performance killer regarding this web part might be data retrieval from SQL database and its processing on application (CMS) level. The less data you retrieve, the better your web site will perform.  Ninety-Nine percent of the time you don’t need to pull all the related documents data from the database. In the case of documents, we are talking about retrieving data from up to 4 tables (CMS_Tree[25 columns], CMS_Document[73 columns], COM_SKU[40 columns] and Document Type table[x columns]).  This could result in pulling up to 140 unnecessary columns, which may not even be used in your transformation. Think about the fact, that all of this extra data needs to be transferred between the web server, the database server, processed by application (CMS) and then only a fraction of the data is used. Luckily, there is a simple solution where you can restrict the columns that you are using in your transformation in the "Columns" property of this web part.

• If you are not displaying any sensitive data, or data that should be publicly available with the web part, you should disable the "Check permissions" option. As with any other check operation you are adding another step in the retrieval process, this results in additional resources being used as well as a possible delay in the response time. 

This was just an example of setting three web part properties. Given the example above, you can see how you can run into performance issues, not only by using custom code improperly, but also by not utilizing the built-in functionality according to the best practices.
Most of the performance issues arise from improper web site design in the first place. As the website grows over time, you could find yourself redesigning the web site from scratch because the scalability of the web site cannot be easily improved. That is why you should allow some time to read through the Kentico DeliverNow Methodology, which discusses various topics related to proper web site design.
That being said, you can use our Performance and Health Audit consulting package.  This is suitable for ensuring implementation scalability and for the stability of your project with a high focus on web site performance.  Kentico Senior Solution Architects with extensive Kentico CMS/EMS knowledge can investigate the root of the issues and provide you with best practice solutions to resolve them.
Finally, if the web site is optimized and still not performing according your expectations then it is time to think about using scale-up (vertically: using better HW for your server) and scale-out (horizontally: adding more servers) techniques or simply move the web site to cloud hosting (Windows Azure etc.). If you would like to host your web site in your own environment and serve more requests in future when number of visitors or hits might rapidly increase, I would recommend you to consider running your web site in web farm environment.

Some clients tend to spent extra money on buying better hardware for their environments, thinking this will help to speed up their web site.  However, the reality in most cases is very different.  We should always ask ourselves, whether we have done everything that we can do to ensure the web site is really optimized. Let's learn from our mistakes and investigate the issues as explained in the Performance Mistakes webinar.

See also: Troubleshooting performance issues
Deep dive – Cache dependencies
How to speed up your Kentico site
What you should NOT do with Kentico CMS
Kentico CSS and javascript
Images and media

Applies to: Kentico CMS 6.x and above