In Commerce R2 SP1 we ended up excluding certain asset paths from the UrlRewriter and handled them "manually" using our own module combined with sql lookups, http- and output-caching. This turned out to be working well for us with the requirements we had at that time.
Back then (I hope it's fixed by now) it loaded ALL assets from DB on every asset request and iterated through them looking for a path+filename match. This was actually done in an EPiServer handler and not in the Mediachase code base. You can check if this is still the case using the profiler, if so I would suggest that you either use the image type metafield if possible (it should be faster) or build something yourself like we did.
So I'm sorry I can't give you some easy config fix for this. I do hope it exists and that someone wiser has discovered it and posts it here.
Hi Thomas,
Look at baf.config and profileCache section. Perhaps, it would help you.
We ended up dropping assets alltogether as there is no caching whatsoever and the issues Patrick reported is very much still an issue with R2 SP2, the more files the worse performance gets.
We don't have the time or the budget for rewriting the standard asset handler.
We are experiencing performance problems with the Asset system in EPiServer Commerce, mostly in regards to displaying image assets(but the same applies to pdf assets). Just showing an image(ie: just opening the url for an image in the browser to display the image) is resulting in between 32 and 56 !! sql calls depending on the image. We have a product overview page with more than 50 images, that means up to around 2500!!! sql calls to display a simple page. This is impossible to put into production.
So how do we fix this? Is there a cache setting somewhere? It seems that there is no caching at all as it is the same sql calls every single time an image is requested. I looked in ecf.asset.config and the docs but couldn't find anything.