我是否正确地在Heroku + Unicorn中预加载应用程序?

Chr*_*ini 7 ruby-on-rails heroku unicorn ruby-on-rails-3

在Heroku上使用Unicorn时.扩展,将会有问题,因为当它仍然加载应用程序时,请求可以访问新缩放的web dyno.这主要导致超时错误.

我在http://codelevy.com/2010/02/09/getting-started-with-unicorn.htmlhttps://github.com/blog/517-unicorn上做了一些阅读

这两篇文章建议使用preload_app true.和after_forkbefore_fork块.

在Rails 3+中,before_block仍然需要代码吗?我读到了某个地方,否则.任何经历过这种情况并且想要分享的人?

我错过了什么吗?我是否正确加载了应用程序?

# config/initializers/unicorn.rb
# Read from:
# http://michaelvanrooijen.com/articles/2011/06/01-more-concurrency-on-a-single-heroku-dyno-with-the-new-celadon-cedar-stack/
worker_processes 3 # amount of unicorn workers to spin up
timeout 30         # restarts workers that hang for 90 seconds

# Noted from http://codelevy.com/2010/02/09/getting-started-with-unicorn.html
# and https://github.com/blog/517-unicorn
preload_app true

after_fork do |server, worker|
  ActiveRecord::Base.establish_connection
end

before_fork do |server, worker|
  ##
  # When sent a USR2, Unicorn will suffix its pidfile with .oldbin and
  # immediately start loading up a new version of itself (loaded with a new
  # version of our app). When this new Unicorn is completely loaded
  # it will begin spawning workers. The first worker spawned will check to
  # see if an .oldbin pidfile exists. If so, this means we've just booted up
  # a new Unicorn and need to tell the old one that it can now die. To do so
  # we send it a QUIT.
  #
  # Using this method we get 0 downtime deploys.

  old_pid = Rails.root + '/tmp/pids/unicorn.pid.oldbin'
  if File.exists?(old_pid) && server.pid != old_pid
    begin
      Process.kill("QUIT", File.read(old_pid).to_i)
    rescue Errno::ENOENT, Errno::ESRCH
      # someone else did our job for us
    end
  end
end
Run Code Online (Sandbox Code Playgroud)

Nei*_*ton 2

您在这里看到的内容是预期的。当您通过 dyno 进行扩展时,Heroku 平台会将该 slug 部署到新的 dyno,该新的 dyno 与您的其他 dyno(即另一个独角兽大师)完全隔离。

一旦该 dyno 部署并运行(有效启动),路由网格将开始向该 dyno 发送请求,此时 Rails 将在 Unicorn 或您已设置的任何服务器上启动。

但是,一旦请求到达,您就有 30 秒的时间返回数据,否则请求将在路由网格上超时(错误 H12)。

因此,总而言之,您的问题与分叉无关,而是您的应用程序无法在 30 秒内启动,因此会提前超时。在 Heroku 平台上,您无需担心分叉和 PID 文件。

  • 这不是很有帮助。看来,当您使用 Thin 时,Heroku 会等到新的 dyno 服务器准备好后再向其发出请求。对于 Unicorn,它在 Unicorn 准备好之前发送请求,因此请求需要超过 30 秒,Heroku 无助地杀死它。必须有一种方法来解决独角兽的这个问题。 (6认同)