Update 1: The bug is fixed in .NET 4.7.1 (thanks to Pascal van der Horst for the information)

Update 2: The related bug is fixed in CMS Core 10.10.2 and 9.12.5. If upgrading to that version is not an option, you can contact Episerver support service for further assistance.

Original post:

If you are using Episerver and update to .NET 4.7 (even involuntarily, such as you are using DXC/Azure to host your websites. Microsoft updated Azure to .NET 4.7 on June 26th) , you might notice some weird performance issues. If your servers are in Europe, Asia or Australia, then you can see a peak in memory usage. If your servers in North America, then you can see the number of database calls increased. In both cases, your website performance is affected, the former can cause your websites to constantly restarts as memory usage reaches a threshold limit, and even more obvious in the latter. Why?

It was a known issue in .NET 4.7, as mentioned here: https://support.microsoft.com/en-us/help/4035412/fix-expiration-time-issue-when-you-insert-items-by-using-the-cache-ins

So TL;DR: when Cache.Insert is called with absolute expiration policy, it inserts a cache entry with a time of expiration. It’s supposedly to be in UTC, but a bug in .NET 4.7 caused the entry to be added with local time. So you can see the problem here: if you are in a GMT+n timezone, the cache entry will stay for much longer than the intended time (for example, 2h15m instead of just 15m). And if you are in a GMT-n timezone, the cache entry will immediately expired as soon as it is added, render the caching useless. The only exception is if your server is in UK – GMT+0, then the cache expiration will work as it should.

This, however, does not affect the cache entries added with sliding expiration policy.

Of course, this is bad. But can you do something about it? Sure.

  • If you are hosting on your own servers, hold off installation of .NET 4.7 until further notice.
  • If you are on Azure, where .NET 4.7 is inevitable, then you have several options:
    • Wait for Microsoft to fix it. Microsoft acknowledged the issue on July 19th, but there has been no updates since.
    • Wait for the next version of CMS Core. There is a fix which mitigates the issue.
    • Or you can try this workaround by overriding the default implementation of IObjectInstanceCache.

And a custom implementation of ISynchronizedObjectInstanceCache :

Now you can see this is an obvious workaround: RemoteCacheSynchronization is a class in Internal namespace, so you should not be using it in your solution. However, this is a circumstance where it’s justified to do so.

And then register this class as the implementation of IObjectInstanceCache and ISynchronizedObjectInstanceCache in one of your IConfigurableModule. To the best result, make sure this module has ModuleDependency on FrameworkInitialization

When Microsoft releases the fix for this issue, or when Episerver releases a fix for CMS Core for this issue, the above workaround should be removed.


Valdis Iljuconoks · August 3, 2017 at 3:07 pm

good catch

Pascal van der Horst · August 8, 2017 at 4:36 pm

They fixed the Cache.Insert leak in .net 4.7.1 build 2538.



“Fixed bug with absolute expiration time when using System.Web.Caching.Cache.Insert(). [453771, System.Web.dll, Bug]”

Hopefully the will release it soon for all Azure Hosting Platforms.

    vimvq1987 · August 8, 2017 at 10:32 pm

    Thanks for the information

Leave a Reply

%d bloggers like this: