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

Question

我有一个简单的应用程序,通过API接收POSTed图像,并通过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,现在它很甜蜜.不知道为什么旧版本的雾和excon有这种奇怪的表现.

Answer 1

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

1. CarrierWave 将文件传输到数据库事务内的s3 。由于 counter_cache 的更新也发生在事务内部，因此您的基准测试代码可能认为更新会永远持续，而实际上是文件传输永远持续。

2. 最后我检查了一下，heroku 应用程序 dyno 甚至不可能像您所看到的那样维持连接。如果您的同步上传时间超过了大约 30秒，您应该会在日志中看到 H12 或 H15 错误。有关 heroku 超时的更多信息，请参见此处。

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

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

义务：你不会让用户直接上传到你的dyno，是吗？