3Just saw Igor Sysoev announced the release of Nginx 0.6.4 on the mailing list, and saw him demonstrating the new proxy_store and fastcgi_store directives (which have been available since 0.6.3), making “mirror on demand” so much easier to do as an developer.
Here is the configuration code Ignor demonstrated in his email:
location /images/ {
root /data/www;
error_page 404 = /fetch$uri;
}
location /fetch {
internal;
proxy_pass http://backend;
proxy_store on;
proxy_store_access user:rw group:rw all:r;
proxy_temp_path /data/temp;
alias /data/www;
}
Basically proxy_store or fastcgi_store saves the backend result into files on the local file system, so subsequent requests to the same URI can be handled by on-disk cache without forwarding the request to the potentially-expensive backend again. Traditionally it requires the backend being able to write to local files (for example, one of my small project does just that), however it is not always possible as they might not share the same file system.
You might still need a separate cron job to periodically invalidate the cache. However it just makes writing the backend much simpler.
Using nginx-0.6.5 I found that the proxy_temp_path directive doesn’t work.
“proxy_temp_path /data/temp;”
this seems to be ignored and nginx uses the directive specified at compile time, by default that is /usr/local/nginx/html
Why would you need to temporarily invalidate the cache?
I would think mainly due to the files being changed at the source…
I’m thinking you have something like a large RAID array, and this would be a nice way to save trips back to the source. I don’t believe it actually -writes- any files unless the application can speak REST/DAV?
Also you might run out of disk space on web nodes, as those typically don’t have enough room for your full website’s data… so you could set it up as an LRU read-through cache basically, much like memcached would be used in front of MySQL…