Help shape the future of CMS PaaS release notes! Take this quick survey and share your feedback. 

Scott Reed
Nov 28, 2018
  3377
(7 votes)

Scheduled jobs in the DXC & The Autoheal Policy & Architecture

Scheduled jobs are a great way to write code that can run periodically and perform actions on your CMS or Commerce system through the Episerver API framework https://world.episerver.com/documentation/developer-guides/CMS/scheduled-jobs/ I have often used these to much success but in our latest project we needed to do some heavy CRUD syncing of data from 2 of our clients large systems in to the Episerver Commerce catalog structure.

We chose to use Scheduled jobs as we could use the API and we needed to do a few other things, we knew the jobs would be intensive but when we came to test some of this on the DXC we kept getting an issue with our largest fresh import of data.

The jobs were getting aborted, so we contacted Episerver support and were informed that Azure Auto Heal was turned on https://blogs.msdn.microsoft.com/appserviceteam/2017/08/17/proactive-auto-heal/ for the environments. Auto Heal will work out if instances have an issue and restart those instances however one of the thresholds it checks was memory usuage and for us the large fresh import was hitting this issue with memory due to the massive data set we were working with.

There are 2 options for this and around architecturing jobs that will cause heavy processing.

To note Episerver Support told me if you have a commerce site they can create another web app for this at no extra cost.

SO As a thought I'd suggest whenever using Scheduled jobs to consider how much data you are processing and how intensive they are and to consider separating jobs out as standard on the DXC to help mitigate any of these issues.

Nov 28, 2018

Comments

valdis
valdis Nov 30, 2018 05:02 AM

nais! I just love these healing policies. we are too lame and lazy to deal with high memory usage (or actually it was app intent to use as much as possible and troll GC) but there is always an easy way - just restart damn thing and move on.. :)

Magnus Rahl
Magnus Rahl Nov 30, 2018 02:39 PM

ICYMI there has been a long standing bug in ASP.NET which prevents cache trimming to run correctly, see my blog post here: https://world.episerver.com/blogs/Magnus-Rahl/Dates/2017/11/bug-in-aspnet-cache-causes-problems-with-azure-proactive-auto-heal/ This results in ever-growing cache when an application runs under memory pressure. Things in epi are cached with timeouts, invalidated when updated etc, but when churning through big data sets it does depend on the LRU algorithm of the cache trimmer to free up memory. The ASP.NET bug has been fixed in .NET Framework 4.7.2 but that fix is still not rolled out to Azure app service in all regions (but should be any day now). 

Please login to comment.
Latest blogs
Be careful with your (order) notes

This happened a quite ago but only now I have had time to write about it. Once upon a time, I was asked to look into a customer database (in a big...

Quan Mai | Feb 5, 2025 | Syndicated blog

Imagevault download picker

This open source extension enables you to download images as ImageData with ContentReference from the ImageVault picker. It serves as an alternativ...

Luc Gosso (MVP) | Feb 4, 2025 | Syndicated blog

Optimizely SaaS vs PaaS: A Comparison from Client and Developer Perspectives

Optimizely, one of the leading digital experience platform. Offering both Software-as-a-Service (SaaS) and Platform-as-a-Service (PaaS) solutions....

Praful Jangid | Feb 3, 2025

Returning to Optimizely After Many Years

Returning to Optimizely After Many Years: A Journey Through Its New Features After several years away from Optimizely’s Content Management … More

Jose Neto | Feb 2, 2025 | Syndicated blog