Performance problem generating URL for thousands of images, due to hitting HDD for each one

Hi,

I have a model where I’m using Carrierwave to let users upload their
avatars. I have one version for the avatar, cropped to a square called
“cropped”.

class User
mount_uploader :avatar, AvatarUploader
end

class AvatarUploader < ImageUploader
version :cropped do
process :crop
end
end

In one of my pages, where I’m listing a few thousand users, each with
their
avatar, the call to generate the URL for these images is taking a long
time.

The problem seems to be that just by accessing to the model attribute
that
has the uploader mounted, Carrierwave seems to be hitting the disk to
either read the file, check that it exists, or something. In other
words,
calling:

user.avatar
user.avatar.cropped
user.avatar.present?
user.avatar.anything_really

All of these hit the HDD.

In the worst case I found, for one of our clients that have a massive
amount of data, the page renders in 10 seconds my dev machine, and 30
seconds on the server. This page render implies about 1200 calls to
“user.avatar.cropped”. The difference seems to be due to SSD vs HDD (or
maybe overhead due to VM’s, not sure). OS Disk Caching does kick in,
though, since rendering the same page for a second time in the server
takes
10 seconds, presumably since disk hits are cached.

If I generate the URL “manually”, instead of using CarrierWave, it’s
back
down to 10 seconds in all machines, so it’s definitely Carrierwave
that’s
causing the slowdown.

It seems like hitting the HDD shouldn’t be necessary to generate the
path.
Is there any way to avoid this, or to work around this problem?

(NOTE: I know 10 seconds is atrocious for a page anyway, we’re doing
stuff
to solve this, but site-wide, we have lots of pages that show tons of
avatars, and we’re getting a slowdown due to these HDD hits, so we’d
like
to improve them, without having to manually generate the URLs, since the
abstraction Carrierwave provides is awesome)

Any thoughts will be greatly appreciated.

Thank you!
Daniel

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs