载波或蜻蜓

Question

我一直在研究 Rails 文件上传工具，对我来说最有吸引力和最有趣的是 Carrierwave 和 Dragonfly。

从环顾四周来看，Carrierwave 似乎采用了更传统的风格，您可以在保存时处理文件，而 Dragonfly 是中间件，因此它允许您即时处理。

我想知道人们是否有任何关于性能测试或比较两者的测试的参考。

另外，只是想知道人们对两者的看法是什么，他们更喜欢哪一个，当然还有他们为什么喜欢它。

Answer 1

取决于设置。正如 Senthil 所写，只要前面有一个缓存代理，就可以使用 Dragonfly。

但如果您使用内置的 Rails 缓存，Carrierwave 的性能会更好，因为文件无需任何处理即可加载。如果你不做任何处理，那就没关系。

以下是我在使用 Mongomapper 的项目中考虑图像时的总结：

Carrierwave：

• 优点
  • 上传时生成赞（节省 CPU 时间）
  • 可以直接使用静态/缓存文档中的文件
  • 不需要任何前端缓存
  • 支持各种存储后端（S3、Cloudfiles、GridFS、普通文件），并可根据需要轻松扩展到新的存储类型。
• 缺点
  • 上传时生成拇指（很难生成新的拇指大小）
  • 本身不支持 mongomapper
  • 为生成的每个文件/缩略图使用存储空间。如果您使用普通文件存储，您可能会用完 inode！

蜻蜓：

• 优点
  • 应与 mongomapper 配合使用，因为它仅扩展 ActiveModel
  • 动态生成拇指（更容易创建新布局/拇指大小）
  • 仅存储一个文件！节省空间:)
• 缺点
  • 如果您没有缓存代理、rack::cache 或类似设备，则每个请求都会占用 CPU。
  • 如果需要，无法将拇指作为文件进行访问。

我最终使用了两者。

未来的愿望是 Carrierwave 能够再次支持 MongoMapper。在各种情况下使用两者之后，我发现 MongoMapper（rails3 分支）中的功能始终有效，并且很容易使用插件进行扩展。目前还不能对 Mongoid 说同样的话，但这可能会改变。

Answer 2

我使用 Dragonfly 只是因为 Carrierwave 放弃了对 mongomapper 的支持，而回形针在没有一些 hack 的情况下无法使用 mongomapper。

蜻蜓进行即时处理，即

用于后面
缓存代理，例如 Varnish、Squid 或
Rack::Cache，这样当第一个
请求可能需要一些时间，后续
请求应该超级快！

Answer 3

Paperclip

Paperclip 旨在作为 Active Record 的简单文件附件库。其背后的目的是使设置尽可能简单，并尽可能像对待其他属性一样对待文件。这意味着它们不会保存到磁盘上的最终位置，如果设置为 nil，它们也不会被删除，直到调用 ActiveRecord::Base#save 为止。如果需要，它会根据大小和存在来管理验证。如果需要，它可以将指定的图像转换为缩略图，并且先决条件就像安装 ImageMagick 一样简单（对于大多数现代基于 Unix 的系统来说，就像安装正确的软件包一样简单）。附加文件保存到文件系统中，并通过易于理解的规范在浏览器中引用，该规范具有合理且有用的默认值。

优点

1. 验证，Paperclip 引入了几个验证器来验证您的附件：
   附件内容类型验证器
   附件存在验证器
   AttachmentSizeValidator
2. 删除附件
   将属性设置为 nil 并保存。
   @user.avatar = nil @user.save
3. Paperclip 更适合使用 activerecord 的有机 Rails 环境，而不是所有其他替代方案。 Paperclip 对于初级 Rails 开发人员来说更容易处理，并且它还为高级开发人员提供了高级功能。
4. Paperclip 的忠实粉丝，因为它不需要 RMagick，可以非常轻松地将其设置为通过 Amazon S3 进行发布，并声明模型中的所有内容（验证等）以保持简洁。
5. 对于多个文件上传和进度反馈，Paperclip 和 Attachment_fu 都可以实现，但两者通常都需要使用 iframe 和 Apache 才能工作。

CarrierWave

这个 gem 提供了一种简单且极其灵活的方法来从 Ruby 应用程序上传文件。它与基于 Rack 的 Web 应用程序配合良好，例如 Ruby on Rails。

优点

