Personalized content causing page response time to increase by 10

Personalized content causing page response time to increase by 100ms per personalized page/block in a contentarea

Thor Henden Silden

Vote:

Hi everyone,

We have a pagetype which uses a contentarea

public virtual ContentArea TextContentArea { get; set; }

Which is output like this in the .cshtml

@Html.EditAttributes(x => x.CurrentPage.TextContentArea)
@Html.PropertyFor(x => x.CurrentPage.TextContentArea)

When publishing a page of this pagetype, with about 10 pages in the TextContentArea, the response time for the page is less than 100ms, which is great. Now, what we have observed is that if we personalize 1 of the 10 pages, the response time increases about 100ms. And by personalizing each of the 10 pages in the contentarea with its own unique visitor group, the page response time increases about 1 second.

First we thought this could be because we used a custom visitor group criteria, QueryStringCriterion, in the visitor groups we have created, but we have observed the exact same behavior by using visitor groups that only uses the criterias that come with EPiServer CMS 7.1. Seems like once you add personalization, EPiServer personalization logic kicks in, and the more you have personalized on a page, the more time the logic takes?

The increase in page response time per personalized block/page in a contentarea is a problem since the customer plans to use personalization quite extensively. For example one page has 36 personalized pages/blocks in a contentarea, and the response time for this page is 3,6s++. The goal is to keep page response times below 1 sec. The added response time per personalized block/page is a huge problem when performance testing, as the CPU hits the roof pretty quickly during a normal load scenario as many pages have personalized content.

I would appreciate suggestions on possible causes to this, where to debug, possible fixes, etc, anything really :)

#80713

Jan 30, 2014 11:35

Mark Everard

Vote:

This is an interesting post and a really difficult technical challenge.

Serving a personalised page is always going to require more CPU than serving the same page to every user. For each and every request the server has to work out who you are and what specific content to serve. This takes CPU time.

I doubt this is caused by a bug, so there won't be an 'easy' fix. What I'd suggest is you look slightly further up at your page and system design, and try and optimise there.

Can you reduce the server load for other non-personalised assets / content, allowing your CPU time to be focussed on the personalised areas, with everything else served via cache. Donut caching is an interesting technique here, along with properly caching static files.
Could you limit the amount of personalised content on each page. This might not be possible, but there has to be a trade off between performance and personalised features, especially when aiming for a one second render time.
Could you redesign the pages to make them simpler? Some user interface designers don't consider performance. They should, especially on an e-commerce site.
Could you throw more tin at it. I'm not sure what load your site operates under, but if you need fast response times and heavily personalised pages then you will need a 'beefy' set of servers. Time to get the site in the cloud, so you can elastically scale :)

Good luck!

#80720

Jan 30, 2014 13:06

Johan Björnfot

Vote:

Could you run the page with personalized content under a performance profiler? Hopefully that would indicate which code that takes time, e.g. to figure out if it is a specific critera or similar.

#80721

Jan 30, 2014 13:07

Thor Henden Silden

Vote:

Hi,

Sorry for taking so long updating this post.

Mark, thank you very much for your suggestions, they were very useful input!

This is what we have done so far:

1. We doubled (from 2 to 4) the numbers of CPU's on both frontend servers, and that took the average response time (during a normal load scenario), from 13,1seconds to about 3-3,5 seconds for a page with 4 content areas and 36 personalizations in total within these 4 content areas. With no load it takes 1 user about 3 seconds to load the same personalized page. Trippling the amount of CPU's had no additional effect.

Now the servers can at least handle the amount of pages it needs to serve per hour without page response times going through the roof. The problem that still remains is getting the response time for 1 page request from 3 seconds to below 1 second.

2. I ran a performance profiler on a similar page in my development environment, and from the result i could see that the following call took alot of time, once per content area:

EPiServer.Web.Mvc.Html.PropertyFor
->ASP.episerver_cms_views_movetoplatform_displaytemplates_contentarea_ascx.__Render__control1
->EPiServer.Cms.Shell.MoveToPlatform.PersonalizedContentAreaExtensions.RenderContentArea

Johan, I have sent the performance profiler file to support.

Limiting the amount of personalized content on a page might be an option. My next step is to see how many personalizations it takes before reaching the 1 sec page response time requirement, then running a load test on that page. That would give an indication as to where the trade off between performance and personalization is.

#80996

Edited, Feb 06, 2014 15:36

Thor Henden Silden

Vote:

I have done a preliminary upgrade of the solution to EPiServer CMS 7.5, which has added a cache layer to personalization/visitor groups. The HTML request of a page with 25 personalizations dropped from 3-3,5second to 400-800ms.

#81326

Feb 14, 2014 10:53