Rails Unicorn - 启动请求和到达控制器之间的延迟答案

【问题标题】：Rails Unicorn - Delay between starting request and reaching controllerRails Unicorn - 启动请求和到达控制器之间的延迟
【发布时间】：2015-10-14 06:36:04
【问题描述】：

我使用 Unicorn 作为我的 Rails 应用程序的应用程序服务器，并试图弄清楚为什么有时在请求开始和到达我的控制器之间存在不平凡（> 5 秒）的延迟.

这是我的 production.log 打印出来的：

Started GET "/search/articles.json?q=mashable.com" for 138.7.7.33 at 2015-07-23 14:59:19 -0400**
  Parameters: {"q"=>"mashable.com"}

Searching articles for keyword: mashable.com, format: json, Time: 2015-07-23 14:59:26 -0400

注意在 STARTED GET: 和“搜索文章的关键字”之间有 7 秒的延迟，这是控制器方法所做的第一件事。

articles.json 被路由到我的控制器方法“articles”，它现在只是这样做：

def articles
        format = params[:format]
        keyword = params["q"]

        Rails.logger.info "Searching articles for keyword: #{keyword}, format: #{format}, Time: #{Time.now.to_s}"

end

这是我的路线.rb

MyApp::Application.routes.draw do
    match '/search/articles' => 'search#articles' 
    #more routes here, but articles is the first route
end

什么可能导致这种延迟？是因为独角兽工人很忙吗？是不是因为 Unicorn worker 占用了太多内存导致系统变慢？

注意：我不认为延迟是在建立任何数据库连接，但我可能是错的。代码不需要进行数据库调用，我的数据库的最大连接数是1000，通常最多有1-2个连接。

【问题讨论】：

可能有多种原因 - 您需要监控系统资源以及独角兽。如果什么都没有，添加一个新的代理可能是最快/最简单的选择
Puma、Passenger 等公司也会出现这种情况吗？
GET请求的最后一行是什么意思，即sais Completed 200 OK in 100ms (Views: 50.0ms | ActiveRecord: 50.0ms)
您是否尝试过使用不同的应用服务器来查看它是否只是独角兽？
这个应用程序在什么环境中运行，您可以分享尽可能多的细节？ Rails 环境是生产还是开发？是在云端吗？谁以及虚拟服务器的规格是什么？换句话说，环境是什么？此外，您为尝试监控或解决问题做了哪些工作？当延迟发生时，在此之前发生了什么？例如，您是否推送了新代码以便服务器对资产进行预处理？谢谢...

标签： ruby-on-rails ruby unicorn

【解决方案1】：

其实可能是 before_filter 回调引起的，你应该检查一下

【讨论】：

【解决方案2】：

如果是生产问题，则可能是客户端发送请求速度慢造成的。 New Relic 和 Monit 是不错的选择。您可以考虑向 Unicorn 工作人员发送信号以重新启动他们以更好地了解问题。

您也可以尝试在 Unicorn 配置中添加 preload_app true 以加快工作进程的启动时间。

【讨论】：

慢速客户端如何导致这个问题？
这里有一些很好的信息：smashcompany.com/technology/…

【解决方案3】：

三个想法：

使用 Puma 代替 Unicorn 可能会更好地为您服务
可能是您的系统内存不足，或者有足够的可用内存：安装 New Relic 以排除瓶颈所在
也可能是您拥有的 Unicorn 实例多于数据库允许的连接数，在这种情况下，实例必须等待其他人断开连接才能连接。这可能会以不规则的 5 秒延迟表现出来，而不是每次都发生。

【讨论】：

但是在“STARTED GET”和正在打印的第一条日志语句之间没有建立数据库连接。没有有意义的工作发生。
实际上 ActiveRecord（以及 Rails）会自动管理它，并且仅在第一个 SQL 查询时才建立数据库连接，这正是您似乎遇到问题的时候。更多信息在这里：devcenter.heroku.com/articles/…。因为您使用的是 Unicorn，所以您有许多实例正在运行，并且如果此 # 大于 DB 允许的连接数，则断开连接的进程将不得不等待其他人在提交其第一个 SQL 查询后断开连接。

【解决方案4】：

我认为这可能是因为内存不足，因此频繁的垃圾收集，从而冻结了整个系统。

【讨论】：

Unicorn 只使用了总内存的 15%，所以我怀疑是这样