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

Question

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

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

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

新遗物报告

事务跟踪

SQL 跟踪

行为相似：在此处输入图像描述

刚刚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会有这种奇怪的表现。

score 0 · Accepted Answer

三个线索，但不是全部：

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

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

强制性：您不会让用户直接上传到您的测功机，是吗？

1 回答 1