For a very long time, some very serious performance issues have affected certain types of Sitecore deployments. It has to do with scaling a Sitecore solution into webfarms (multiple content delivery servers) and the use of the Sitecore Staging Module.
In very short summary, if the website is updated frequently (say, for instance, an editorial staff of 10 or so, posting relevant market updates) AND the website is under heavy load, most practical uses of the tool Sitecore recommends and supports will more or less kill performance on your SQL Servers or whatever storage mechanism you have in place.
I’ve never blogged in detail about this issue, as I didn’t have a client myself that was affected directly by this issue. Paul George has blogged about it in detail however, and if you want to learn more about what this issue is and if it could be affecting you, take a look at these posts:
- Problems with Sitecore and the staging module part 1
- Problems with the Sitecore 6 staging module part 2 – extranet user loses session
So why write about it now?
The good news
Alex Shyba posted about a new Sitecore Shared Source module that was just made publically available; SitecoreStager – Sitecore Partial (item) Cache Clearing Module.
In short, instead of just uncritically clearing the entire cache on your target server, dropping user sessions, putting out the cat and so on – the SitecoreStager will instead execute a partial cache clear and in essence just clear items from the cache that were affected by the publishing operation.
This is very good news indeed, and for those clients who have been affected by this problem I am sure it’s tipped hats all ‘round :-)
The bad news
This is actually something that has been nagging me a bit for some time now, and has just been refreshed by this release.
It is Shared Source.
Don’t get me wrong. I think the Sitecore Shared Source Library is an excellent idea. I have code in there myself, and it’s a perfect place to go look for those “there has to be someone else who had this problem and solved it” code snippets and field types and whatever it may be.
But it is also, for obvious reasons, unsupported by Sitecore themselves. I mean, how could they? Half the modules and code pieces in there come from independent sources like myself – and it wouldn’t be reasonable to expect Sitecore to support them.
But what about the code Sitecore release to the library themselves?
Would you not agree; “With Sitecore, you can have a team of editors publishing content to an enterprise level site, and performance will still rock” is a statement you’ll find (albeit probably not verbatim) in Sitecore marketing material? But it is unsupported?
I feel somewhat the same for the Multiple Sites Manager… shouldn’t a standard Sitecore have a solution for regular (advanced) editors to set up new websites without having to edit configuration files? Or is that limited to Foundry licenses only?
What I mean is
Sitecore marketing materials doesn’t exactly help anyone much, when they boast “Comes with Blog Modules, Wiki Modules and even Microsoft Dynamix and Microsoft BizTalk integration (yes…)”; yet offers little or no actual support other than pointing the users, the licensees, the Sitecore implementors (like myself) in the direction of the Shared Souce Library, shrug and go… “From here, you’re on your own”.
Kudos for making this module. I think this belongs in the core package however, fully supported and updated with every Sitecore release. That’s my 2 cents worth.
We can imagine that you feel a bit unconfortable around being the module a Shared Source module.
It's a module based on the need from our clients at this moment.
Our product department is going to address these needs as soon as possible as well, but for this moment, our solutions team came up with such a solution.
This means that we're able to help the customers out now, while we can work on an integrated solution for the long run.
Both scalability / staging module and multisite support are on our radar and will be adressed in our upcoming releases.
Thank you, as usual, for your critical note. We feel with you, but we also try to do our very best to help our customers now and not only tomorrow :).
Alex de Groot
Thanks for your blog post!
Just to add to Alex's comments, we thought about how to release it and shared source was the most obvious decision because there is no one way to solve cache clearing notification. Some customers want to use "pull" approach, others want "push". Releasing this component as a shared source gives one benefit - implementers can use this as an example and simply implement the same code in a bit different fashion, for example a scheduled agents that clear caches on a timely basis if a publishing operation occurred.
Plus as Alex already mentioned, this functionality will be included into the core product soon, so we decided not to deliver it as another official module which could conflict with Staging module.
As a side note, this component is being currently used for a number of clients in production so it is in a very good shape.
Post a Comment