Hi,
Below is some general information you can take a look at. However, it would be great to check e.g. the debugs to see what is going on and also e.g. the Windows Event viewer logs, check the IIS settings and application pool limitations

When it comes to performance optimization of the web site, there are many factors that you can focus on.

You can try to:

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,
Reduce data transfer and frequency retrieval between database and web server,
Optimize all SQL queries,
Cache data on server side,
Review the usage of Kentico API and custom code,
Minimize number of objects allocated in memory,
Eliminate all exceptions logged in the Event log,
Reuse existing objects/data,
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,
Disable features/functionality which you are not using,
Think about the best storage for your files,
DB vs. File system,
Content Tree vs. Media library,
Review your environment setup,
Scaling out vs. scaling up your hardware,
Optimize SQL server and IIS settings,
Cache output on IIS level,

As you can see there is a lot of work to be done, but where to start?

Well, one could say that 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. However, enabling caching could just suppress the real symptoms, which is not the proper way to start addressing performance issues.

Instead, we should start focusing on identifying the real bottlenecks in the first place. Luckily, Kentico comes with great debugging tools where you can identify slow running SQL queries, number of cached items, the execution time of each page request event and many others.

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.


That being said, this is why I would like to point out 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.

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.

Some of our 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.

Best regards,
Juraj Ondrus