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

Question

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

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

有没有人知道为什么这个上传时间这么长以及为什么计数器缓存查询需要这么长时间？







刚刚在 http://carrierwave-s3-upload-test.herokuapp.com 上添加了一些照片

行为类似:


刚删除counter_cache从我的代码并做了更多的上传......再次奇怪的行为。


编辑 1

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

编辑 2

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


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

编辑 3

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

Answer 1

三个线索，但不是整个故事:

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

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

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

在那之后，唯一想到的是您正在上传一个史诗级的文件。我对从 heroku 到 s3 能够实现的延迟和吞吐量感到失望，因此这也可能涉及。

强制性:您不会让用户直接上传到您的测功机， are you?