gpt4 book ai didi

ruby-on-rails - 为什么使用 CarrierWave 和 Fog 从 S3 检索文件 URL 需要这么长时间?

转载 作者:行者123 更新时间:2023-12-04 08:10:34 24 4
gpt4 key购买 nike

我正在使用 CarrierWave (0.9.0), Fog (1.14.0) 和 S3 来存储用户头像。确定给定用户的头像 URL 似乎需要很长时间。后续调用的时间大大减少。

配置/初始化程序/fog.rb

CarrierWave.configure do |config|
config.fog_credentials = {
provider: 'AWS',
aws_access_key_id: ENV['AWS_ACCESS_KEY_ID'],
aws_secret_access_key: ENV['AWS_SECRET_ACCESS_KEY']
}
config.fog_directory = ENV['AWS_S3_BUCKET_AVATAR']
config.fog_public = false
end

user.rb
mount_uploader :avatar, ImageUploader

控制台
irb(main):002:0> Benchmark.measure { user.avatar_url }
=> 0.500000 0.020000 0.520000 ( 0.537884)

irb(main):003:0> Benchmark.measure { user.avatar_url }
=> 0.000000 0.000000 0.000000 ( 0.001830)

irb(main):004:0> Benchmark.measure { user.avatar_url }
=> 0.000000 0.000000 0.000000 ( 0.001454)

irb(main):005:0> Benchmark.measure { user.avatar_url }
=> 0.000000 0.000000 0.000000 ( 0.000998)

New Relic 报告有时 user.avatar_url最多需要 1 秒。什么可能导致这如此缓慢? There's a discussion on slow URL generation for public files ,但我的头像不公开。

更新 1:

在第一次调用之前明确要求 Fog 和 CarrierWave 没有区别,如 false返回,表明它们已经加载。
irb(main):002:0> require 'carrierwave'
=> false
irb(main):003:0> require 'fog'
=> false
irb(main):004:0> Benchmark.measure { user.avatar_url }
=> 0.510000 0.030000 0.540000 ( 1.627774)

更新 2:

这是上传者:
# encoding: utf-8

class ImageUploader < CarrierWave::Uploader::Base

include CarrierWave::RMagick

storage :fog

def store_dir
"uploads/#{model.class.to_s.underscore}/#{mounted_as}/#{model.id}"
end

version :s_32 do
process resize_to_fill: [32, 32]
end

version :s_40 do
process resize_to_fill: [40, 40]
end

version :s_50 do
process resize_to_fill: [50, 50]
end

version :s_115_120 do
process resize_to_fill: [115, 120]
end

version :s_128 do
process resize_to_fill: [128, 128]
end

def extension_white_list
%w(jpg jpeg gif png)
end

end

更新 3:
user.avatar.url似乎没有什么区别:
irb(main):003:0> Benchmark.measure { user.avatar.url }
=> 0.500000 0.030000 0.530000 ( 0.926975)

最佳答案

我认为雾需要可能仍然存在问题(尽管现在不那么明显了)。由于雾中有很多不同的东西,我们很久以前就做出了选择,将许多依赖项的加载推迟到需要它们时。这有加速“雾”的好处,但可能会在某些事情第一次发生时减慢速度。不知道我是怎么忘记这部分的,但是在我的机器上做一些小的基准测试时,考虑到这一点,我当然可以看到速度变慢。

为了解决这个问题,您可以将上面的相关要求基准更改为:

require 'benchmark'
require 'fog'
Fog::Storage.new(
provider: 'AWS',
aws_access_key_id: ENV['AWS_ACCESS_KEY_ID'],
aws_secret_access_key: ENV['AWS_SECRET_ACCESS_KEY']
)
Benchmark.measure { ... }

您不使用该连接似乎有点奇怪,但我将其设置为推迟加载 S3 细节,直到您这样做(例如,这样您就不必加载 S3 细节才能使用EC2)。但是,通过在更早的时间初始化连接,可以避免这种开销。希望这至少能让你更接近你想去的地方。

关于ruby-on-rails - 为什么使用 CarrierWave 和 Fog 从 S3 检索文件 URL 需要这么长时间?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/17950732/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com