Show HN: Imgix.js, a JavaScript library for responsive imaging • Hacker News Board

Re: Show HN: Imgix.js, a JavaScript library for responsive imaging

#31

Post by egonschiele » Fri, Oct 10, 2014, 11:06 PM UTC

skuhn wrote: post #30

egonschiele wrote: post #23

Earlier quoted context omitted.

I have heard anecdotally that graphicsmagick and imagemagick both have awful memory leaks. Did you run into this? We serve ~400 reqs/sec from our image server after putting a CDN in front of it, so we couldn't work with memory leaks. File size was a problem for us too, as was file format. We needed a solution that would work with pngs, jpegs, gifs and tiffs.

I worked for a company that used ImageMagick for compositing images together and resizing them to one of ~60 sizes (different page locations, device types, etc.). While it worked, and it was at the core of the company's technology, it was truly the worst software I have ever had to wrangle into a production service. You name it and ImageMagick could do it: - Leak memory - Perform terribly until you find the magic inc…

Eep. Thanks for the writeup. I'm really glad we didn't go with imagemagick.

Re: Show HN: Imgix.js, a JavaScript library for responsive imaging

#32

Post by latch » Sat, Oct 11, 2014, 1:04 AM UTC

egonschiele wrote: post #23

latch wrote: post #12

Earlier quoted context omitted.

I'd break it down into two parts. The first is the image transformation. For this we use graphics magic, and based on the params in the querystring, we'd crop, resize, alter the quality, anchor the image to a focus point and so on. Not copy and pastable, but [1] should give you a rough idea. Also [2] is code we use to get the file type and size of the image (gm identify can be painfully slow). The second part was a b…

I have heard anecdotally that graphicsmagick and imagemagick both have awful memory leaks. Did you run into this? We serve ~400 reqs/sec from our image server after putting a CDN in front of it, so we couldn't work with memory leaks. File size was a problem for us too, as was file format. We needed a solution that would work with pngs, jpegs, gifs and tiffs.

No, we didn't have memory leaks, but I do remember we had to build GM from source because the version in the ubuntu rep was old and it DID leak.

For gifs, we used gifsicle, but we didn't support the full set of functions with it.

Re: Show HN: Imgix.js, a JavaScript library for responsive imaging

#33

Post by porker » Sun, Oct 12, 2014, 8:54 AM UTC

latch wrote: post #18

richbradshaw wrote: post #16

Earlier quoted context omitted.

Are you using S3 with multiple EC2 instances/multiple servers? Do you keep your /storage/ on S3? I'm considering pulling from S3, then resizing on whatever server it is, then storing back on S3 - any issues with that? Do you handle the malicious case of someone supplying various widths and heights potentially DoSing the server?

Non EC2 servers, one in Europe and one in the US. /storage are local SSDs to the machines (so it's 2 copies of the data (3 for the originals since they're also on S3)). Whether storing it back on S3 is "good enough" depends on whether you feel the latency to fetch from S3 is acceptable. I don't have any hard numbers (I might have at some point). I imagine you'll see a percentage in the 1-4s range, which is pretty bad…

> It never proved necessary to do more. You're definitely open to a DOS attack. Hard to mitigate too...

An approach I've used before is to have a hash in the URL, and discard any requests where the width/height don't match the hash value. Not good if users are meant to be able to link at whatever size they want, but in our case we gave a shortcode to users which then generated the actual URL.