Try our conversational search powered by Generative AI!

Slow loading times on Preprod on DXP (with ImageProcessor)



We have noticed a weird behaviour on Preproduction on DXP. The enviroment is very slow sometimes and I can replicate the behaviour by changing Query-params. Se below:


1 - Old request. Width=350 is the default URL for one of our images.

2 - After I manually change the Width to something new. 374 has not been used before and therefor the request takes a bit longer as noticed.

3 - I refresh the page. The request now takes almost a full minute to load. This is what we are struggling with - to figure out why.


If we run the same code and DB on Integration we get these results:


We had the same problem before we implemented the serviceworker, and have the SW.JS on both enviroments - so it shouldn't anything to do with it.


We are going to try to override some default behaviour to put timestamps on the processor to see if it has anything to do with this. But we do run the imageprocessor on our local dev enviroment and Integration, so it shouldn't be at fault?

CloudFlare CDN-cache:

Checking the Request Headers on request #2 it says:
cf-cache-status: MISS

But so does Request #3.
It is as if the second request tells DXP to serve the CDN-Cached image on the second request, but the CDN is not ready yet?

<package id="ImageProcessor" version="2.8.0" targetFramework="net472" />
<package id="ImageProcessor.Plugins.WebP" version="1.3.0" targetFramework="net472" />
<package id="ImageProcessor.Web" version="4.11.0" targetFramework="net472" />
<package id="ImageProcessor.Web.Config" version="2.6.0" targetFramework="net472" />
<package id="ImageProcessor.Web.Episerver" version="" targetFramework="net472" />
<package id="ImageProcessor.Web.Episerver.Azure" version="" targetFramework="net472" />
<package id="ImageProcessor.Web.PostProcessor" version="1.5.0" targetFramework="net472" />
TAGS: DXCWarmupDelay, ImageProcessor, CloudFlare, DXP, DXC
Edited, Mar 16, 2020 16:12

It seems like disabling the property fcnMode (fcnMode ="Disabled") in web.config fixes the problem.

My theory is that rendering an image with parameters that has not been rendered before, like changing width from 830 to 840, triggers a restart of the app service and that is why we saw "DXCWarmupDelay" in AI.

Mar 18, 2020 11:38

Hi Salmin

What's the old value specified in your config? I'm curious what has been done in your CMS triggers the app restart. In theory, when app restarts, there must be many files changed triggers Overwhelming File Change Notifications.

Mar 19, 2020 0:47

Hi Vincent,

Old value: <httpRuntime targetFramework="4.7.2" requestValidationMode="2.0" fcnMode="Single"/>

I think that because we use ImageProcessor, it saves a copy of the new size to disk, which triggered the App restart.

Mar 19, 2020 2:17

Hi Salmin

That's interseting. When fcnMode is set to Single, it should drastically reduces the chance of overwhelming File Change Notifications. I think the biggest issue in your solution is to save the copy of new size to disk

Episerver highly recommends to store code only within the WebApp, all contents should be stored in Blob storage (see more details from link below). You'll experience unexpected bebaviors like stability and performance issues once your app exceed / close to the upbound limit 900MB (this is current DXP setting according to the doc)

I suggest you switch to Blob cache provider in preproduction and production environment, the ImageProcessor cache config file can be located at /config/imageprocessor/cache.config

Edited, Mar 19, 2020 5:32
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.