28

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

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

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

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

4

4 回答 4

33

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

但是如果你使用内置的 Rails 缓存，Carrierwave 的性能会更好，因为文件可以在没有任何处理的情况下加载。如果你不做任何处理，那也没关系。

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

载波：

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

蜻蜓：

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

我最终都使用了。

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

于 2011-01-10T10:35:07.010 回答
10

我使用蜻蜓只是因为carrierwave放弃了对mongomapper的支持，而回形针在没有一些黑客攻击的情况下无法使用mongomapper。

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

旨在用于缓存代理（如 Varnish、Squid 或 Rack::Cache）之后，这样虽然第一个请求可能需要一些时间，但后续请求应该非常快！

于 2010-12-26T18:06:22.743 回答
5

回形针

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

优点

  1. 验证，Paperclip 引入了几个验证器来验证您的附件： AttachmentContentTypeValidator AttachmentPresenceValidator 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 的工作量。

载波

这个 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、续集，甚至可以与 3rd 方图像管理一起使用，例如 cloudinary 该解决方案似乎最完整，支持覆盖几乎所有内容，但该解决方案也更加混乱（至少对我而言），因为您需要更多代码处理。需要了解 CarrierWave 采用的模块化方法。不知道您使用哪种流行的 S3 客户端，同时支持 aws/s3 和 right_aws。它也与 ORM 无关，并且与 Active Record 没有紧密耦合。Paperclip 的紧密耦合让我们在工作中有些悲痛。支持 aws/s3 和 right_aws。它也与 ORM 无关，并且与 Active Record 没有紧密耦合。Paperclip 的紧密耦合让我们在工作中有些悲痛。支持 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. 为每个生成的文件/拇指使用存储空间。如果您使用普通文件存储，您可能会用完 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. 如果需要，无法将拇指作为文件访问。

参考

于 2015-06-21T18:29:41.037 回答
2

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

于 2015-06-21T20:57:42.897 回答