.png?width=667&height=667&ext=.png)
Is Kentico 10 Performance for Real?
Introduction
Last month's launch of Kentico 10 included some notable new features and enhancements to the Kentico EMS platform. I mentioned most of these items in my wrap up of the best Kentico month ever in my last post. However, one item stands above the rest in terms of enterprise scalability and high end performance. That item in my mind is the statement that "version 10 of Kentico can now handle 100 million contacts and one billion activities"
Let that sink in for a few seconds, because that’s billion with a "B". That is a big statement, but exactly what does it mean? As a long time Kentico user, I have long been aware of the performance best practices that Kentico has published over the years, and a few unpublished hidden gems as well. So when I hear the word "handle" next to performance, I immediately start to think that it could be taken as a broad statement. My curiosity got the best of me, so I reached out to Michal Kadak, platform product owner at Kentico, and asked him to explain that statement in a more detailed way.
Seeing is Believing
To my surprise, Michal replied to my inquiry with a thoughtful reply asking me what exactly I was interested in. I told him that many people in the Kentico developer, partner, and end client community would love to know more details on the performance of Kentico 10. For instance, how the system performs from a day to day standpoint with that much data. I was also wondering what made Kentico 10 so special when compared to previous versions of the platform. Not long after our initial conversation Michal volunteered to not only answer my questions, but do me one better in terms of showing me the actual live site that Kentico had used in its performance benchmarks. My reply to that was "Hell yeah".
Over a remote session, Michal and I met and reviewed a Kentico 10 test site that was close to the one the internal Kentico team used for the final benchmarks. We were able to walk through the live site and the admin interface. But before I go into the details let me throw out a few stats for the site.
- The Kentico Dancing Goat starter site was used in our demonstration
- The site was loaded with 100 million contacts and around 1 billion activities
- The site was hosted and running in Azure
- The database size of the demo site was 1.8 TB
- The site was running in a web farm with 1 server configured (more later on this)
That is some serious data and serious horsepower!
In our review, we first looked at the live site performance first. After a fresh re-compile, the Dancing Goat site home page loaded pretty much the same way any other Kentico side would. There was a tiny bit of a browser spin time and then the site loaded right up. There was no long delay to prime the cache as you might have expected. It kind of just worked in about the same amount of time that any other Kentico site takes. We navigated around a few pages and the site performed just like I would have expected. I would say it easily passed the first test in my mind.
We also discussed the high level technical details of how Kentico 10 was able to achieve the performance increase. Basically, it all boils down to the work that the Kentico development team has put into optimizing the Contact Management, Activity log, Segmentation, Personas, and Lead Scoring apps that are part of the digital marketing solution. Huge amounts of data can be stored, collected, and used without affecting the live site performance. The team put time into optimizing both the C# code and some SQL database table indexes.
This is an important point because I have personally been a part of projects that have had millions of rows of data in the contact and activity tables and there was a slightly noticeable difference to first load page load time when the on-line marketing setting was toggled on vs. off. To Kentico's defense these projects were in Kentico 7.0 and Kentico 8.0 mostly.
Kentico 10 Admin Interface Performance
The live site is only half the battle right? Not only do we have to worry about end customer experience, but we also need to think about how the Admin interface behaves with this much data in it. In the past this has been an Achilles heel of Kentico when it comes to the edge case of having millions of rows of data in the on-line marketing database tables. Although I would argue that there is very little need to keep that much data in a real world site, even if it is a hugely trafficked site. Do you really need to look at data that is older than 6 months for anonymous visitors that could be bots? In my experience the answer to that question is no.
Pro Tip: If you haven't been cleaning up your Kentico online marketing data, check out my post on getting rid of it, and also on 11 Spring Cleaning Tips for Kentico.
Once we logged into the admin interface and navigated from the admin dashboard to the Contact Management app I got my first taste of what 100 million contacts can do to a system. I'm not going to lie, sugar coat, or exaggerate it. It did take about 5-10 seconds for the UniGrid to load up that many contacts. That amount of time might seem like a lot, however, in version 8 and possibly even version 9, this screen would simply have timed out and never finished loading. It is nice to know that the system can now handle this obscene amount of data.
Paging through the records worked as expected to. However, Sorting and Searching was a different story though. The thing is, at this point, when you have that much data, the key performance bottleneck is not actually the application layer (Kentico / ASP.NET), it’s the database layer (SQL Server). If you are a Kentico partner, developer, or end client and want to support sorting and searching actions on huge datasets, it will be up to you to add more indexes in SQL for your specific use cases. Which, honestly, is probably not a bad thing.
Kentico 10 Documentation
In my conversations with Michal about Kentico 10 performance he mentioned that Kentico had been working on a new best practice document that defined the performance ability of Kentico in a very detailed way. I was happy to see a copy of this documentation. I can't recommend it more for any Kentico user, developer, or partner who needs to develop and/or maintain a large Kentico site. If you fit this criteria, stop what you are doing right now and go read Best practices for EMS performance.
Pro Tip: Kentico 10 Performance Best Practice documentation is now live in the newly redesigned docs.kentico.com
Kentico 10 Performance is for Real
At the end of the day, you don't have to take my word for it, or even the Kentico documentation. You can simply look at the proof via the screenshots I have taken during my review of Kentico 10 with Michal. One other thing to note. As I mentioned above this starter site was running with only 1 web farm server. Michal mentioned that in the real benchmarking that Kentico performed they were running 3 or 4 servers in a farm and were able to acheive even more throughput. That's pretty impressive.
Conclusion
Let me also point out one thing that has always impressed me about the people behind the brand at Kentico software. It doesn't matter if the person that you are talking to is in sales, support, product management, or a C level executive. Any one of those people will take the time out of their busy schedules to (when possible of course) answer your questions and generally help you however they can. The help and advice that they give is also transparent and straightforward. I have always appreciated their approach and it goes a long way in reinforcing our partnership at BizStream with Kentico.
