ruby-on-rails - 如何在 Heroku 上分析不一致的 H12 超时

Question

我的用户在 Heroku 上偶尔会遇到请求超时。不幸的是，我无法一致地重现它们，这使得它们很难调试。有很多机会可以提高绩效 - 例如通过减少每个请求的大量数据库查询并添加更多缓存 - 但如果不进行分析，那就是盲目的尝试。

根据我们的 New Relic 分析，许多请求在服务器上花费 1 到 5 秒的时间。我知道这太慢了，但远未达到超时所需的 30 秒。

New Relic 上的错误选项卡向我显示了发生超时的几个不同的数据库查询，但这些查询并不是特别慢的查询，并且每次崩溃都可能是不同的查询。同样，对于同一 URL，有时会显示数据库查询，有时则不会显示。

我如何了解这些特定情况下发生了什么？例如。如何查看发生超时时在数据库中花费的时间，以及没有错误时在数据库中花费的时间？

我的一个假设是数据库在某些情况下会被锁定；也许是阅读和写作的结合。

Answer 1

你可能已经看过了，但 Heroku 有一个 doc有一些关于请求超时的良好背景。

如果您的请求花费了很长时间，并且在请求完成之前为其提供服务的进程没有被终止，那么它们应该生成事务跟踪，以提供有关花费太长时间的各个事务的详细信息。

如果您使用的是 Unicorn，则可能不会发生这种情况，因为请求花费的时间足够长，以至于它们与 Unicorn 的 timeout 相冲突。 (之后服务这些请求的工作人员将被强行杀死，从而不给 New Relic 特工足够的时间来报告)。

我建议采用两步方法:

1. 配置rack-timeout中间件的超时时间低于 Heroku 的 30 秒超时值。如果此方法有效，它将通过引发 Timeout::Error 来终止耗时超过超时的请求，并且此类请求应在 New Relic 中生成事务跟踪。
2. 如果这没有产生任何结果(可能是这样，因为rack-timeout依赖于Ruby的stdlib Timeout类，它有 some limitations )，您可以尝试将 Unicorn 请求处理超时从默认值提高60 年代(假设您使用的是 Unicorn)。请注意，在这种情况下，长时间运行的请求会占用 Unicorn 工作人员更长的时间，这可能会进一步减慢您的网站速度，因此请将此作为最后的手段。