Architecture for high performance caching of image files created on the fly

I'm developing an application which needs to serve raster image files at varying zoom levels of a vector image stored on the server. Imagine having vectorized data of streets and buildings, and generating on the fly a PNG tile for a Google-maps-like service, as a response to a client's request for a certain zoom level and coordinates.

In my case the underlying vector data changes quite frequently plus the zoom levels are at much closer increments than e.g. the dozen or so fixed zoom steps in Google Maps. Hence, for me it is impractical to pre-calculate all possible tiles and upload them to a high-performance static media server.

Is there an elegant way to get the first request for a specific tile to be served from the app that generates it and all subsequent requests to be served from a static media server?

Assume that as soon as I generate a tile on the app server I can instantly make it available on the static media server.

The obvious approach which would be to use a redirection if a tile has previously been generated is sub-optimal, as it will (a) load the app server with many unnecessary hits and (b) reduce the overall performance for the client as the browse开发者_开发技巧r will need to send two requests in series before getting the image data, approximately doubling the response time.

So I'm looking for other ideas. E.g. is there a way to configure a web server to try and use high performance static file serving and if a file doesn't exist then to fall back to calling an app instead of returning a 404?

---

This is a relatively common problem to generate a file cache if it does not already exist, so it can be served directly by the webserver.

In NginX, there is the try_files option. This takes a set of URIs and, as you would expect, tries each one till it finds a response. If the first set fails, but a later one returns OK and the data (and while it's there, also creates a file that would match the first try-file path) then the next request is short-circuited.

try_files $uri $uri/ /makeCacheFile.php?q=$uri&$args;

In Apache, something like this will perform much the same with mod_rewrite

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.+)$ /makeCacheFile.php?q=$1 [L,QSA]

Here, we check if a particular file be served for a request, and if it would not, pass the URL to a script that may go on to generate it.