41–50 of 55 posts
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.
Or just use Amazons serverless image handler, to server up requested sizes, and cache them. https://aws.amazon.com/solutions/serverless-image-handler/
Wasn't expecting that from an aws created lambda solution
Earlier quoted context omitted.
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. N…
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.
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.
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 l…
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.
Earlier quoted context omitted.
The article mentions Digital Ocean provides the infrastructure so it seems the only cost is dev time. It reads almost like a promotional for DO with all of their services mentioned, which is probably why they support it to begin with.
I though about that, too, but that's not any different from using AWS specific services. I actually now realized why they use bloody annoying different names: it's free marketing when someone writes about how they implemented stuff instead of having a generic name.
In general I like to see brand signals: if someone I respect mentions that they use Cloudflare, that is useful information, even without further details.
Unsolicited mentions are usually useful, it's just sneaky paid advertising is bad.
Image resizer scaling is one of the more interesting problems I have worked on in the last 10 years of so. I was part of a small team that designed and built the resizer that powers the nine.com.au network of sites. Modest by USA standards it gets close to hundreds of millions of views a day across the whole network. We ended up using shared nothing architecture. The whole thing ran on 6 T2 large AWS instances using…
I once tried to pitch a one "mobile ecommerce website as a service" company in Vancouver to go for GPU based image rescaler at around 2011. A very dumb proposal: no caching, resize on the fly, the gpu has many gigabits of resizing performance for as long as JPEG is involved. One GPU works in decoding with VDPAU, one in encoding with CUDA. That knocked down any google app engine based "elastic" service on economic bas…
More interestingly, the github repo is just a wonderful example of a fully built application using modern techniques in a microservices architecture: https://github.com/DMarby/picsum-photos It's so hard to always find how all the pieces fit together and this repo has it all. Really impressive.
Image resizer scaling is one of the more interesting problems I have worked on in the last 10 years of so. I was part of a small team that designed and built the resizer that powers the nine.com.au network of sites. Modest by USA standards it gets close to hundreds of millions of views a day across the whole network. We ended up using shared nothing architecture. The whole thing ran on 6 T2 large AWS instances using…
Edit: forgot to mention, the appengine documentation is very limited, and only mentions the ability for width/height resizing. Searching stackoverflow and other sites, however, reveals many other available modifiers
Edit 2: Also to mention is that the (ab)use of this service is quite popular with illegal sites. Who doesn't love offloading your image bandwidth to google's image proxies?
Earlier quoted context omitted.
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 l…
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…
In 99% of workflows, what's going to happen on a cache miss at the CDN is you'll hit varnish, which will also suffer a cache miss since it's a rarely-requested resource that's being requested. That 1% of cases it helps with are the few that have been requested recently enough to have not been evicted from the Varnish server but not so recently that they haven't been evicted from the CDN. It's a vanishingly-small amount of traffic. Most of what your varnish server will be doing is making requests to your main server while doubling your bandwidth and server costs. And latency.
Not practical at all.
That infrastructure would've been better spent on another server in the load-balancer rotation -- which is also unnecessary since I run a nearly-identical offering with many times the traffic and do it off of a single server + CDN so I speak from experience.
Not to mention the most ridiculous turtle in this stack: Spaces itself is a CDN. That means on every cache miss the traffic gets bounced from a CDN (Cache #1) to a load balancer (does that imply multiple Varnish instances?) which bounces it to Varnish (aka Cache #2) to a server which makes one request to Postgres, then another to Redis (Cache #3) and if it finally finds its file it redirects to Spaces (Cache #4). Your real traffic coming in is almost all going to get served by the CDN -- and when it's not on the CDN, it's going to be from a page that only gets hit once a week or once a month or less. That means if it's not in your outer cache it's not going to be in any of your inner caches, since it's long-tail traffic. And the long tail is quite a lot of traffic.
Again: I have an image site that gets much more traffic than picsum and I run it off of a single server + CDN. My biggest cost by far is bandwidth. He's not doing himself any favors with all this over-engineering. My service has a CDN which -- upon cache miss -- serves a flat file from my server. Done. 4TB of data transfer monthly and .75TB of flat files stored across multiple volumes. New files are processed / generated at upload and that's the end of the story. I'm just some random shmuck on the internet so you don't have to believe me but I've just had an epiphany in reading this story by some guy who happens to do exactly what I do and not as well but with many, many more steps and I'm realizing I'm an expert on shit I don't even think about being an expert on while other people who think they're experts -- aren't.