-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rails 7 - slow store time Carrierwave S3 AWS fog upload ONLY in localhost #2605
Comments
Is this a copy of #2615? do you need both open? |
sorry for the duplication, I got some issues of formatting of the question and I posted two of the same. Have you some ideas of the causes? |
Anyone has some ideas of the cause of this? |
I've been experiencing this as well recently. Additionally any automated tests that interact with file uploads will fail because of timeouts, so this is more than an inconvenience but actually something impacting the development process. By logging the various steps I could see that it happens during the |
Thank you @YSavir Yes, the same for me. Even if I'm looking at the console, I see the database quickly updates and the server idle for a long time. After your confirmation it seems that it's clear that it is due to store action. I am working on a Macbook pro M1, maybe this should be an useful information. Unfortunately I can't do any testing on other machines. |
I solved the problem: all I had to do was post about it here. Just like that months worths of timeouts and sluggish uploads went away. No code changes, no dependency updates, nothing changed at all... but it's working smoothly now, at least in what I've tested so far. No idea what happened there, but 🤷🏼. It's been a problem for the past few months and now it's fine. Wish I had further input. Only thing I can think of is that I added logging before and after each uploader hook and |
@YSavir , wow this may really change development times. |
The various callbacks are found here in the documentation. For each callback hook I had a |
ok I have tested all the callbacks as you suggested, @YSavir. I added the logs at the remove hook and everything is still the same :-( |
Still getting this issue, has someone some news? |
I have been following the thread, but since I can't update our project to Rails 7 yet I can't contribute. |
Yeah have a similar issue here. Its unbearable. I tried digging into the root cause with fog-aws but as soon as Also i was a big shocked about the huge amount of files and layers of indirecton needed to upload a file to s3 in aws/fog but that is maybe something for a different story. |
I'm also on an M2 MacBook, and along with the slow store time, I was also getting After reading this issue on CarrierWave.configure do |config|
...
config.fog_credentials = {
...,
connection_options: {
write_timeout: 5
}
}
end Of course, this does not resolve the issue of the slow uploads, but at least I don't receive timeouts anymore, so I leave my solution here in case someone else has the same issue. |
Has anybody got any solution? this happens also when removing images, I don't know if this is clear. |
@robertoboldi I just rolled my own upload and skippped all of this |
yes it seems a good idea. |
Something dumb like this would get u started Some lib thing class Uploader
def get_url(variant)
"https://xxx.ams3.digitaloceanspaces.com/#{get_key(variant)}"
end
def initialize(model)
@model = model
end
def magick(upload, &block)
return unless upload
@image = MiniMagick::Image.read(upload.tempfile)
yield
@image = nil
end
def variant(name, size)
Tempfile.open { |xx|
@image.resize(size)
@image.write (xx)
s3 = Aws::S3::Client.new(endpoint: "https://ams3.digitaloceanspaces.com")
File.open(xx, "rb") do |file|
s3.put_object(
acl: "public-read",
body: file,
bucket: "xx",
key: get_key(name),
)
end
}
end
end
class SpotUploader < Uploader
def get_key(variant)
"#{Rails.env}/spots/#{@model.id}/#{variant}.jpg"
end
def upload(upload)
magick(upload) do
variant(:thumb, "612x612")
variant(:tiny, "50x50")
end
end
end In the controller class PageController < Controller
def create
@spot = Spot.new(spot_params)
@spot.user = User.first
@spot.category = :building
@spot.difficulty = "5"
@spot.save
loader = SpotUploader.new(@spot)
loader.upload(spot_params[:file])
@spot.file = loader.get_url(:thumb)
@spot.save
render json: merge_cover_photo(@spot)
end
end Gems gem "mini_magick"
gem "aws-sdk-s3" |
@emilebosch Wow, the full code! |
No worry remember this is crap and needs love and attention and mime types and security checks and all that jazz |
In a production environment, after updating carrierwave to the latest version 3.0.5, saving documents began to take a long time to process. I studied the gem for a long time, and decided to set logging to save fog and noticed that the |
Resolved for me by site If you see extra requests to cloud storage when loading files, this should help you.
I should read README carefully) |
thank you, it seems to really increase upload speed, but I got strange behaviour: STILL ONLY IN LOCALHOST
I tried different image formats and dimensions from 100 KB to 1.5MB and literally measured upload time from, click to reload of the page looking at my rails console. I'll read the readme as soon I have some time to dedicate to this. ...and thanks again Xeej! |
I have switched to Rails 7 and I found some issues when I upload image in my localhost.
It is mandatory to manage, import, rework and upload images on a local environment, and Images (and attachments) needs to be uploaded from localhost.
The system idles for 10/30 sec even for 5kb images, picture will be correctly loaded.
Furthermore the server is also very slow when deleting images.
I underline that this happens only in localhost, not production.
My system is a last generation M1 MacBook pro.
Here is my code:
carrierwave.rb
image_uploader.rb
the issue is shown during uploads in my active admin page, with standard form uploader, in console and also in seeds.rb file.
The gems I'm using for upload are:
What I have tried:
It seems the issue is related to the effective upload time, maybe the fog?
EDIT:
after some analysis on logs I am pretty sure that the issue is due to the store time that is very long.
Processing time is really fast, while cache time could be improved, but we may survive with it.
The text was updated successfully, but these errors were encountered: