Heroku上奇怪的TTFB（到第一个字节的时间）问题

Question

从六月份左右开始，我们在整个站点上经历了奇怪的第一个字节的时间滞后行为。在使用这个站点时，问题是显而易见的（有时应用程序在10-20秒内没有响应），它也存在于通过webpagetest.org进行的瀑布分析中。我们总部设在丹麦，但从任何主持人那里得到这个结果。

为了确认问题，我们html" target="_blank">执行了一个基准测试，向一个简单页面发送300个相同的请求，并测量响应时间。如果我们向首页发送300个请求，中值响应时间在1秒以下，这是相当好的。让我们害怕的是，60个请求所需的时间是原来的两倍，其中40个请求所需的时间超过4秒。有些请求需要多达16秒。

这些缓慢的请求都不会出现在New Relic中，我们使用New Relic进行性能监视。不会出现请求队列，无论我们将web进程扩展到多高，结果都是一样的。尽管如此，我们不能否认问题是由应用程序代码引起的，所以我们尝试了另一个实验，通过机架中间件来响应请求。

Middleware setup:
$ heroku run rake middleware
use Rack::Cache
use ActionDispatch::Static
use TestMiddleware
use Rack::Rewrite
use Rack::Lock
use Rack::Runtime
use Rack::MethodOverride
use ActionDispatch::RequestId
use Rails::Rack::Logger
use ActionDispatch::ShowExceptions
use ActionDispatch::DebugExceptions
use ActionDispatch::RemoteIp
use Rack::Sendfile
use ActionDispatch::Callbacks
use ActiveRecord::ConnectionAdapters::ConnectionManagement
use ActiveRecord::QueryCache
use ActionDispatch::Cookies
use ActionDispatch::Session::DalliStore
use ActionDispatch::Flash
use ActionDispatch::ParamsParser
use ActionDispatch::Head
use Rack::ConditionalGet
use Rack::ETag
use ActionDispatch::BestStandardsSupport
use NewRelic::Rack::BrowserMonitoring
use Rack::RailsExceptional
use OmniAuth::Builder
run AU::Application.routes

然后，我们运行相同的脚本来记录响应时间，并得到几乎相同的结果。响应时间的中值约为130ms（明显更快，因为它没有击中应用程序。但仍有60个请求耗时超过400ms，25个请求耗时超过1秒。同样，有些请求慢至16秒。

一种解释可能与网络或DNS设置上的慢跳有关，但traceroute的结果看起来非常好。

在Heroku上的另一个Rails3.2和Ruby1.9.3应用程序上运行响应脚本证实了这个结果--没有任何奇怪的行为。

Answer 1

原来这是一种请求排队。有时，web服务器很忙，由于heroku只是将随机传入的请求随机地路由到任何dyno，所以我可能会在dyno后面的队列中结束，该队列由于例如html" target="_blank">数据库问题而完全停顿。奇怪的是，这在new relic中很难被注意到（当查看图表中的thin时，取消选中所有其他资源是一个好主意，然后排队突然出现）

2013年编辑21/2：事实证明，它在Newrelic中几乎不引人注目的原因是，它没有被测量！http://rapgenius.com/lemon-money-trees-rap-genius-response-to-heroku-lyrics

我们发现这非常令人沮丧，最后我们离开了Heroku，转而使用专用服务器。这让我们以1/10的成本提高了20倍的性能。此外，我必须说，我们对Heroku感到失望，他们在发生这种情况时否认缓慢是由于他们的基础设施，尽管我们怀疑这一点，并强调了几次。我们甚至得到了这样的答案：

Newrelic 29/8 2012：“看起来，在Ruby代理的可见性开始之前，导致这种情况的原因就已经发生了。代理记录的队列时间是从请求进入dyno开始的时间，所以慢速是在此之前发生的。”

底线是，我们最终花了一个又一个小时在优化代码上，而这并不是真正的瓶颈。此外，为了提高我们的性能，我们不顾一切地使用了太高的dyno音阶，但我们真正从中得到的唯一一件事是从Heroku和Newrelic获得了更大的收入--这并不酷。我很高兴我们改变了。

当时甚至有一个bug导致newrelic pro在所有Dyno上被充电，尽管我们（根据NewAlics自己的建议）已经禁用了对后台工作进程的监控。花了很多时间，发了很多邮件，错误才被双方承认。

PPS.如果你不知道当前正在进行的讨论，那么这里是http://rapgenius.com/james-somers-herokus-bugly-secret-lyrics的链接

编辑26/2 2013 Heroku刚刚在他们的时事通讯中宣布，Newrelic发布了一个更新，显然应该对Heroku的情况有所了解。

EDIT 8/4 2013 Heroku刚刚发布了一个关于这个主题的常见问题解答