Performance of Kentico CMS


We are often asked about the performance and load tests of Kentico CMS. We do not currently provide the full load test suite since it is internal, we will probably provide the public performance reports later. I would like to present you some information about our load tests and optimization procedures and ensure you we do our best in this field of implementation.

Why is the web site (product) so slow?

This is the eternal question of all customers of all the applications ... the usual answer of our support team would be probably: "We are not sure, we do not have any problems with performance, could you please send us the export package?". This is not an answer from someone who wants to get some time to investigate, but from the experienced user who knows that lot of the performance issues are caused by the design of the project. Until someone can actually answer you the question, you (or he) must always ask and resolve the question which is more important for your project, so we will just start with that to ensure you done everything you could, the question is:

Did I design the system correctly or are there some performance issues from my side?

Every solution has many ways how it can be done. Some of them are good, some of them are bad. As you sure know, the solution is so fast as its slowest part so let's assume for a while the Kentico CMS (or any other program) is written correctly and the solution is fast enough. If the solution is fast enough, the problem is probably on the side of the person who implements the specific web site. Here are some performance tips and most common mistakes that you can do:

1) Find the slowest part of the solution

You should always start with the slowest part of the solution to remove the slowest part of your code or configuration, you can find the slowest part several ways:
  • Use SQL server profiler - With SQL server profiler you can see all the queries that are called by the application and find the slowest ones, you can use this if you use your own queries and you are able to find them in all the called queries.
  • Use Kentico CMS query debugging - From version 3.1 the Kentico CMS offers integrated query debugging where you can contextually find the queries and get the information about amount of data returned by the query. You can find the details on this feature in Kentico CMS Developers Guide -> Debugging and optimalization
  • Use some 3rd party or integrated VS performance monitoring - This way you can find the parts of the code which are slowest
  • Use your brain, check the settings of components located on your web site and try to find the parts which could work with too much data and could be optimized somehow
If you find the slowest part, you can optimize it ...

2) Reduce the amount of data

If some of the data aren't nesessary (aren't displayed), you should not require them from the system. You should also simplify the way how the data are filtered on the SQL server.

Typical mistake: You have the web site with large number of documents and you display the menu with just one or two levels. You should always simplify the final where condition to search only these two levels instead of the full document tree.

3) Think of a scenario with the most amount of data

Prepare the scenario with most amount of data you are expecting from your web site (solution). Can your solution handle such amount of data? If not, think of ways how you can limit the amount of the data.

4) Reduce the number of queries

In some cases, you may need to get some additional data in you transformation. This is potentially harmful for your web site performance, because every item needs to get the additional data and may cause the query. You should always cache these data to reduce their number or use alternative ways how to get the information (use current page info or current document object from context, etc.).

5) Simplify your code and data retrieval

Use functions to get the additional data for your code and cache the data the same way like before. You should avoid recursion if possible.

6) Use caching

With Kentico CMS you can use several levels of caching, you should always use caching if the content is not too dynamic. You can use following caching options:
  • Page info caching - This caches the default page (document) information and this information is used in all parts of the page processing, this should always be cached.
  • Content caching - Content caching means that the controls cache their data so they do not need to access the database to get them. You should use this caching if you do not wish to use full page caching and get better performance.
  • Image caching (file caching) - Attachment files can be cached to speed up the process of their retrieval.
  • Full page caching (output caching) - Unlike the other caching which are configured in the Settings of the web site and certain web parts, full page caching can be configured for the section of documents in the document properties and caches the complete HTML output of the page. It should be used only for static content but brings excellent performance to the web site.
All caching of Kentico CMS is based on the standard caching models of ASP.NET. Here are some tips to set-up your caching.

7) Disable everything that you do not need

If you do not need some functionality or if you have some alternatives with better performance, disable it. It is nice to have output filter enabled to resolve one URL for your code and simplify your code this way, but the output filter must search such fixes through all the output content which slows down the application. So if you are experienced, you can write the code which doesn't require output filter for example.

