载波或蜻蜓

Question

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

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

我想知道人们是否提到了性能测试或任何比较两者的测试。

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

Answer 1

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

蜻蜓在飞行中进行处理，即

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

Answer 2

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

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

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

载波：

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

蜻蜓：

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

最后我两个都用了。

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

Answer 3

回形针

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

优势

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

载波

此 gem 提供了一种从 Ruby 应用程序上传文件的简单且极其灵活的方法。它适用于基于 Rack 的 Web 应用程序，例如 Ruby on Rails。

优势

1. 简单模型实体集成。添加单个字符串image 属性以引用上传的图像。
2. 用于上传和远程获取图像的“魔术”模型方法。
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 等外部事物有很好的支持，甚至可以与 cloudinary 等第 3 方图像管理一起使用该解决方案似乎最完整，支持几乎所有内容，但解决方案也更加混乱（对我来说至少）因为您需要处理更多代码。需要了解 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. 如果你发现一些错误并报告它，开发团队真的很忙。他们会告诉你自己修复错误。这似乎是一个在业余时间改进的个人项目。对我来说，它不适用于有截止日期的专业项目。
7. 本身不支持 mongomapper
8. 为每个生成的文件/拇指使用存储空间。如果您使用普通文件存储，您可能会用完 inode！

蜻蜓

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

优势

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

缺点

1. 如果您没有缓存代理、rack::cache 或类似服务器，则每次请求都会占用 CPU。
2. 如果需要，无法将拇指作为文件访问。

参考文献

• Ruby on Rails Image Uploads with CarrierWave and Cloudinary
• Rails 3 paperclip vs carrierwave vs dragonfly vs attachment_fu

Answer 4

其他人写了很好的总结，我只想说，根据我们的经验，Dragonfly 设置需要更多的维护，并且由于一些开发人员的疏忽，我们也被大量的孤立图像卡住了删除原件后。普通载波不会发生这种情况。 附言我们迁移到 cloudinary（并使用carrierwave）并且对它很满意。