5 ms·

I agree. and I'm surprised they made a blog post about this. The details of this seems more embarrassing than it is enlightening. >Comment bundles are particul

by sigmar 11y ago

I agree. and I'm surprised they made a blog post about this. The details of this seems more embarrassing than it is enlightening. >Comment bundles are particularly heavy: They contain the comment text itself as well as its id, timestamp, and author metadata (including profile picture). ... Generating profile picture URLs is a CPU-inefficient operation because we must dynamically compute the correct CDN URL. The more comments we load, the more profile picture URLs we need to generate. Is it loading the entire profile picture with each comment? Not just a small thumbnail?

sloanesturz 11y ago
I think it's only loading the URL to the profile photo image, which is stored in the CDN. Calculating the URL is, apparently, the slow factor. Maybe it requires some type of cryptographic operation that results in heavy CPU use?
- sigmar 11y ago
  >I think it's only loading the URL to the profile photo image Sorry, by "it" I should have written "the client." I meant to suggest my question of whether that is where their client OOM errors are coming from.
  - mikeyk 11y ago
    We load a small thumbnail; it's the extra memory allocated to strings that was the main factor that helped when we reduced the # of comments sent down.
- madeofpalk 11y ago
  Many 'big operations' will use some sort of image-resizer CDN, whether something custom made in-house, off-the-shelf/open source (like thumbor), or a CDN like Imgix. To prevent anyone from fiddling with the URL to generate thousands of differently sized images, they'll often have a way to 'sign' the URL to ensure people can't do this sort of attack. This can be expensive, depending on how its done I guess.
- x1024 11y ago
  It could be a hash operation, yes. But would it really be necessary to make it a cryptographic hash? It would explain the performance issues, yes. But who uses cryptographically-secure hashing for use-cases where the answer is "MD5"?

by sigmar 11y ago

sloanesturz 11y ago

I think it's only loading the URL to the profile photo image, which is stored in the CDN. Calculating the URL is, apparently, the slow factor. Maybe it requires some type of cryptographic operation that results in heavy CPU use?

sigmar 11y ago
>I think it's only loading the URL to the profile photo image Sorry, by "it" I should have written "the client." I meant to suggest my question of whether that is where their client OOM errors are coming from.
- mikeyk 11y ago
  We load a small thumbnail; it's the extra memory allocated to strings that was the main factor that helped when we reduced the # of comments sent down.
madeofpalk 11y ago
Many 'big operations' will use some sort of image-resizer CDN, whether something custom made in-house, off-the-shelf/open source (like thumbor), or a CDN like Imgix. To prevent anyone from fiddling with the URL to generate thousands of differently sized images, they'll often have a way to 'sign' the URL to ensure people can't do this sort of attack. This can be expensive, depending on how its done I guess.
x1024 11y ago
It could be a hash operation, yes. But would it really be necessary to make it a cryptographic hash? It would explain the performance issues, yes. But who uses cryptographically-secure hashing for use-cases where the answer is "MD5"?