The challenges of a high traffic site with EPiServer

…with an unconventional approach to data fetching.

This article is a first of a series describing the faceted navigation system for EPiServer that we have internally developed in Cognifide and that’s already proven to be a robust solution for delivering tagged content a heavy traffic site, which will be released shortly as an open source project. The article outlines some pitfalls of EPiServer that we’ve run into and the nature of the project in which the module was used first and which influenced a lot of our design decisions.

This article and the Faceted Navigtation module is developed on EPiServer 4.61 and not the latest version 5 of the CMS so far, so mind that some of my reservations may not be a problem if you’re just starting to work on a brand new project and have the luxury of using new features of it.

Also (which may be a good thing) our sites uses a different approach to navigation the content, we do not really care much for the tree structure, but we treat all EPiServer pages equally when looking for content because of how the site is designed from the creative point of view.

The project is a vast site with:

tens of editors working on it simultaneously.
millions of uniques per month
tens of thousands of articles in just about half a year
5 IIS servers working in tandem on a single SQL database
The page cannot be cached as a whole as it contains dynamic and Geo-targeted content.
The content on the page changes every other minute or more often
There is a great deal of automated content coming from various feeds.
A content can be both feeded automatically based on the time of publishing as well as forced in some controls and no article can appear on a page twice, yet controls have to have predefined number of links. May not seem hard to do, but believe me once controls will start stealing articles form each other you’ll see why I listed it as a main feature.

First thing to give the credit where it’s due – let me enumerate the good sides of using EPiServer in the scenario (the parts that we found particularly useful):

EPiServer provides a beautiful interface to the editors. Both for editing pages and organizing the content.
EPiServer provides a great infrastructure for us to plug into it with property types, and GUI plugins
EPiServer allows us to use as much or as many of its elements as we need – from our point of view we mostly use it as a repository and pretty much ignored all of its custom controls and a great deal of its APIs (which I’ll explain later why.

The list does not seem like a long one – but believe me – all of the points are fundamental to the success of the site! The editors love the UI, the developers love the extensibility and “pluggability” of the APIs. And the logical structure of the database allowed us for flexibility in skipping some APIs where it proved that a direct database call was beneficial.

The bad part is basically that the EPiServer API is slow for what we needed it to perform (the site can easily reach a couple of thousand simultaneous connections at peak times), if we wanted to use GetPage() for every link on the site we would be in serious troubles. At our average of 155 links per page, this was a serious problem.

Also since we have a structure of the tree that is not directly reflected on the site, but rather we search by “categories”. The idea of the site is that it is a huge search engine that displays the freshest content content based on the facets it is tagged with. Using the EPiServer APIs we would have to use FindPagesWithCriteria() which in itself is probably the most disliked call speed-wise. Also categories in themselves do not support any metadata (there are no properties for categories). Needless to say – we had to implement our own code for this kind of creative approach and that’s what we did.

In effect, what we limited to the list of hardest abusers are:

FindPagesWithCriteria()
Getpage()
GetChildren()
and (mostly based on Mat’s article) use of dynamic properties.

Basically all the calls that return PageData or PageDataCollection are all potential candidates for heavy caching.

The main approach that we took in our solution is “cache the hell out of it, but do it smart”. Don’t cache PageData unless there is absolutely no other way. Cache links, page titles and data that’s potentially used on every page.

Also where needed and justified by the speed increase we reach directly to the database – skipping some EPiServer APIs (At this point this is just one call as we want the solution to be easily portable between various EPiServer versions).

More (and the solution) coming shortly…