我在Heroku上托管了一个Rails 3.2应用程序，每天在Rails应用程序中会出现2-3次超时。这些是不是 H12请求超时，而是发生在Rails堆栈中的某个地方的超时。因此，它们实际上会在网站上产生异常，并出现在我的Airbrake日志中。
超时发生的地方似乎完全是随机的;有时它在像Formtastic这样的gem中，或者在HAML视图中，或者在ActiveRecord代码中。您可以在这里看到一些回溯的示例:https://gist.github.com/dpmccabe/5238273
这个网站没有太多的流量，在两个dynos上运行良好(尽管它们会自动扩展，这要归功于Adept scale插件)。HTTP_X_HEROKU_QUEUE_WAIT_TIME报头通常是低或零，所以我不认为这是路由问题。我甚至尝试从瘦切换到独角兽没有效果(我的独角兽)。
这些超时异常似乎在整个应用程序中随机发生，这一事实并没有给我太多的信息。我确实有New Relic，但我不确定如何调试它。什么好主意吗?
我也遇到过同样的问题。虽然我还没有解决这个问题，但我想我应该和大家分享一下我目前所看到的。我正在使用rack-timeout gem(基于您的回溯，看起来您也是如此)并将超时设置为15秒。看看新的遗物，我的应用服务器对任何请求的平均响应时间都在200毫秒以下。然而，像你一样，我一天会有2-3个错误，看起来像这样:
undefined method `result' for #<Timeout::Error: execution expired>
错误发生在各种各样的操作中，似乎没有任何操作特别容易产生错误。甚至在简单的CRUD DELETE操作上也会出现错误。我在Heroku的Cedar堆栈上运行rails 3.2应用程序。我运行两个web dynos，每个dynos有3个独角兽工人。它们都始终低于512mb的限制。
到目前为止，我发现的唯一线索是，我经常在日志中超时附近看到类似以下的东西:
[AMBER] LOG: process 21289 acquired ShareLock on transaction 105259 after 32366.132 ms
你看到类似的东西了吗?这可能是一个DB动作锁定记录导致超时，我不太确定。
我在heroku上的应用程序也遇到了同样的问题。
我检查了日志，发现很少有请求的处理时间超过30秒，这导致了heroku上的超时错误。在我的情况下，问题是打印到日志，我有一个临时服务器，有很多输入和输出数据打印到服务器日志，这需要超过30秒的打印，heroku会假设请求仍在处理中，即使在从远程api收到响应后，因为它还没有完成打印数据到日志。
因此，我删除了所有打印输入(由代码构造的输入xml数据)和输出(从api接收的xml数据)数据到日志的print语句。
- 所以我建议你检查日志，看看请求是否需要超过30秒来处理
- 检查您是否正在打印需要时间在日志上打印的数据(用于调试目的)。
根据Heroku Dev Center的说法，如果完成请求的时间超过30秒，路由器将终止请求。您可以使用rack-timeout gem来查找瓶颈。请将超时时间设置为小于30秒
Rack::Timeout.timeout = 15 # seconds
如果您有多个并行请求，请考虑使用Unicorn