1. 简单模型实体集成。添加单个字符串 image 属性来引用上传的图像。
2. 用于上传和远程获取图像的“Magic”模型方法。
3. HTML 文件上传集成使用标准文件标签和另一个隐藏标签来维护已上传的“缓存”版本。
4. 用于创建具有不同尺寸和格式的派生图像版本的简单界面。图像处理工具很好地隐藏在幕后。
5. 用于获取图像的公共 URL 及其用于 HTML 嵌入的调整大小版本的模型方法。
6. 如果内置 Rails 缓存，Carrierwave 的性能会更好，因为文件无需任何处理即可加载。如果你不做任何处理，那就没关系。
7. 上传时生成拇指（节省 CPU 时间）
8. 可以直接使用静态/缓存文档中的文件
9. 不需要任何前端缓存
10. 支持各种存储后端（S3、Cloudfiles、GridFS、普通文件） 如果需要，可以轻松扩展到新的存储类型。
    事实之一是它不会使您的模型配置混乱。您可以改为定义上传器类。它允许您轻松地重用、扩展等您的上传配置。
    我们最喜欢的是 CarrierWave 非常模块化。您可以轻松地在本地文件系统、基于云的 AWS S3 等之间切换存储​​引擎。您可以在 RMagick、MiniMagick 和其他工具之间切换图像处理模块。您还可以在开发环境中使用本地文件系统，并在生产系统中切换到 S3 存储。 Carrierwave 对外部事物（如 DataMapper、Mongoid、Sequel）有很好的支持，甚至可以与第 3 方图像管理（如 cloudinary）一起使用该解决方案似乎是最完整的，对任何事物的支持范围都很完整，但该解决方案也更加混乱（对我来说）至少）因为您需要处理更多代码。需要了解 CarrierWave 采用的模块化方法。它不知道您使用哪种流行的 S3 客户端，支持 aws/s3 和 right_aws。它还与 ORM 无关，并且与 Active Record 不紧密耦合。 Paperclip 的紧密耦合给我们的工作带来了一些痛苦。

缺点

1. 您无法验证文件大小。有一篇 wiki 文章解释了如何做到这一点，但它不起作用。
2. 使用 MiniMagick 时完整性验证不起作用（如果您担心 RAM 使用情况，则非常方便）。您可以上传损坏的图像文件，CarrierWave 一开始会抛出错误，但下次会吞掉它。
3. 您无法删除原始文件。您可以调整它的大小、压缩等。有一篇 wiki 文章解释了如何做到这一点，但它又不起作用。
4. 它依赖于外部库，例如 RMagick 或 MiniMagick。 Paperclip 直接与转换命令行 (ImageMagick) 一起使用。因此，如果您在使用 Minimagick 时遇到问题（我也遇到过），您将在 Google 搜索中损失数小时的时间。在撰写本文时，RMagick 和 Minimagick 都已被放弃（我联系了 Minimagic 的作者，但没有回复）。
5. 它需要一些配置文件。这被视为一种优势，但我不喜欢在我的项目中只为一个 gem 提供单个配置文件。模型中的配置对我来说似乎更自然。无论如何，这是个人品味的问题。
6. 如果你发现了一些bug并报告了它，那么开发团队真的缺席而且很忙。他们会告诉你自己修复错误。这似乎是一个在业余时间改进的个人项目。对我来说，这对于有截止日期的专业项目来说是无效的。
7. 本身不支持 mongomapper
8. 对生成的每个文件/拇指使用存储空间。如果您使用普通文件存储，您可能会用完索引节点！

Dragonfly

1. Dragonfly 令人印象深刻的一点是它与大多数其他图像处理插件的区别在于它允许从视图中即时调整大小。
2. 无需在单独的文件中配置缩略图大小或其他操作，可以节省大量时间并减少挫败感。它使得 Rails 视图代码如 image_tag @product.image.thumb('150x150#') 成为可能。
3. 神奇的一切都是通过缓存实现的。该插件不是在上传时构建处理后的版本，然后链接到图像的各个版本，而是根据请求生成图像。虽然这对于第一次加载来说是一个问题，但默认情况下使用 Rack::Cache 为所有后续加载新创建的图像进行 http 缓存，尽管如果缩放成为问题，也可以使用其他更强大的解决方案。

优点

1. 我会经常更改图像尺寸吗？示例：如果您想让用户更改图片的大小（或者由于其他原因您需要尺寸的灵活性），或者开发速度非常快。
   是的：蜻蜓
   否：Carrierwave 或 Paperclip
2. 可以与 mongomapper 一起使用，没有任何问题
3. 只要您使用缓存代理，性能就应该很好
4. 应该与 mongomapper 一起使用（它只扩展 ActiveModel）
5. 动态生成拇指（更容易创建新的布局/拇指大小）
6. 仅存储一个文件！节省空间 动态
7. 处理（旨在在 Varnish、Squid 或 Rack::Cache 等缓存代理后面使用，因此虽然第一个请求可能需要一些时间，但后续请求应该超级

）

1. 快 如果您没有缓存代理、rack::cache 或类似的设备，则每个请求都会占用 CPU 资源。
2. 如果需要，无法将拇指作为文件访问。

• 使用 CarrierWave 和 Cloudinary 进行 Ruby on Rails 图像上传
• Rails 3 回形针、Carrierwave、Dragonfly 和 Attachment_fu

Answer 4

其他人写了很好的总结，我只是想说，根据我们的经验，Dragonfly 设置需要更多维护，并且由于一些开发人员的疏忽，我们还陷入了许多孤立图像，这些图像在原始图像之后仍然存在被删除。使用普通载波就不会发生这种情况。
PS 我们迁移到了 cloudinary（并使用了它的 Carrierwave）并且对此感到满意。