ASP.NET Cache memory bug fixes released

Fixes for two bugs I found in ASP.NET Cache memory management are included in .NET Framework 4.7.2 which was released today (download here). The two bugs would under most conditions allow the ASP.NET Runtime Cache, used heavily in Episerver applications, to use up almost all memory. In Azure Web Apps (and therefore in DXC Service) this would in turn cause unnecessary application recycles because of how the Proactive Auto Heal feature (enabled by default) reacts to high memory usage. You can read more in my previous blog post.

While you can download and install the update today on servers you control yourself, it will be some more time before the update is desployed where it is needed the most, on Azure Web Apps. There is no definitive time table for this, but there is a github announcement and discussion. A possible estimate might be drawn from the previous deployment: .NET Framework 4.7.1 was released 2017-10-17 (source), Azure deployments started around 2017-12-04 (source) and were complete by 2018-01-05 (source).

In the meantime I strongly advice sites to continue to use the workaround (explained in my previous blog post) of setting the cache's privateBytesPollTime setting to 29 seconds and explicitly configure a percentagePhysicalMemoryUsedLimit, 90 % or below to stay clear of Proactive Auto Heal, e.g.

<cache percentagePhysicalMemoryUsedLimit="80" privateBytesPollTime="00:00:29" />

Update 2018-05-01

If possible, also consider updating to CMS 11.1 or later. From that verison, a much shorter cache timeout is used for items inserted through scheduled jobs. There is also a new API making it possible to control the Content cache timeout for a specific call, e.g. when doing a batch read of large amounts of content that you don't expect to be accessed very often.

For any CMS version, you can also consider configuring the pageCacheSlidingExpiration option of the episerver config section. The default for this option is 12 hours, which considering it is a sliding expiration, is probably overkill for most applications.