views:

46

answers:

1

I'm creating a page that has some dynamically generated images built from data that comes from web services. The image generation takes a fair amount of time due to the time involved in hitting the web services, so I need to do some caching.

One option would be to use the OutputCache parameter to cache the images, but I don't like forcing some unlucky user to wait for a really long time. I'd rather write the images to files in the background and serve static html.

Whats the best way to do this? I'm thinking about creating a special url to trigger refreshes that writes the images to disk and setting up a scheduled task of some sort to hit the refresh url. Any better ideas?

It seems its possible to use memcached with ASP.Net, how hard would that be to set up? Seems like it may be overkill for this situation (internal tool) and I've already got the disk based version working, but I'm curious.

A: 

We do something similar, although we simply precompute the files/images and store them in the HttpRuntime.Cache. This way our views can still be generated as-is, but they typically pull from cached data rather than generating on-the-fly.

On the off chance that the cached data isn't available, we have getter functions to generate them:

public static GetGraph(int id)
{
    if (HttpRuntime.Cache["image_"+id] == null)
        HttpRuntime.Cache["image_"+id] = _imageGen.GenerateGraph(id);
    return HttpRuntime.Cache["image_"+id];
}
Andrew
The issue is that I never want the user to trigger the generation -- not even once. I suppose in this method you can just have the scheduled task visit the same page the user is visiting.
Luke
@Luke - we typically don't have the user trigger the generation either. We cache everything for 30 hours, and have a process that rebuilds the cache each night. The advantage of the above message is that the image/file/etc would still be available even if the batch process didn't run for some reason ... and wouldn't necessitate a system outage to rebuild all cached objects.
Andrew
Thanks for the clarification.
Luke