In the opening post of this series I shared basic sizing guidelines for Sitecore CEP, but if your organization intends to fully leverage the capabilities of CEP you will also need to consider the impacts of goals, conversions and events.
Governance plays a critical role in any Sitecore deployment
Learn more about Best Practices for Sitecore
Goals, Campaigns and Page Events
The PageEvents table holds a record of all page events that occur on the published site. This covers goals, campaigns and other events. Our analysis of the data in this table indicates that a single event consumes approximately 0.635 KB of space for data and indexes. While this number is not significant, it is comparable to the data required for a page hit (0.5905 KB). While nowhere as substantial as the visitors and page views it can easily add 3% – 6% to the database and can have additional impacts when you consider backup, disaster recovery and other elements.
Being able to model the page event data requirement will be largely based on supposition in the early days. If you have previous analytics, that should give you some indication of traffic that would follow a conversion funnel and trigger events. Start there. By way of anecdotal evidence, on NLC’s website there is approximately 1 page event for every 2 pages viewed.
Going back to our fictional example of a moderately busy site with 100,000 visitors / month and an average of 10 page views / session the data required for a single month was 727 MB. If we now add on 50,000 page events this will increase the monthly size by:
(50,000 x 0.635) = 31,750 KB or 31 MB
This now brings our monthly data requirement to 758MB.
Engagement plans and testing
There are many other features of CEP that can generate significant data footprint; however at this time we do not feel that we have enough information to properly model their impact. A/B testing and the engagement plans in particular are so dependent on your implementation that any guidance we can provide would potentially be misleading. Our suggestion is that you setup your plans as early as possible and then use load generation software to mimic traffic to collect actual statistics. These capabilities can generate several GB’s of data in a month.
Many of our clients duplicate the analytics data captured on the website to a second database. That second database is used entirely for reporting in order to isolate the performance load of heavy reporting from the website. If you choose to do this it will effectively double your data needs. In our fictional example our need to capture and store data has moved from 758MB to 1.48GB monthly and our total data footprint at 6 months to 8.88GB. You can see the projected growth depicted in the following chart.
For more on the topics of DMS database performance and dedicated reporting databases, please see Sitecore’s DMS tuning guide at http://sdn.sitecore.net/SDN5/Reference/Sitecore%206/DMS%20Performance%20Tuning%20Guide.aspx.
Understanding your traffic patterns, usage of events and reporting requirements will provide a reasonable estimation of your DMS data requirements. The remaining factors are projected site growth, high availability, disaster recovery and backup. These topics will be covered in my third and final post of the series.
Language of posts
Posts by date