8) Update the solution with latest version

In every version, we take care about the core performance just like you take care (or should take care) about your web site structure performance. This is the reason you should always update to the last version of our system. New version has always some additional optimizations and many bug fixes.

9) Read the documentation

Last advice I can give you right now is to read the documentation. The documentation is not just boring collection of sentences, it is valuable source of information. If you understand the system completely, you can write better code, create better sites and the time you spend by studying the documentation will be given back to you very soon, at the time you won't need to spend the weekend by searching the performance or any other issue because your web site architecture will be just right. It is the last point in my list but one of the most important.

What now? Kentico CMS

So, now you have your part of the system properly structuralized, set up for fine performance and updated to last version. What is the next step? Learn something about our development, the way how we ensure the solution to be fast and reliable ... You will also learn how the Kentico CMS evolved to understand the consequences.

At the beginning, there was ...

Actually, at the beginning, there was one boss and a small group of programmers (some of them external, many of them students) who took care about almost everything. To be honest, from current perspective it was very chaotic process. These were the times of version 1.x. There was just simple vision to create the Content Management System and small group of customers who presented their needs. The architecture of the system was counting only with small web sites and there were no resources for optimization so it was basically built on the simplicity. At some point, it became too bad for next updates ...

Not enough space?

When the version 1.9a came out, it was already obvious that we cannot continue this way, that the solution isn't good enough to become the best choice for our customers. It was fine for the features it offered at the moment but It just didn't offer enough space for further modules and new features. Thanks to our customer base, the company could afford more developers and some of the students graduated and become full time employees. This extended our possibilities to be able to create version 2.0

Version 2.0 was completely recreated using design patterns, the bad things on architecture were replaced by new approaches and the solution was ready for further improvements. This is basically the reason why some of the customers had to change their code while migrating from 1.9a to 2.0. Architecture of version 2.0 is well designed and no other significant changes were needed since this one. Still, at this moment the solution was developed as it was designed, without reviews and performance optimizations.

Not enough performance?

As the solution and the company grew, it has come to our minds that the solution needs more than just a lot of features. The number of customers increased and we acquired some large clients which needed the best they could get from their web sites. This is why we found the time in our tight schedule and optimized the slowest part of the solution. Basically, we followed the steps above. From version 2.3 to 2.3a we got almost doubled the RPS (requests per second) and it was clear that the solution needs further optimizations and we get get much better.

I must say here (I think the ones of you who know how the IT business works will agree) that lot of the companies do not cover the optimization in their products at all, especially the free ones, because it needs a lot of time and experiences and does not bring any marketing advantage. Unfortunately most of current day products are only marketing based.

Optimization approved!

Fortunately the first results from our optimizations, which took about a week of time, persuaded the management to include the optimization process into time plan and we could continue with it to further levels. From this time, each version was optimized and we got much better results than before. Each version is faster than the previous even if it contains more features which require more resources.

How do we optimize?

Currently, we use all the points stated before to find the weakest parts in our solution, for the performance optimization we mostly use:
  • Native query debugging of Kentico CMS to validate proper caching and detect potentially slow queries
  • SQL Server Profiler to detect queries not covered by our native query debugging
  • Reducing the number of data by optimizing the where conditions based in the previous steps
  • Reducing the number of queries
  • ANTS Profiler to optimize the code
  • Reducing the number of calling of most frequent methods
  • Running load tests
Our load tests currently run on a single machine which is the most common configuration, in the future we are planning to run the load tests also on the web farms.

We are also optimizing the solution for memory requirements, for this, we use following approaches:
  • Reducing the size of most frequent objects
  • Reducing the amount of code by generalizing the methods
  • Caching of the data and metadata objects
  • Creating separable modules - This will option will be introduced in the next major version and should singnificantly reduce the memory requirements of the web sites which do not need some of the modules
Memory optimization is one of our current top priorities and it would be done as soon as possible.

Want more features? Want more performance? Just give us some time please ...

