Slow loading times on Preprod on DXP (with ImageProcessor)

Join us this Friday for AI in Action at the Virtual Happy Hour! This free virtual event is open to all—enroll now on Academy and don’t miss out.

AI OnAI Off

Home / Forums / Developers (Main Products) Forum / CMS 7.5 - 11 /

Slow loading times on Preprod on DXP (with ImageProcessor)

Salmin Skenderovic

Vote:

Hello!

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:

Request:

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.

Preprod:

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

SW.js:

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.

ImageProcessor:

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?

Versions:

-----------------------------------------------------------------

TAGS: DXCWarmupDelay, ImageProcessor, CloudFlare, DXP, DXC

#218574

Edited, Mar 16, 2020 16:12

Salmin Skenderovic

Vote:

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.

#218670

Mar 18, 2020 11:38

Vincent

Vote:

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.

#218706

Mar 19, 2020 0:47

Salmin Skenderovic

Vote:

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.

#218707

Mar 19, 2020 2:17

Vincent

Vote:

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)

https://world.episerver.com/digital-experience-cloud-service/self-service/self-service-troubleshooting/

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

https://github.com/javafun/EpiserverImageProcessorCacheExample/blob/master/EpiserverImageProcessorCache/config/imageprocessor/cache.config

#218710

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.