Carrierwave + S3 存储 + 计数器缓存耗时过长答案

【问题标题】：Carrierwave + S3 Storage + Counter Cache Taking too LongCarrierwave + S3 存储 + 计数器缓存耗时过长
【发布时间】：2013-11-16 09:49:36
【问题描述】：

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

80% 的时间我的事务时间很长，比如 60 秒或更多，其中超过 90% 的时间用于将图像上传到 S3 和更新 counter_cache。

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

行为相似：

刚刚从我的代码中删除了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会有这种奇怪的表现。

【问题讨论】：

【解决方案1】：

三个线索，但不是全部：

CarrierWave 将文件传输到 s3 inside your database transaction。因为 counter_cache 的更新也发生在事务内部，所以您的基准测试代码可能认为更新需要永远进行，而实际上是文件传输需要永远进行。
最后我检查了 Heroku 应用程序 dyno 甚至不可能在您看到的情况下维持连接。如果同步上传超过about 30 秒，您应该会在日志中看到 H12 或 H15 错误。有关 heroku 超时的更多信息here。
您是否尝试过更新雾？ 1.3.1 已经一年半了，从那时起他们可能已经修复了一两个错误。

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

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

【讨论】：

我的文件大约 100kb，它们不是那么大......而且我的 S3 存储桶位于 us-east-1，就像 Heroku 一样。 1. 是的，我认为，但交易时间是上传和 counter_cache 更新的总和......但这可能是对新遗物的某种误解。 2. 我收到那些 H12 错误，但在 H12 之后，heroku dyno 继续它正在做的事情。所以我的客户认为文件没有上传到 S3，但过了 30 秒后，文件就在那里。我的主要问题是巨大的上传时间。为什么在同一区域从 Heroku 上传 100kb 到 S3 需要这么长时间？