I must say the optimization process is very slow and very expensive for costs. As I said before, we are constantly improving the performance and stability, but it cannot be done at once, it is a long way run, so if you think it is still not enough, please be patient. However, in comparisson with many other products, our solution is just fine, trust me ;-).

What is current status?

I am sure you will ask me how the system performs, so here are current results, you can also see the charts of comparisson to the previous versions:

Load tests for the 3.1a version of Kentico CMS


CPU: Intel Core 2 6600 @ 2.40 GHz

OS: Windows Server 2003
DB: MS SQL Server 2005 (on same server)
Framework: IIS 6, .NET 2.0, single application instance

Page Processing:

Test covers all the base pages of the sample Corporate Site

Cache settings: Page info = 60, Images = 60
Online RPS (requests per second): 69
20 minutes test run: 73 RPS / 87,264 Pages

Cache settings: Page info = 60, Images = 60, Content = 60
Online RPS: 128
20 minutes test run: 122 RPS / 146,191 Pages

Cache settings: Page info = 60, Images = 60, Full Page = 60
Online RPS: 1,752
20 minutes test run: 1,751 RPS / 2,101,612 Pages

GetFile processing:

Test done with single image 148 kB JPEG image 1024x768, original and resized to 640 and 320 pixels

Cache settings: Page info = 60
File settings: Files in DB
Online RPS: 40
20 minutes test run: 41 RPS / 48,784 Files

Cache settings: Page info = 60
File settings: Files in DB + FS
Online RPS: 327
20 minutes test run: 324 RPS / 389,311 Files

Cache settings: Page info = 60, Images = 60
File settings: Files in DB + FS
Online RPS: 1,195
20 minutes test run: 1,066 RPS / 1,279,436 Files

As you can see, the results are pretty good and the performance is increasing with each version.

So much for now, see you at the next post

Share this article on   LinkedIn Google+

Martin Hejtmanek

Hi, I am the CTO of Kentico and I will be constantly providing you the information about current development process and other interesting technical things you might want to know about Kentico.


Martin Hejtmanek commented on

Hi satish,

We never actually tried that (Kentico CMS does not do that) so I cannot give you the exact solution. Please contact our support with the details of your current implementation, they will help you.

satish commented on

i want to know weather the g-zip is applying in the kentico system if not how can i apply the g-zip in the kentico site can u please give me the details how to implement the g-zip i tryed the g-zip of the blowery but the site is not runing its displaying the site not found its urgent replay plz

Martin Hejtmanek commented on

Hi Satish,

If you look at the charts, you can see that the performance is much better with newer versions, so my first advice is to upgrade to the newest version you can.

If you will still experience slowness, please identify the weakest places (go through the points above) and if you are able to deal with them by yourselves do that. If not, let our support know and they will give you hints.

I recommend as the first step to enable all caches and check the code of your transformations. That's the place where most of the people do their mistakes.

satish commented on

Hi i am unable to find out the problem where i am developing the site using the kentico 3.0 its loading very slowly can u please help me to increse the performance the url is its urgent plzz help me out

Martin Hejtmanek commented on

Hi Lee, I am not sure what you mean by the clustered IIS Windows Servers and why it doesn't apply as web farm, could you please be more specific? Please send the response to our support too keep this blog clean from support questions.

Lee Englestone commented on


My IT technical manager has asked me whether the Kentico CMS has built in support for cluster failover or load balancing if we were to install it on clustered IIS Windows Servers?

I have searched the Support part of the Kentico site and found no references.

I am NOT talking about the webfarm content synchronization functionality.


-- Lee

Car Hire commented on

Hi Martin,

Thanks for taking the time to reply. I understand what you are saying re the PHP, maybe once we get an understanding for Kentico works we will have a better view. I will confess we did have a php directory a while back with 800,000 records, and the only way we could get the performacnce was to export to html...

I did have a support ticket open a while back and we went through all the settings and we think we have it correct.

I am going to upgrade the server tonight from 3.1 > 3.1a

We have full page caching enabled, but I am not sure as to where the setting is for content caching ?

