The development of SharePoint's core engine back in the days

SharePoint’s core engine: as slow as it is old

After so many years of dealing with performance issues in SharePoint onpremise and seeing the slowness of SharePoint Online, I had to write about it, just only to feel better! 🙂

SharePoint’s core engine is old, very old

Back in the days, it was put together in DotNet, which is not the fastest of technology. On top of that, from SharePoint Portal Server 2003, SQL Server was used to host files. The old 5000 limit threshold tells about how badly the core engine was designed. Even the schema of the content databases has not changed for years.

SharePoint’s APIs are extremely slow

This has consequences in many areas:

1) The web interface
Just use a busy library of SharePoint Online and you’ll see by yourself.

Microsoft has developed many layers of caching to try to improve SharePoint’s performance over the years. First, there were the old Output Cache, Object Cache and BLOB Cache. Since the 2013 version, the Distributed Cache service came to the rescue. With SharePoint 2016, you even have now a dedicated server minrole just for that.
Even so now, onpremise farms are performing well, the trouble is that you cannot cache every single view of every single list for every single user. At some stage, SharePoint’s web server will have to chat back and forth with their SQL backend.

Some third-party product vendors will tell you that BLOB storage is the solution to SharePoint’s performance issue. If it was that simple, Microsoft would have done it for SharePoint Online. They are still using shredded storage, so it is not worth put the effort to go down the route of BLOB storage with all the trouble this implies.


2) The offline synchronisation
Why the old OneDrive For Business (a.k.a. SkyDrive, a.k.a. Workspace, a.k.a. groove.exe hacked together by some old folks originated from IBM) and any other 3rd party tools (GoodSync, SPSync,, Colligo Engage …etc.) just don’t work?
It is not for the lake of trying, it’s just that they are limited by SharePoint’s web APIs.
The new version of OneDrive works well(ish) just because a cache/buffer was developed between the client (workstation or mobile) and SharePoint Online. This buffer is much faster and is hosted on Azure. Back in December 2016, when I asked Jeff Teper in the SharePoint Saturday conference in Geneva if OneDrive NextGen will work with SharePoint onpremise, he just told me that there was no plan to package this piece of code for onpremise use.


3) Video Portal
As the same as the offline synchronisation issue, the Video Portal was quickly build following troubles with end-users uploading videos and sending the links to a few hundreds of colleagues.
Result: farm down or at least service interruption. OK, SharePoint is not made for streaming but still, here is the point: when it comes to getting large content for hundreds/thousands of users, SharePoint just does not cut it.


4) Which brings me to… the hilarious retro-pedaling of Microsoft, as I like to call them, about the Internet site on Office 365.
Remember, back in March 2015, Microsoft decided that well, you’ll have to use GoDaddy or to host your site.
Apart from the fact that company had to double their efforts to create a common template/look and feel between their Intranet site hosted on SharePoint and their Internet site hosted on whatever (Drupal, WordPress …etc.), it just shows how SharePoint can just not sustain the load of even a few thousand users.


5) Backup and restore: my favourite.
I am going to make an entire post about this imposture. Forget all backup and restore tools which use SharePoint APIs (pretty much all vendors have a SharePoint module) even the Microsoft Data Protection Manager (DPM). The APIs are just not fast enough to back up huge amount of data.
It was already true back in MOSS 2007, it’s even truer now with our data rate consumption. SharePoint Online is not backed up that way, and neither should you but that’s another post.


Cristal ball guess or letter to Santa Claus?

It took Microsoft a good 20 years to go from Windows 95 core engine to something which we can call a good operating system: Windows 10 (launch in July 2015).
20 years to go from one version to another. Are we going to wait that long for SharePoint? Well, we are closing in on those 20 years.

Putting SharePoint in Office 365 was the best move Microsoft has done.
Not because it saved organisations lots of trouble trying to administer the beast, but because it showed Microsoft that SharePoint really is not an industry grade product, especially not ready for the industrialised cloud.
At the same as Facebook cut by a third their datacentre resources just by rewriting their code back in the days, Microsoft has the only choice to rewrite SharePoint’s core engine as well to survive in the cloud.


Eh, I love starting rumours!

Here is one: what if the new interface found in SharePoint Online for the past 2 years, extremely bare and simple, was just the first step towards rewriting the back engine?
Change the front interface first. Then after a few years, when everyone is used to it and has forgotten about the old look and feel, change the back engine.

I wonder what would be the future of SharePoint. Time will tell…

The king is dead, long live the king!


Published by

Jean-François Pironneau

Travaillant depuis 2003 sur les versions successives de SharePoint, je me suis spécialisé au fur et à mesure des années dans la partie infrastructure/technique, puis récemment dans la gouvernance de Microsoft 365.

Leave a Reply

Your email address will not be published. Required fields are marked *