SharePoint Performance – Blob Cache and Image Renditions could be the bad guy

The Problem

We’re running quite a big SharePoint Environment and using SharePoint 2013 also for Web Content Management.

In order to monitor the performance of the system, we have build a couple of web tests with Microsoft Visual Studio and are running those configured as Load tests regularly. First of all, this is a very recommended setting if you are hosting a system with heavy load or specific performance goals.

So, surprise surprise, we ran into performance issues with the environment specially since the usage of the platform is very heavy and the Visual Studio Load test results did not meet our predefined goal.

So next step, lets check the usual stuff:

https://www.usetheweb.ch/sharepoint-2013-performance-optimierung/

Nope, no help there. It wasn’t the custom .NET Code, it wasn’t the servers with high CPU / RAM usage, it wasn’t the database; response times were fine. Etc.

Consulting the Devloper Dashboard (https://www.usetheweb.ch/troubleshooting-sharepoint-2013-developer-dashboard/) actually did not help either.

Somewhen we had a look at the IIS and the corresponding worker processes beneath. We did monitor the IIS Processes on the servers and found out a very interesting fact: We had a very very high amount of Garbage Collector Calls! Actually in our big environment it seemed that the deadly “GC.Collect” command would be called even more than once per second!

To wrap this up: the .NET Garbage Collector did a lot of cleaning and the process itself therefore was quite “disturbed”, let’s call it that way.

So finally there was a firm lead! Yeah!

We were able to point out the “Bad Guy” via stacktrace. Somehow the generation of image thumbmails (SharePoint Image Renditions) did cause those events. To be more precise => Almost every call to an image over the web platform did Couse a GC.Collect Event!!

Further investigations proved the fact. This is an still open bug which is shipped out with SharePoint 2013. And to make things even worse, we tested the behavior also on the new version, SharePoint 2016 On-Premise. Even there, the problem persists.

To reproduce the issue

User opens SharePoint Intranet => WFE Requests Image from Blob Cache => Images with Image Renditions are generated and returned => This leads to a .NET GC.Collect Event

The solution

So to make a long thing short:

There’s currently no solution for this issue but a workaround, which will reducy the pains to a minimum.

The workarround

So let’s repeat again: Almost every request to an image on our SharePoint 2013 platform (WCM) brought the .NET Garbage Collector to life.

With the help of Microsoft we at least could identify a workaround. Fun fact here was that the Blob Cache doesn’t cache draft versions of images! And in our environment, we used the Publishing Template as a starting point and the Image Libraries where actually configured with Minor and Major Versions, leading to the fact that most of the images did not have a Major Version.

So as a workaround => Make sure that all Images are published as Major Version!

This will still lead to a .NET GC.Collect event, but “only” once per image; as soon as the image is on the BlobCache, you’re happy to go

Summary

If you’re on SharePont 2013 / 2016 on Premise and using the BlobCache with Image Renditions, make sure your pictures are published as Major Version!