6 ms·
If you need random access to s3 within an ec2 region, sticking nginx in front of it as a caching proxy is unbelievably faster than hitting s3 directly; even mor
by mnutt 5y ago
If you need random access to s3 within an ec2 region, sticking nginx in front of it as a caching proxy is unbelievably faster than hitting s3 directly; even moreso if you're multi-region.
I recently experimented with trying to have nginx rewrite images from png/jpeg to webp for clients that support it. I ended up with a solution where a lambda triggered off new files added to a bucket and re-encoded them as webp alongside the originals. When a request came into nginx, it would examine the URL and client Accept headers, and then first try to fetch the webp file from s3 before falling back to fetching the original from s3.
I was somewhat surprised that nginx was capable of doing it efficiently, given the nginx configuration format and all the moving pieces.
- gonzo41 5y agoIf you;re doing this with an ec2, why not use CloudFront, and if you need a tiny bit of logic you could use API GW edge optimized and toss a lambda in there to do the logic bits.
- halfmatthalfcat 5y agoAt Edge workers really are great at solving so many of these use cases.
- killingtime74 5y agoNginx itself supports lua and JavaScript
- mnutt 5y agoThat would work, too. It would be very expensive at scale and would be difficult to keep tail latencies down. Which might be ok for some cases, but wasn't for mine.
- dikei 5y agoInstead of re-encoding everything, have you considered using something like `imgproxy` to transcode image on demand and cached the result ?
- jgalt212 5y agowhy webp over png/jpg? Is there that much of a difference to amortize the cost of the extra processing and/or caching?