9 ms·

I wonder how much it would cost to do a similar service and just upload all images and dimension possibilities to S3 + use cloudfront cdn.

by k2xl 7y ago

kemyd 7y ago
What's the point? You'll create dimensions never used by users (CPU sensitive), you'll store files not used by users (storage), you'll miss some configurations for sure. They're creating files once and store them in a cache (CDN and local cache). Basically, they are doing something similar to your suggestion minus creating unnecessary files.
overcast 7y ago
Or just use Amazons serverless image handler, to server up requested sizes, and cache them. https://aws.amazon.com/solutions/serverless-image-handler/ https://aws.amazon.com/solutions/serverless-image-handler/
- bwilliams18 7y ago
  This is what I use in production right now. It works well once you figure it out, but backwards compatibility with the previous Thumbor based version isn't as good (or at least correctly documented) as they say. And the previous Thumbor based processor just stopped working one day. It's not as robust as a system as I expected.
  - overcast 7y ago
    That's unfortunate, I've only just begun rolling into a new project, so I can't comment on how it used to be.
- jontro 7y ago
  This broke unexpectedly in July. Hot fix came about a month later. Upgrading to v4 completely broke backwards compatibility. Wasn't expecting that from an aws created lambda solution
swebs 7y ago
Well let's limit the possibilities to any image between 1x1 and 1920x1080. Calculating the number of possible images is simple enough. It's just 1920*1080, or 2073600 images. Now what's the average size of each image? Well the average of each dimension is half of the full size, so the average area should be 1/4th to of a 1920x1080 image, or 518400 pixels per image. So in total, we need to save 1074954240000 pixels. Now how many bytes does each pixel take to store? I really don't know. You can save them as 8bit RGB PNG images and assume each pixel will use 24 bytes. You'd add some for headers, and remove some to account for compression, but let's ignore that for now. Maybe someone else can chime in. But for now we need to store 25798901760000 bytes, or about 23TB. Not impossible, but sounds needlessly expensive.
- cabaalis 7y ago
  I'll bet that most image requests will be within certain parameters. 2^x by 2^y. So you could probably pre-cache most real-world image sizes, and leave dynamic generation for 1-offs.
  - anamexis 7y ago
    Well, that's what they're doing.
  - davinic 7y ago
    AND you could try to figure out how to do that beforehand, but some LRU-type cache solves the problem without any prior knowledge of what those sizes are.
- lonelappde 7y ago
  You can easily cut that by a factor of 100 simply by serving only multiples of 10pixels for sizes over 300px. And cut by another factor of 10 for jpg compression
- emilfihlman 7y ago
  It's also possible to have the same base image that you cut a portion out of, so you wouldn't need to store an original image for each possibility, just cache results of cropping as needed.
