Why don't more companies resize images client-side first using and then save the server some work by only asking it to verify the result by - resizing to the same size - removing metadata This results in much faster transfer (10x less bandwidth used often for mobile uploads) and reduces server load by "farming" out the work to the clients. https://developer.mozilla.org/en-US/docs/Web/API/CanvasRende... # Edit: On Kee…
As I understand they needed to download images from any external servers using an URL. I am not sure if that is possible even with CORS. Also they don't save preview images and generate them when needed as I understood. So what you are suggesting requires a lot of disk space to keep thumbnails that might be never needed later. And if you don't have millions of uploads per day then it makes no sense trying to save som…
How Discord Resizes 150M Images Every Day with Go and C++
121–130 of 157 posts
Re: How Discord Resizes 150M Images Every Day with Go and C++
#122Earlier quoted context omitted.
In this case, it was perhaps cheaper for them to do in-house, and it's not rocket science? They wrote a bleeding edge library for it - sounds like they have the expertise just fine. Minimizing external dependencies can be a big deal if you have the developers to manage it. Also, it is totally core to what they do. Images are a huge part of the Discord UX.
At 150m images per day, not counting bandwidth, imgix would cost ~135k/month. Running 12 n1-standard-16 instances (peak load according to the article) is ~$5k/month. It's not hard to see why we wrote it in house when you consider that cost.
Re: How Discord Resizes 150M Images Every Day with Go and C++
#123Earlier quoted context omitted.
At 150m images per day, not counting bandwidth, imgix would cost ~135k/month. Running 12 n1-standard-16 instances (peak load according to the article) is ~$5k/month. It's not hard to see why we wrote it in house when you consider that cost.
Ok, so why a new library and associated dev time when thumbor and other libraries already exist, especially if you're willing to spend 5k/month on instances just for this?
Re: How Discord Resizes 150M Images Every Day with Go and C++
#124Earlier quoted context omitted.
to be fair, you could say the same of facebook/google. they're not selling the data (giving it to third parties), but they're making money off it.
Sure, they serve said data to other authorized users and clients (intended recipients). Name a business that doesn’t do that. ;)
Re: How Discord Resizes 150M Images Every Day with Go and C++
#125Unfortunately the post seems to have disappeared from the internet (it was probably around 6 years ago), so here are some other teasers:
https://yahooeng.tumblr.com/post/116391291701/yahoo-cloud-ob...
https://ceph.com/geen-categorie/dynamic-object-interfaces-wi...
Disclaimer: not affiliated with Ceph apart from being a happy sysadmin.
Re: How Discord Resizes 150M Images Every Day with Go and C++
#126That’s 1700 images per second. Doable on one (beefy) box. 3 to account for the diurnal cycle. Am I supposed to be impressed?
Where I work we have single nodes processing near that much data a hour -- these are beefy systems though.
Re: How Discord Resizes 150M Images Every Day with Go and C++
#127This post reminded me of a very old article from Yahoo/Tumblr explaining how they were (ab)using Ceph to generate thumbnails on the fly as pictures were uploaded using the Ceph OSD plugin interface. Unfortunately the post seems to have disappeared from the internet (it was probably around 6 years ago), so here are some other teasers: https://yahooeng.tumblr.com/post/116391291701/yahoo-cloud-ob... https://ceph.com/gee…
Talk is from Lua workshop 2017. Relevant content begins at 15m40s.
Re: How Discord Resizes 150M Images Every Day with Go and C++
#128Earlier quoted context omitted.
Ok, so why a new library and associated dev time when thumbor and other libraries already exist, especially if you're willing to spend 5k/month on instances just for this?
That was pretty clear in the post - they didn't find a Golang lib that could compete with their pillow-simd on resizing, which was the main performance bottleneck.
If they're going to spend 60k/year on instances, the dev time definitely wasn't worth it for this. They just wanted to use that language because this is a NIH situation, not really an engineering priority.
Re: How Discord Resizes 150M Images Every Day with Go and C++
#129That’s 1700 images per second. Doable on one (beefy) box. 3 to account for the diurnal cycle. Am I supposed to be impressed?
I don't get why you are being down voted. This is almost exactly what I thought. It's just not that much data given the state is computer hardware. Where I work we have single nodes processing near that much data a hour -- these are beefy systems though.
Re: How Discord Resizes 150M Images Every Day with Go and C++
#130That’s 1700 images per second. Doable on one (beefy) box. 3 to account for the diurnal cycle. Am I supposed to be impressed?