Carrierwave或Dragonfly

Question

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

从环顾四周来看,似乎载波采用更传统的风格,您可以在保存时处理文件,而蜻蜓是中间件,因此它允许您即时处理.

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

此外,只是好奇人们的意见是什么,他们喜欢什么,当然为什么他们喜欢它.

Answer 1

取决于设置.正如Senthil所写,只要你在前面有一个缓存代理,它对Dragonfly来说就没问题了.

但是如果你使用内置的rails缓存,Carrierwave会表现得更好,因为文件可以在没有任何处理的情况下加载.如果您不进行任何处理,则无关紧要.

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

Carrierwave:

• 优点
  • 上传时生成大拇指(节省CPU时间)
  • 可以直接从静态/缓存文档中使用文件
  • 不需要任何缓存前端
  • 支持各种存储后端(S3,Cloudfiles,GridFS,普通文件),如果需要,可以轻松扩展到新的存储类型.
• 缺点
  • 上传时生成大拇指(diffucult生成新的thumbsizes)
  • 本地不支持mongomapper
  • 为每个生成的文件/拇指使用存储空间.如果使用普通文件存储,则可能会用完inode!

蜻蜓:

• 优点
  • 应该使用mongomapper,因为它只扩展了ActiveModel
  • 动态生成大拇指(更容易创建新的布局/拇指)
  • 只存储一个文件!节省空间:)
• 缺点
  • 如果您没有cache-proxy,rack :: cache等,请在每个请求上吃CPU.
  • 如果需要,无法将thumb作为文件访问.

最后我最终都使用了这两个.

未来的愿望是让carrierwave再次支持MongoMapper.在各种情况下使用后,我发现MongoMapper(rails3分支)中的功能始终有效,并且使用插件很容易扩展.对于Mongoid来说,现在不能说同样的话,但这可能会改变.

Answer 2

我之所以使用蜻蜓只是因为载波减少了对mongomapper的支持而且没有一些黑客,回形针就无法使用mongomapper.

Dragonfly即时进行处理,即

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

Answer 3

回形针

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

好处

1. 验证,Paperclip引入了几个验证您的附件的验证器:AttachmentContentTypeValidator AttachmentPresenceValidator AttachmentSizeValidator
2. 删除附件将属性设置为nil并保存. @user.avatar = nil @user.save
3. 对于使用activerecord的有机Rails环境而言,Paperclip更好,而不是所有其他替代方案.Paperclip对于初学者开发人员来说更容易处理,并且还为高级开发人员提供了高级功能.
4. Paperclip的忠实粉丝,因为它不需要RMagick,所以很容易将其设置为发布到Amazon S3并声明模型中的所有内容(验证等)使事情保持清洁.
5. 关于多个文件上传和进度反馈,Paperclip和Attachment_fu都可以实现,但两者通常都需要使用iframe和Apache来解决问题.

CarrierWave

这个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和其他工具之间切换图像处理模块.您还可以在dev env中使用本地文件系统,并切换到生产系统中的S3存储.Carrierwave对DataMapper,Mongoid,Sequel等外部产品有很好的支持,甚至可以用于第三方图像管理,例如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. 为每个生成的文件/拇指使用存储空间.如果使用普通文件存储,则可能会用完inode!

蜻蜓

1. 关于Dragonfly的令人印象深刻的事情,它将它与大多数其他图像处理插件分开,是它允许从视图中动态调整大小.
2. 不需要在单独的文件中配置缩略图大小调整或其他操作是一个巨大的时间和挫折节省.它使Rails视图代码成为image_tag @product.image.thumb('150x150#')可能.
3. 通过缓存可以实现神奇的魔力.该插件不是在上传时构建处理后的版本,而是链接到图像的各个版本,而是在请求时生成图像.虽然这对于第一次加载是一个问题,但是默认情况下使用Rack :: Cache会为所有后续加载缓存新创建的图像,但是如果扩展成为问题,则可以使用其他更强大的解决方案.

好处

1. 我会经常改变图像尺寸吗？示例:如果您希望让用户更改其图片的大小(或者由于其他原因需要灵活性),或者真正快速开发.是的:蜻蜓号:Carrierwave或Paperclip
2. 可以毫无困难地与mongomapper一起使用
3. 只要您使用缓存代理,性能应该没问题
4. 应该使用mongomapper(它只扩展ActiveModel)
5. 动态生成大拇指(更容易创建新的布局/拇指)
6. 只存储一个文件!节省空间
7. 动态完成处理(意味着在缓存代理后面使用,例如Varnish,Squid或Rack :: Cache,这样第一个请求可能需要一些时间,后续请求应该超级快)

缺点

1. 如果您没有缓存代理rack::cache或类似的,请在每个请求上吃CPU .
2. 如果需要,无法将thumb作为文件访问.

参考

• 使用CarrierWave和Cloudinary进行Ruby on Rails图像上传
• Rails 3 paperclip vs carrierwave vs dragonfly vs attachment_fu