Nginx: a caching, thumbnailing, reverse proxying image server
charlesleifer.com
Nginx: a caching, thumbnailing, reverse proxying image server
1–10 of 59 posts
Re: Nginx: a caching, thumbnailing, reverse proxying image server
#2Very cool! I've been playing around with nginx-lua to handle our shortened URLs without having to invoke the upstream application.
Re: Nginx: a caching, thumbnailing, reverse proxying image server
#3If you use a CDN such as Cloudflare, you can do a similar trick but forget about the proxy cache (and associated storage needs) - as long as every image at every size gets a unique URL and you control http cache headers correctly, Cloudflare will store copies of every image size ever requested across their CDN network.
In terms of this blog post, you'll only need the "resizing server". This is a very simple and stateless way to get image thumbnailing to work. I'd also personally not bother with all the API key stuff - how 'malicious' can it be to generate a thumbnail of a public image?
This will even work with 3rd party images (the case of the app I used this for, it was product icons from Apple's App Store). If you somehow want to use images hosted elsewhere inside your app, but worry about speed or about hitting their servers too much, proxy them with Nginx and let Cloudflare handle the rest.
Re: Nginx: a caching, thumbnailing, reverse proxying image server
#4I wish the author had gone into more detail about why they chose to stop using Varnish.
Re: Nginx: a caching, thumbnailing, reverse proxying image server
#5I wish the author had gone into more detail about why they chose to stop using Varnish.
I was already using Nginx to proxy to my Python sites, so getting rid of Varnish meant one less thing to fiddle with.
Re: Nginx: a caching, thumbnailing, reverse proxying image server
#6If you use a CDN such as Cloudflare, you can do a similar trick but forget about the proxy cache (and associated storage needs) - as long as every image at every size gets a unique URL and you control http cache headers correctly, Cloudflare will store copies of every image size ever requested across their CDN network. In terms of this blog post, you'll only need the "resizing server". This is a very simple and state…
The blog post implements the "resizing server" on nginx to prevent the hits on application server. One alternative is to use AWS Lambda which has a sample code solution precisely on S3 image thumnailing.
Re: Nginx: a caching, thumbnailing, reverse proxying image server
#7I was wondering if an additional cookie based security token is possible with secure_link module. (show image only if session cookie is present)
Apparently, it is possible, great! One of the google results: https://gist.github.com/hilbix/5921589
Re: Nginx: a caching, thumbnailing, reverse proxying image server
#8This is a cool little project showcasing some of NginX's lesser known modules in action.
However, I have one nitpick.
The caching server's main location is a bit of a cargo-cult unoptimization. They have specified:
location ^/(.+)$ {
location / {
Re: Nginx: a caching, thumbnailing, reverse proxying image server
#9Does the image_filter module use the GPU?
Image filtering is an expensive operation for the CPU, with large latencies as well.
Re: Nginx: a caching, thumbnailing, reverse proxying image server
#10I found the nginx native image library completely inadequate a few years ago, so I had to use the perl module to connect it to imagemagick libraries instead. Much higher quality results.
Not sure if they have improved the native library but I doubt it has the flexibility.
The important part is caching the results because of the expensive cpu time.
ps. googling about the current state of this came up with an interesting nginx module which talks to imagemagick (or gd) directly https://github.com/cubicdaiya/ngx_small_light