One of the early features of ACS AEM Commons was the Named Image Transformer as part of the release 1.5 of 2014. This feature allowed you to transform image assets dynamically with a number of options, most notable the transformation into different images dimensions to match the requirements of the frontend guidelines. This feature was quite popular and in a stripped-down scope (it does not support all features) it also made it into the WCM Core Components (called the AdaptiveImageServlet).
This feature is nice, but it suffers from a huge problem: This transformation is done dynamically on request, and depending on the image asset itself it can consume a huge amount of heap memory. The situation gets worse when many of such requests are done in parallel, and I have seen more than once situations of AEM publish instances ending up in heavy garbage collection situations, ultimately leading to crashes and/or service outages.
This problem is not really new, as pretty much the same issue also happens on asset ingestion time, when the predefined renditions are created. While on AEM 6.5 the standard solution was to externalize to this problem for asset ingestion (hello Imagemagick!), and AEM CS solved this challenge in a different and more scalable way using AssetCompute. But both solutions did not address the problem of enduser requests to these dynamic renditions, this is and was still done on request in the heap.
We have implemented a number of improvements in the AdaptiveImageServlet to improve the situation:
- A limit for requested dimensions was added to keep the memory consumption “reasonable”.
- The original rendition is necessarily used as a basis to render the image in the requested dimension, but rather the closest rendition, which can satisfy the requirements of the requested parameters.
- An already existing rendition is delivered , if its dimensions and image format is requested.
- An upcoming improvement for the AdaptiveImageServlet on AEM CS is to deliver these renditions directly from the blobstore instead of streaming the binary via the JVM.
This improves the situation already, but there are still customers and cases, where images are resized dynamically. For these users I suggest to make the these changes:
- Compile a list of all required image dimensions which you need in your frontend.
- And then define matching processing profiles, so that whenever such a rendition is requested via the AdaptiveImageServlet it can be served directly from an existing rendition.
That works without changes in your codebase and will improve the delivering of such assets.
And for the users of the Named Image Transformer of ACS AEM Commons I suggest to rethink the usage of it. Do you really use all of its features?
Things on a content management system 
Hi Jörg,
Interesting article! We have this setup (Named Image Transforms + AdaptiveImage), originally built by consultants on AEM 6.1 and upgraded along the way. In addition to the performance concerns you outlined, I also find it difficult to understand the interplay between Named Image Transforms, the AdaptiveImageServlet, and the rest of the imaging stack incl. PictureFill on the front-end.
In recent years, we’ve moved to depend as little as possible on AEM renditions, and prefer to only generate the required thumbnails, a Web rendition and a PTIFF, and ask Dynamic Media for generating and caching the specific rendition sizes and formats we want. We make heavy use of instance-level cropping, and had to write custom code to convert AEM crop parameters to DM’s syntax.
We’re trying to plan out a migration from 6.5 to CS, and this is one of the areas where I’d like to do a better job. Can you elaborate on how your advice relates to environments that also use Dynamic Media?
Thanks!
– Val
Hi Val,
interesting question, but I am not an expert on Dynamic Media and PTIFFS. Let me see if I can get something published, although that will definitely some take time.
Thanks!