Sitecore 6.3 Performance Update

If you read the comments on my last post you’d see my memory was a bit fuzzy in regards to the Sitecore roadmap. Just to clarify, I got it wrong and Sitecore 6.3 is not the release to support massive amounts of content. And thanks to Adam Conn from Sitecore who has also clarified that “massive amounts of content” means millions of content items. It was Thomas Eldblom who mentioned the codename under which this feature is being developed; “massif”. Ah yes, I vaguely remember something about that name… So the premise of my original post was wrong. But I think it’s good to have this data which supports the claim that Sitecore 6.3 performs better than Sitecore 6.2. Another commenter, KenB, queries about the odd artefacts we saw in the Sitecore 6.3 performance for querying by name. So I thought I’d investigate that a little more and see if this artefact was actually the way Sitecore does perform or if this was more just a case of a noisy computer. Here’s the graph of Sitecore 6.2 vs Sitecore 6.3 for performance of querying a child item by name.

As you can see, the query at 1000 items for Sitecore 6.3 looks to be much larger than expected, especially when compared to the Sitecore 6.2 case which is a pretty flat line. So I did some more testing around this point to see if Sitecore does actually perform this way.

It would appear that it does. Keep in mind the scale of the y axis here. We’re looking at milliseconds difference between the data point at 1000 and 1250. But we can definitely see the curve flatten around the 1000 mark. Let’s have a look at these results mixed with those from my original tests for query by name.

We can still see the performance for query by name drop off slightly at about 1000. But now we realise this is not the “massif” release, then we’d follow Sitecore guidance and restrict our content trees to have no more than 100 child items in any location. I should also point out that the above results were taken for fresh, new data. Sitecore has a lot of caching to improve performance and subsequent queries return much quicker than the original query. The data above is from the first query. For each set of tests I dropped all data (find rm) and recreated the data (rep 1000 create).