ruby-on-rails - Heroku上出现奇怪的TTFB(时间到第一个字节)

Question

我们正在改善Heroku托管的Rails应用程序(rails 3.2.8和ruby 1.9.3)的性能。在此过程中，我们遇到了一个令人担忧的问题，对于该问题而言，源极难追踪。让我快速解释一下我们如何遇到该问题以及如何设法解决该问题。

-

从6月左右开始，我们在整个站点的“第一个字节的时间”中都经历了奇怪的滞后行为。通过使用该网站，问题很明显(有时应用程序在10到20秒内没有响应)，并且通过webpagetest.org在瀑布分析中也存在该问题。
我们的总部设在丹麦，但可以从任何东道国获得此结果。

为了确认问题，我们进行了基准测试，将300个相同的请求发送到一个简单的页面，并测量了响应时间。
如果我们向首页发送300个请求，则响应时间的中位数低于1秒，这是相当不错的。令我们感到恐惧的是，60个请求所花的时间是该时间的两倍，而其中40个所花的时间超过4秒。某些请求最多需要16秒。

这些缓慢的请求都不会出现在我们用于性能监控的New Relic中。无论我们将Web流程扩展到多高，都不会显示请求队列，并且结果是相同的。
不过，我们不能拒绝该问题是由应用程序代码引起的，因此我们尝试了另一个实验，我们通过机架中间件响应了该请求。

通过将此中间件(TestMiddleware)放在机架堆栈的开头，我们在该请求未到达应用程序之前就返回了一个请求，以确保以下任何中间件或rails应用程序都不会引起延迟。

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

然后，我们运行相同的脚本来记录响应时间，并得到几乎相同的结果。中值响应时间约为130毫秒(明显更快，因为它没有打到应用程序。但是仍然有60个请求花费了400毫秒以上的时间，而25个请求花费了超过1秒钟的时间。同样，有些请求的速度慢至16秒。

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

通过在Heroku上托管的另一个Rails 3.2和ruby 1.9.3应用程序上运行响应脚本可以确认此结果-根本没有任何奇怪的行为。

DNS设置遵循Heroku的建议。

-

至少我们感到困惑。 Heroku的路由网络会不会有些麻烦？
为什么我们看到这种奇怪的行为呢？我们如何摆脱它？为什么我们看不到新遗物？

Answer 1

原来，这是一种请求排队。有时，该Web服务器很忙，并且由于heroku只是随机随机将传入的请求随机发送给任何dyno，因此我可能最终排在dyno后面的队列中，由于诸如此类的原因，dyno完全卡住了数据库问题。奇怪的是，这在新的遗物中几乎不可见(这是个好主意，在查看其图表中的稀薄时取消选中所有其他资源，然后队列突然出现)

，2013年2月2日编辑:事实证明，它在Newrelic中几乎不引起注意的原因是，它没有被测量! http://rapgenius.com/Lemon-money-trees-rap-genius-response-to-heroku-lyrics

我们发现这非常令人沮丧，最终我们离开了Heroku，转而使用专用服务器。这使我们的性能提高了20倍，而成本却只有其1/10。另外，我必须说，Heroku对我们感到失望，他在发生这种情况时否认了速度缓慢是由于他们的基础设施造成的，尽管我们怀疑并多次强调了它。我们甚至得到了这样的答案:

Heroku 28/8 2012: "If you're not seeing request queueing or other slowness reported in New Relic, then this is likely not a server-side issue. Heroku's internal routing should take <1ms. None of our monitoring systems are indicating any routing problems currently."

此外，我们与Newrelic进行了交谈，尽管他们认为自己与Heroku之间的工作关系非常紧密，但他们似乎也没有意识到这个问题。

Newrelic 29/8 2012: "It looks like whatever is causing this is happening before the Ruby agent's visibility starts. The queue time that the agent records is from the time the request enters a dyno, so the slow down is occurring before then."

最重要的是，我们最终花费了数小时来优化代码，但这并不是真正的瓶颈。另外，以过高的测功比例运行以绝望地尝试来提高性能，但是我们真正要从中获得的唯一一件事是Heroku和Newrelic的 yield 都更大-并非很酷。我很高兴我们改变了。

PS。当时，即使我们(根据Newrelics自己的建议)禁用了对后台工作人员进程的监视，甚至还有一个错误导致newrelic pro受到所有dyno的指控。双方承认错误后，花费了大量时间和大量电子邮件。

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

编辑26/2 2013
Heroku的通讯中只有 announced，Newrelic发布了 update，显然应该对Heroku的情况有所了解。

2013年8月4日编辑
Heroku刚刚针对该主题发布了 FAQ