Carrierwave + S3存储+计数器缓存耗时太长

时间：2013-11-05 13:41:30

标签： heroku amazon-s3 carrierwave counter-cache excon

我有一个简单的应用程序，通过API接收POSTed图像，并通过Carrierwave将它们发送到S3。我的照片表也有一个counter_cache。

80％的时间我的交易时间是巨大的，比如60秒或更长时间，超过90％的时间用于将图像上传到S3并更新counter_cache。

有没有人知道为什么上传时间如此之大以及为什么反缓存查询需要这么长时间呢？

New Relic report

Transaction Trace

SQL Trace

刚刚在http://carrierwave-s3-upload-test.herokuapp.com

上添加了一些照片

行为类似： enter image description here

刚刚从我的代码中删除counter_cache并进行了更多上传....奇怪的行为再次出现。 enter image description here

编辑1

上次批量上传的日志。 EXCON_DEBUG设置为True：https://gist.github.com/rafaelcgo/561f516a85823e30fbad

编辑2

我的日志没有显示任何EXCON输出信息。所以我意识到我正在使用雾1.3.1。更新为Fog 1.19.0（使用较新版本的excon gem），现在一切正常。 enter image description here

提示..如果您需要调试外部连接，请使用较新版本的excon并设置env EXCON_DEBUG = true以查看一些详细信息，如下所示：https://gist.github.com/geemus/8097874

编辑3

伙计们，更新了gem fog，现在很好。不知道为什么旧版本的雾和excon有这种奇怪的表现。

1 个答案:

答案 0 :(得分：0)

三条线索，但不是整个故事：

  1. CarrierWave将文件传输到s3 inside your database transaction。因为counter_cache的更新也发生在事务内部，所以你的基准测试代码可能认为更新是永远需要的，而实际上它是永远需要的文件传输。

  2. 最后我检查过，只要你看到，就不可能让heroku应用程序dyno维持连接。如果您的同步上传时间超过about 30秒，您应该会在日志中看到H12或H15错误。有关heroku超时的更多信息here。

  3. 您是否尝试过更新雾？ 1.3.1是一年半，他们可能已经修复了一两个错误。

    4. 过去，唯一想到的是你正在上传一个史诗级别的文件。我一直对从heroku到s3能够实现的延迟和吞吐量感到失望，因此也可以参与其中。

    强制性：您不允许用户直接上传到您的dyno，are you?

相关问题
最新问题