Nginx image processing server with OpenResty and Lua
leafo.net
leafo.net
The bottleneck with this implementation is ImageMagick. ImageMagick leaks a lot of memory and is generally very inefficient with resizing operations. GraphicsMagick is not much better. Under high load, this will crush your CPUs and max out your Nginx threads much faster than it is worth. You will almost definitely need to use something like OpenCV on the GPU for this to scale.
Although caching is referenced briefly in this article, it is crucial for this system to work. A good CDN with fast invalidation and a low eviction rate would be ideal.
Of course, you need to cache the thumbnails for a reasonable time once they're generated, otherwise the CPU usage will skyrocket, but that's pretty easy to achieve with nginx's proxy_cache directive.
I also have implemented this in Go, but using cgo and graphicksmagicks, which is way faster and decodes almost any image you throw at it (there are some issues with very optimized GIFs, but I fallback to gifsoup for "deoptimizing" them in those cases). In fact, I even added a function for cropping and resizing an image to a given size in the module itself (since I think is a very common need), while keeping the aspect ratio and also giving the option to just center the result or grab the part of the image with higher entropy (e.g. suppose you have an image with a person in the side and then a lot of blue sky, you probably don't want to crop and image and end up with just sky in the thumbnail). This is just one of a few benchmarks I wrote:
BenchmarkResizePngMagick 20 80665091 ns/op 689 B/op 3 allocs/op
BenchmarkResizePngNative 1 9689016519 ns/op 351200 B/op 27 allocs/op
(yup, that's 120x faster)
The bindings are mostly documented, but I haven't gotten around to releasing the code yet, although I do hope do publish it soon. If you're interested, send me an email and I'll let you know when I put the code in Github.
Much more powerful than their built in image handling which uses the ancient and no longer updated GD library.
Just use tmpwatch in a cron job. You can use mtime or atime depending on your linux and capabilities to expire the resized images and delete them every so many hours (or days depending on your space).
Could never get sendfile to work under perl through nginx either for some reason and they never answered my question on the nginx forums, so I had to just inefficiently dump the image directly to nginx in a buffered loop. The image is cached just like this lua code so the next read goes directly through nginx so wasn't too worried about the sendfile problem.
Code is just 50 lines though, if I can figure it out, most any coder should be able to. Just compile nginx with http://wiki.nginx.org/HttpPerlModule and then find any perl example code for imagemagick.
Thanks for the details, though. That actually gave me a few ideas.
For instance, say you are generating thumbnails for JPEG images. Most Operating Systems ship with the IJG libjpeg, but a few have switched or are considering switching to libjpeg-turbo, a forked binary compatible library that has several performance enhancements. One thing libjpeg-turbo doesn't do though, is implement the DCT scaling functionality of libjpeg, which is a way of efficiently downscaling jpeg images without fully decoding the image (and of course has an impact on image quality as well). The most important benefit of using DCT scaling for generating thumbnails is that it has much lower memory overhead. Since you don't need to decompress the entire image first, it can be done block by block, which means full-image sized buffers don't need to be allocated (which is what Imagemagick will try to do by default). Generating a small thumbnail of a large (10,000 x 20,000 pixel) image will allocate large amounts of memory, whereas using the DCT scaling option will allocate only small working buffers and complete much faster. If you're running an image processing server, these considerations are vital.
Long story short, if you stop thinking about your code at the level of the Imagemagick API (or whatever graphics library you choose), you can end up with more problems than you might realize.