【问题标题】:Caching dynamic images in Rails在 Rails 中缓存动态图像
【发布时间】:2011-08-13 00:09:44
【问题描述】:

我正在使用 rmagick gem 从控制器生成动态图像。控制器将 id 作为参数,查找模型,在现有图像上写入文本,然后输出。

我已经运行了一些基准测试,比较了为每个请求生成它与写入磁盘并使用send_data 输出它(如果它已经存在)。我没有注意到这两种方法在每秒请求数方面的差异很大。

是否有缓存图像或将其写入磁盘而不是为每个请求动态生成图像的最佳做法?生成后,这些图像将大部分保持静态,但我还希望可以选择在特定时间间隔后重新生成它。

【问题讨论】:

    标签: ruby-on-rails caching rmagick


    【解决方案1】:

    最佳做法是缓存生成的图像并允许网络服务器提供它们。

    在 Rails 应用程序前使用 Apache 或 Nginx 等网络服务器,并确保将图像写入网络服务器可以提供服务的位置。因此,如果您的 Rails 路由计算结果为 /dynamic_images/3.png(它调用 dynamic_images_controller 操作 show,id=3 和 format=png),将该图像写入 public/dynamic_images/3.png 并在控制器中使用 send_file 发送它。

    下次请求该文件 (/dynamic_images/3.png) 时,网络服务器将很乐意为它提供服务(缓存),Rails 应用程序将永远不会受到攻击。

    对于高级需求,例如重新生成图像和清理控制器代码,请查看paperclip gem。

    【讨论】:

    • 在此设置的生产版本中,这是否意味着您在 Puma 或任何运行 Rails 的每个应用服务器上运行 Apache 或 Nginx?
    【解决方案2】:

    只是一个想法(从未尝试过):为什么不使用 memache 存储图像(尤其是动态生成的图像)​​?

    Rails.cache.write("MY_IMAGE", image)

    【讨论】:

    • 我其实很喜欢这个选项。见RailsCasts #115
    • Memcache 的最大密钥大小默认为 1MB,据我记得,它缓存大对象的效果并不好(存储桶大小/调整大小,尽管现在可能已经修复)。对于图像来说,这可能是一个糟糕的选择。此外,这意味着在许多生产部署中(至少潜在地)远程命中,这...具有权衡:生成工作更少,但花费更多检索和负担服务,本质上是文件服务,实际上不是设计的为此,不需要这样做。如果你想把它放在内存中,你可能希望它在 Rails 进程中是本地的。
    【解决方案3】:

    您应该将缓存的图像放入这样的目录中,Web 服务器将从该目录中提供这些图像。您不想为此使用 send_data - 这太慢了。 此外,您可能希望忽略 VCS 中的该目录。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2021-03-27
      • 2011-04-01
      • 1970-01-01
      • 1970-01-01
      • 2011-03-29
      • 2011-04-12
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多