Hi,

When it comes to performance optimization of the web site, there are many factors (areas) that you can focus on - it is hard to say from your short description which one exactly is the right one for you. Anyway, I think reading the general information/suggestions below can help you in general and also in other parts of your web site to optimize things to get the best performance.

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,
- Disable ViewState,
- Use code minification & compression,
- Eliminate the round trips (redirects),
- 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. 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.

Best regards,
Juraj Ondrus