Pages loading way slow when we have more images and skip cache layer.

[srikanthgurram-17]

In cloud instance we have an issue reported by our users that some of the pages loading way slow.

• This page has more number of images eg: we have multilayout teaser each has 4 to 6 images and this teaser is configured 14 times (approx. 60 to 70 images in a page).

• We are using AEMaacS as a headless solution. we built a json API over a sling exporter framework

• We use wcm.io media handler to build the DM image rendition urls.
  When we actually check the issue using profiling we understood that we are invoking many times media handler this is where exactly most of the time spent by the request. some of the facts during profiling check are as below:

• For the actual serialization it just took few ms as you said

• 70% mainly for resolveRenditions(media, asset, mediaArgs)

• resolving DAM renditions and resizing for media handler is where it spends most of the time. this is mainly happens inside wcm.io libraries.

1. Is there something we can improve from our side like number of invocations in a given page. eg: any recommendation from your side.
2. Is there something media handler can optimize the code ? inside resolveRenditions(media, asset, mediaArgs)

Note: This is only happening when we skip the dispatcher and CDN and directly hit publisher.(only without caching)

CC @stefanseifert

[stefanseifert]

interesting - we have to come back to this in january, i've not much time left this year.

some first thoughts/questions:

• why are you skipping dispatcher and CDN? because you are using it directly within authoring environment for edit purposes?
• can you give some actual performance numbers for different types of requests (total request run times, including the fraction that you see is spent within media handler code) for:
  ** a complex pages with 60-70 images
  ** a moderate complex page with 10-20 images
  ** a page with only one teaser and the minimum amount of images
• you are using DM - but DM is also using a "pull-cache" model, the first time an image in a new resolution is requested may take a bit until it is cached. make sure the users that perceive bad performance do not only seeing it takes a bit until DM has rendered all renditions.
• due to rendering the renditions by DM the media handler itself is not rendering any binaries at all, so it only has to calculate the rendition dimensions and DM paramters, which should not take much time. of course it's not easy to tell without knowing the custom project code if there are special use cases.