how to use nginx to create static files from dynamic content
Serving static files is much faster than that of dynamic content – even if some parts of it are stored by memcached or assembled by the help of means such as varnish.
Here is how to utilize nginx proxy module to cache outputs as static files. For example for your old (read-only) wiki pages, trac documentation or even old wordpress blog posts. An example for the latter:
server {
listen 555.999.33.62:80;
server_name some.blog.com;
access_log off;
error_log off;
root /srv/www/blog/html/;
# start: blog cache
location ~ ^/200[0-8]/[01][0-9]/ {
root /tmp/nginx/blog/fetch;
expires 30d;
error_page 403 404 = /fetch$uri;
}
location ^~ /fetch/ {
if ($request_uri ~ /$) {
set $store_extra index.html;
}
internal;
proxy_pass http://127.0.0.1:80;
proxy_store /tmp/nginx/blog${uri}${store_extra};
proxy_store_access user:rw group:rw all:r;
}
# end: blog cache
location /wp-includes/ {
expires 7d;
}
location /wp-content/ {
expires 14d;
}
location / {
proxy_pass http://127.0.0.1:80/;
proxy_redirect off;
}
}
The cache is located in /tmp/nginx/blog resembling a new DocumentRoot, which even could be moved to another machine for distributed serving. The entire directory is mounted on /dev/shm, thus on frequent access served directly from memory, else moved by Linux kernel to disk.
Caching works as follows: First access is a cache miss and the request is proxied to an Apache listening on 127.0.0.1 port 80. WordPress there yields an output which in return will be stored as static file by proxy_store in /tmp/nginx/blog, from where subsequent requests will be served. In case it appears as directory “index.html” will be appended; /fetch is always prepended due to the re-location.
Pruning that cache could be done as follows by a cron-job:
find /tmp/nginx/blog -ctime +14 -type f -exec rm '{}' \;
# analoguous for empty directories; ctime (creation ~) could be atime (access time)
Subscribe in a reader
Follow me on Twitter
[...] choice. That could be e.g. a second domain for static files only, Amazon S3 or CludFront storage, Nginx caching statics or even a dedicated CDN. By that you can decrease load on the server hosting your blog. [...]
[...] Links: – Nginx wiki – how to use nginx to create static files from dynamic content – Page-level caching with [...]
imho, varnish or even squid can manage and serve cache better??
I don’t have benchmarks for Varnish at hand and have only installed it once. It does ‘feel’ a bit slower on images, but don’t hesitate do tell us about any benchmarks or usage scenarios you come across.
(Varnishd has the advantage of being able to cache parts of pages, which Nginx cannot.)
http://deserialized.com/reverse-proxy-performance-varnish-vs-squid-part-1/
Squid would be my last choice, because it is rather slow compared to Nginx in this scenario (configuring it is just a pain), most cases slow to a third. Almost every benchmark out in the net points this out. But we’re talking about serving static files here, and Squid and Nginx have more options than that.
http://www.peterbe.com/plog/nginx-vs-squid – ~7100 Nginx, ~2300 Squid RPS
Have you tried Nginx’s built in caching + using a tmpfs location as cache store?
Vito, I do always cache in shared memory/tmpfs.
If you do so, don’t forget to tweak vm.swappiness:
The higher swappiness is, the more aggressive memory pages are swapped out. If you have a lot of RAM dedicated for cacheing and daemons demanding a predicable amount of RAM, better set a lower value.
The default is 60 for swappiness and 30% of total RAM for tmpfs.
And you’re right. One could’ve used caching abilities of Nginx http_proxy, but as soon as you use fastcgi this won’t work (not covered by this example, though). And, sometimes you just want that mirror files, e.g. for archival purposes.
[...] from: Mark’s Blog » how to use nginx to create static files from dynamic content Tags: caching, content, nginx, [...]