Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Discord Resizes 150M Images Every Day with Go and C++

blog.discordapp.com

Post reply on HN
Print view View original

41–50 of 157 posts

Re: How Discord Resizes 150M Images Every Day with Go and C++

#41

Post by Matt3o12_ »

pmelendez wrote: post #23
Xeoncross wrote: post #8

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…

From the notes of your link: "drawImage() will ignore all EXIF metadata in images, including the Orientation. This behavior is espacially troublesome on iOS devices. You should detect the Orientation yourself and use rotate() to make it right. " If the origin of the image is the client and you got the client side resize wrong, then you might introduce artifacts when trying to fix it on the server because the data los…

The question now is, what drains more power, sending the image and resizing it before sending. If the user has a good WiFi or 4G connection, sending the file as it, should be quicker and more energy efficient. With a 2G or 3G connection, uploading a photograph can take significantly longer (1min on poor/average 3G, which means the antenna is working for that duration and draws a lot of battery). Converting it should not take more then a second. Furthermore, I would prefer using less data then using a tiny amount of battery.

Re: How Discord Resizes 150M Images Every Day with Go and C++

#42

Post by GuB-42 »

bri3d wrote: post #15
caltrops wrote: post #6

I’d be very worried about a security issue with the unsafe C++ code. You really have to run this kind of complex parsing in a disposable containerized environment to do it safely. Or do everything carefully and in a memory safe language.

I'm not sure why this is being downvoted - image processing is one of the most dangerous parts of a common consumer-facing web software stack. By and large this is because image container formats are poorly documented, overly broad, and rely on a lot of tricky binary parsing that's easy to mess up in an unsafe programming language. It's also one of the most obvious ingress points for untrusted binary data uploaded by…

The downvote is probably because the comment implied that the issue is that the image processing is done in "unsafe" C++ and that another language should have been used.

However, there isn't much choice. Performance is very important in image processing, so much that many libraries contain hand-written assembly. In the article, it says that 90% of processing power is dedicated to it. Using a safer language in a safe way could completely kill performance and significantly increase the costs.

Re: How Discord Resizes 150M Images Every Day with Go and C++

#44

Post by caltrops »

GuB-42 wrote: post #42
bri3d wrote: post #15

Earlier quoted context omitted.

I'm not sure why this is being downvoted - image processing is one of the most dangerous parts of a common consumer-facing web software stack. By and large this is because image container formats are poorly documented, overly broad, and rely on a lot of tricky binary parsing that's easy to mess up in an unsafe programming language. It's also one of the most obvious ingress points for untrusted binary data uploaded by…

The downvote is probably because the comment implied that the issue is that the image processing is done in "unsafe" C++ and that another language should have been used. However, there isn't much choice. Performance is very important in image processing, so much that many libraries contain hand-written assembly. In the article, it says that 90% of processing power is dedicated to it. Using a safer language in a safe…

How much does a hack of all your data and/or a major outage cost?

I also recommended a mitigation strategy for unsafe code. Complaining that security is too hard is the reason for the situation we find ourselves in as an industry.

Re: How Discord Resizes 150M Images Every Day with Go and C++

#45

Post by abiox »

Buttons840 wrote: post #30
devwastaken wrote: post #27

How is the security? Any sort of image processing is a potential exploitation point. I see it says it uses the 'mature' libjpeg-turbo and libpng libraries,along with giflib for .gifs, but even with full trust of those, the C code, patches, and changes ontop could be more exploitation points. You can look through Imagemagick alone to see all the fun things possible when seemingly basic processing turns into exploits.…

Wow really? Is there room for another image processing library? Is ImageMagic poorly written or is image manipulation inherently risky?

> Is there room for another (...)

seems to me that there is no limit to available room. well, i suppose we're capped by the collective capacity of local storage and storage service providers.

Re: How Discord Resizes 150M Images Every Day with Go and C++

#46

Post by linkmotif »

> Today, Media Proxy operates with a median per-image resize of 25ms and a median total response latency of 85ms. It resizes more than 150 million images every day. Media Proxy runs on an autoscaled GCE group of n1-standard-16 host type, peaking at 12 instances on a typical day.

Awesome! <3

Re: How Discord Resizes 150M Images Every Day with Go and C++

#47

Post by dr_zoidberg »

victor106 wrote: post #5
deepnotderp wrote: post #4

Earlier quoted context omitted.

Yeah, either a good Python JIT or Cython would have been fine honestly. I never understood the obsession with "python is slow" when you can recover almost all of the performance with a good JIT or Cython (in many/most cases).

What are some good Python JIT's that are worth trying out?

PyPy.

Re: How Discord Resizes 150M Images Every Day with Go and C++

#48

Post by [deleted] »

Matt3o12_ wrote: post #41
pmelendez wrote: post #23

Earlier quoted context omitted.

From the notes of your link: "drawImage() will ignore all EXIF metadata in images, including the Orientation. This behavior is espacially troublesome on iOS devices. You should detect the Orientation yourself and use rotate() to make it right. " If the origin of the image is the client and you got the client side resize wrong, then you might introduce artifacts when trying to fix it on the server because the data los…

The question now is, what drains more power, sending the image and resizing it before sending. If the user has a good WiFi or 4G connection, sending the file as it, should be quicker and more energy efficient. With a 2G or 3G connection, uploading a photograph can take significantly longer (1min on poor/average 3G, which means the antenna is working for that duration and draws a lot of battery). Converting it should…

[deleted]

Re: How Discord Resizes 150M Images Every Day with Go and C++

#49

Post by Lutin »

Xeoncross wrote: post #8

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…

This is for proxying images that users link in chat, not for when users upload images to the service. It doesn't make sense to talk about doing this resize on the client, as the client doesn't have the image.

Re: How Discord Resizes 150M Images Every Day with Go and C++

#50

Post by wastedhours »

mark-r wrote: post #38
b1naryth1ef wrote: post #29

Earlier quoted context omitted.

Ah sorry I misunderstood you. We keep the original image around and provide different sizes for different platforms/resolutions/dpis/etc.

There's no reason this couldn't be a two-step process, resizing to something reasonable on the client then fine-tuning it on the server. I'm presuming you don't see the need to start with multi-megapixel images.

> I'm presuming you don't see the need to start with multi-megapixel images.

Might be a fair presumption today, but might not be for the future with hiDPI screens, VR etc... for the relative storage costs, it'd be better to have the original, and then you can programmatically run from there.

Post reply on HN