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