Once we have upgraded, I will see what the performance is like and create a ticket as you have described.

Thanks for your help.


Martin Hejtmanek commented on

Hi Scott,

Thank you for your comment.

Yes, ASP.NET web site can be very greedy if it isn't designed very carefully. At first, I would like to ask you to go through my performance tips and try to find the weakest point of your your solution. In your case you should focus on caching of the files (if you are using some large files) and on the amount of data loaded from the database, which you can find in the query log. If you are using full page caching, you should turn off the content caching which in that case just consumes memory without any obvious benefits.

If you find out that the site is fine from your point of design, we could take your site and do the profiling to see which point of our solution is the one to consume so much memory and check if we can optimize it somehow. For this, we will need the backup of your database and the project (working web site), if you are interested in this, send the information where we can download your project to our support team at Please note that we can do this profiling for you only with latest released version of Kentico CMS (currently 3.1a), so you will need to keep the project up-to-date for this. I would also like to mention that this is not something we usually provide to our clients, it is just complimentary so you shouldn't expect from us too much, we will do our best but we may also tell you that your web site architecture is not a good one for such amount of data, so be prepared for both good and bad news ;-). One way or another, we will try to help you.

We will probably create the feature of exporting the web site to static HTML in future, but I am afraid our current schedule is too short for all the new features we are planning so I cannot promise you anything at the moment.

I must say here, that it doesn't really matter if you use PHP or ASP.NET, you can always get the same functionality with the same performance if you are willing to write your code as complicated as with PHP. What ASP.NET component-based CMS brings you are all the great extensibility features and connectivity with just everything you name. You can think of just anything in the future and you get it, this is something that PHP can never get you. Of course, all these features are for the cost of performance, it is the same like when you compare good old Atari games with current time Hi-tech gaming experience, good things must run on a good hardware. For this reason I don't like to compare languages if the architecture of the solution isn't exactly the same.

At the end, I would like to quote an Evangelist of Czech Microsoft who we met on friday, I think it was the best description how the most of the companies works I ever heard ... and with my previous PHP experience, I must say it is very true ...

"At first, they think how the PHP is great. They create a simple static web site with PHP using code segments from various forums. Then they ask how to connect their web site with their external system (or anything). When they find out it would cause them too much trouble, they double the web site development price by reimplementing the site in ASP.NET So at the end they all have ASP.NET web sites for double price than usual and their competitors who started with ASP.NET are happy to use the other half of the money for something else."

So I say: It is nice to use PHP if you can get you hands off the project as soon as you finish it, otherwise, you may get into serious trouble in future.

Just to summarize:

1) Try to identify the problem with memory yourself
2) After you do that, provide us with your project if you like
3) We will do the analysis and profiling and give you the feedback


Car Hire commented on


I have read your blog on the performance of Kentico CMS and find it of great interest. We have a website using the latest version of Kentico. The site has approx 6000 pages hosted on a dedicated server with dual CPU and 2GB ram. Most of the pages are static pages.

We find that the performance can be quite slugish, it does not appear to be CPU issue, but a memory issue, the site usually uses over 1.5gb of memory.

We have enabled what we think is all the correct caching options, and use full page cache for 95% of pages.

Our concern is that we are looking to upgade to a server licence, and will need to host 5-6 similar sites with the same amount of pages. At the present situation I cannot see how the server would be able to handle this.

I would like to suggest that maybe you could arrange for yourself or your engineer to evaluate our setup, find out if we are doing anything wrong etc, and maybe use the results to post a new blog on the subject.

Also, I think a great feature which I am not sure if its possible would be to export the entire site into static html pages, I think this would be a huge performance benefit. We would be quite happy to do a new export for example on a weekly basis to take into account any new changes / pages etc.

We are quite commited to Kentico CMS, we have found it to be the best CMS on the market in terms of functionality, ease of use etc, but do find the performance to be an issue. We have a PHP CMS site that has over 400,000 pages and runs like a rocket on a single cpu machine with 1gb ram.