maxk42 7y ago
I run a similar image host with many times the traffic of picsum as well as daily DDOS attempts. This is pretty much the approach I've chosen. (I don't use S3, but a similar setup.) My infrastructure is much simpler than this (CDN in front of Varnish? What the hell software do you think they're using for the CDN?) and my total hosting costs are about $150 a month since recently upgrading the server. Seeing articles like this just reaffirms for me: The people who write these articles are not necessarily experts.
- siscia 7y ago
  What you mean by similar set up of S3?
- kemyd 7y ago
  Using CDN doesn't guarantee that users requests will hit your server only once.
- cestith 7y ago
  Two layers of the same cache can be beneficial, even if they're both using Varnish. Let's walk through a couple of request scenarios. I'll assume I'm both running the application/inner cache/load balancers and testing the request flows myself for simplcity of pronouns. I request image42 and it's in the outer cache. I get served from the outer cache. I request image127 and it's a cache miss on this server. It asks its backend, which is another cache, and this time it's a cache hit since it hadn't time out there yet. I request image128 and my browser requests the same image again from the same backend, it doesn't even have to hit my load balancer the second time. I request image2049. It's a miss on the outer cache. It's a miss on the inner cache. It gets generated by processing in a primary application. I then request it again, and I hit a different frontend cache. It's a miss in this frontend, but this cache is hopefully refreshed from that inner layer of cache rather than going all the way back to the application. If the load balancer pins traffic based on the ultimate end-user's IP to a particular inner-circle Varnish box via MRU then the chances are quite high that's what happens. I request image4095 and it has expired from the inner cache, but is still unexpired in the outer cache so it never gets beyond the CDN.

I wonder how much it would cost to do a similar service and just upload all images and dimension possibilities to S3 + use cloudfront cdn.

by k2xl 7y ago

I wonder how much it would cost to do a similar service and just upload all images and dimension possibilities to S3 + use cloudfront cdn.

kemyd 7y ago

What's the point? You'll create dimensions never used by users (CPU sensitive), you'll store files not used by users (storage), you'll miss some configurations for sure. They're creating files once and store them in a cache (CDN and local cache). Basically, they are doing something similar to your suggestion minus creating unnecessary files.

overcast 7y ago

Or just use Amazons serverless image handler, to server up requested sizes, and cache them. https://aws.amazon.com/solutions/serverless-image-handler/ https://aws.amazon.com/solutions/serverless-image-handler/

bwilliams18 7y ago
This is what I use in production right now. It works well once you figure it out, but backwards compatibility with the previous Thumbor based version isn't as good (or at least correctly documented) as they say. And the previous Thumbor based processor just stopped working one day. It's not as robust as a system as I expected.
- overcast 7y ago
  That's unfortunate, I've only just begun rolling into a new project, so I can't comment on how it used to be.
jontro 7y ago
This broke unexpectedly in July. Hot fix came about a month later. Upgrading to v4 completely broke backwards compatibility. Wasn't expecting that from an aws created lambda solution

swebs 7y ago

Well let's limit the possibilities to any image between 1x1 and 1920x1080. Calculating the number of possible images is simple enough. It's just 1920*1080, or 2073600 images. Now what's the average size of each image? Well the average of each dimension is half of the full size, so the average area should be 1/4th to of a 1920x1080 image, or 518400 pixels per image. So in total, we need to save 1074954240000 pixels. Now how many bytes does each pixel take to store? I really don't know. You can save them as 8bit RGB PNG images and assume each pixel will use 24 bytes. You'd add some for headers, and remove some to account for compression, but let's ignore that for now. Maybe someone else can chime in. But for now we need to store 25798901760000 bytes, or about 23TB. Not impossible, but sounds needlessly expensive.

cabaalis 7y ago
I'll bet that most image requests will be within certain parameters. 2^x by 2^y. So you could probably pre-cache most real-world image sizes, and leave dynamic generation for 1-offs.
- anamexis 7y ago
  Well, that's what they're doing.
- davinic 7y ago
  AND you could try to figure out how to do that beforehand, but some LRU-type cache solves the problem without any prior knowledge of what those sizes are.
lonelappde 7y ago
You can easily cut that by a factor of 100 simply by serving only multiples of 10pixels for sizes over 300px. And cut by another factor of 10 for jpg compression
emilfihlman 7y ago
It's also possible to have the same base image that you cut a portion out of, so you wouldn't need to store an original image for each possibility, just cache results of cropping as needed.

maxk42 7y ago

I run a similar image host with many times the traffic of picsum as well as daily DDOS attempts. This is pretty much the approach I've chosen. (I don't use S3, but a similar setup.) My infrastructure is much simpler than this (CDN in front of Varnish? What the hell software do you think they're using for the CDN?) and my total hosting costs are about $150 a month since recently upgrading the server. Seeing articles like this just reaffirms for me: The people who write these articles are not necessarily experts.

siscia 7y ago
What you mean by similar set up of S3?
kemyd 7y ago
Using CDN doesn't guarantee that users requests will hit your server only once.
cestith 7y ago
Two layers of the same cache can be beneficial, even if they're both using Varnish. Let's walk through a couple of request scenarios. I'll assume I'm both running the application/inner cache/load balancers and testing the request flows myself for simplcity of pronouns. I request image42 and it's in the outer cache. I get served from the outer cache. I request image127 and it's a cache miss on this server. It asks its backend, which is another cache, and this time it's a cache hit since it hadn't time out there yet. I request image128 and my browser requests the same image again from the same backend, it doesn't even have to hit my load balancer the second time. I request image2049. It's a miss on the outer cache. It's a miss on the inner cache. It gets generated by processing in a primary application. I then request it again, and I hit a different frontend cache. It's a miss in this frontend, but this cache is hopefully refreshed from that inner layer of cache rather than going all the way back to the application. If the load balancer pins traffic based on the ultimate end-user's IP to a particular inner-circle Varnish box via MRU then the chances are quite high that's what happens. I request image4095 and it has expired from the inner cache, but is still unexpired in the outer cache so it never gets beyond the CDN.