Take the 2-minute tour ×

I have some ASP.NET MVC actions that generate images dynamically (although it could equally be an ASPX page).

I'm using [OutputCache] to cache these images. I'm just wondering if I need to worry about ASP.NET caching images in memory and taking up too many resources. These are product images of varying sizes for a shopping cart containing only a couple dozen products.

Will OutputCache use disk or just in memory? How intelligent is it? Or should I just save the images to disk myself and implement my own caching system (which is actually the current implementation) ?

share|improve this question
Sorry to bump this, but I'm in the same situation -- did you end up having to roll your own cache implementation? I'm serving my images from dedicated servers, so I don't have access to those IIS instances from my upload page, and would rather avoid messing directly with the file system when trying to invalidate the cache entries. Did you come up with a solution to this? –  Daniel Schierbeck Apr 29 '10 at 11:51
i ended up saving the images to a cache directory myself the first time they were requested but now i pretty much stopped generating dynamic images except small ones which i'm not concerned about. plus we upgraded to a new server with 8gb as opposed to 2gb. re-reading my original question i'd be surprised if outputcache would use disk (apart from via virtual memory). –  Simon_Weaver Apr 29 '10 at 19:37

1 Answer 1

up vote 3 down vote accepted

For all intents and purposes, I believe that the output cache is completely in-memory - meaning that if the app pool is recycled, the image will need to be generated again.

I've had to do something similar in the past, and I actually implemented a two-tiered system that used the HTTP cache primarily, and used the filesystem as a fallback. If something didn't exist, I generated the image and saved it to disk AND put it in the cache. That way if it gets pushed out of the cache or the app pool recycles, I only have to load it off the disk (it appears you've done the same).

As far as "too much memory", if you explicitly use HttpContext.Cache instead of [OutputCache], you can control the priority of the item in the cache. You can then tweak the settings on your app pool to control how much memory it uses overall, but I'm not sure there's a whole lot to be done other than that. A couple images * 12 products doesn't seem like it would take up a whole lot of memory to me though.

Without knowing anything else about your application, it sounds to me like you could get away with just using the outputcache. However, if you need something more robust and scalable, I'd use the two-tiered system I described. Though, if you've already got that implemented and working, "if it ain't broke..."

share|improve this answer
right now the implementation is messy cos the filename is a concatenation of an image key, desired dimensions plus other parameters. i don't want to spend a whole day writing some clever caching mechanism if i can get away with one line of code. guess i should probably just monitor IIS memory usage –  Simon_Weaver Jan 28 '09 at 23:42

Your Answer


