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

在Heroku上使用独角兽时。扩大规模将会产生问题，因为新的缩放网络动态码可以通过请求访问，当它仍在加载应用程序时。这主要导致Timeout错误。我是否正确地在Heroku + Unicorn中预载应用程序？

我没有使用preload_app true在http://codelevy.com/2010/02/09/getting-started-with-unicorn.html和https://github.com/blog/517-unicorn

的两篇文章有点阅读建议。和after_fork和before_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

来源

2012-02-18 Christian Fazzini

你在这里看到的是预期的。当你通过测功机扩大规模时，Heroku平台会将这个slu deploy部署到一个新的测功机，这个测功机完全与其他的dynos（即另一个独角兽大师）隔离。

一旦dyno被部署并运行（有效启动），路由网格将开始向该dyno发送请求，这是Rails将在Unicorn上启动的服务器，或者其他设置的服务器。

然而，一旦请求到达时，你有30秒的窗口，返回数据或请求将在路由网（误差H12）超时。

因此，总结一下，你的问题不是做与派生，它的应用程序可以在30秒，因此早期的超时内启动。担心分叉和PID文件不是您在Heroku平台上需要担心的问题。

来源

2012-02-20 09:19:25

嗨尼尔。解决方案是预装应用程序，以防止请求进入，直到dyno（独角兽主机）完全加载应用程序。我关心的是我是否需要'before_fork'块中的代码？ – 2012-02-20 09:31:39

你的before_fork将无法实现。正如我之前所说的，问题在于Heroku路由网格将在您的Unicorn启动之前向您发送请求。预加载应用程序不会解决此问题。 – 2012-02-20 11:07:53

如果是这样的话。如何防止在Heroku上旋转/放大新的Web dynos时发生超时错误？ – 2012-02-20 14:08:18

只是部分的答案，但我能减少这种独角兽配置这些讨厌的比例超时：

worker_processes 3 # amount of unicorn workers to spin up 
timeout 30   # restarts workers that hang for 30 seconds 
preload_app true 

# hack: traps the TERM signal, preventing unicorn from receiving it and performing its quick shutdown. 
# My signal handler then sends QUIT signal back to itself to trigger the unicorn graceful shutdown 
# http://stackoverflow.com/a/9996949/235297 
before_fork do |_server, _worker| 
    Signal.trap 'TERM' do 
    puts 'intercepting TERM and sending myself QUIT instead' 
    Process.kill 'QUIT', Process.pid 
    end 
end 

# Fix PostgreSQL SSL error 
# http://stackoverflow.com/a/8513432/235297 
after_fork do |server, worker| 
    defined?(ActiveRecord::Base) and 
    ActiveRecord::Base.establish_connection 
end

还有，我用heroku labs:enable preboot（见https://devcenter.heroku.com/articles/labs-preboot/）。不幸的是，当扩展Web dynos时，我仍然看到一些超时。

这里是在HireFire支持论坛的讨论，我开始：http://hirefireapp.tenderapp.com/discussions/problems/205-scaling-up-and-down-too-quickly-provoking-503s

来源

2012-07-16 14:30:10

遵循相同的方法，并没有帮助。看来，即使预加载，独角兽开始“聆听”和分叉工作人员“准备就绪”之间有一段时间的延迟，对我来说，这是> 30秒，所以即使所有*和*预启动我都会得到H12错误。 – 2012-08-21 23:43:46

preload_app true有助于为我们的应用程序，所以不要给它一个镜头，如果你看到有部署/重新启动期间超时的问题。评论说这没有帮助，我认为这不值得尝试，然后意识到这确实是我们需要的修复。

我们的情况是使用preboot的缓慢启动的Rails应用程序。在某些部署和重新启动时，我们会收到很多超时，直到该网站被我们的正常运行时间监控所认为的为止。

我们感悟到与preload_app false，麒麟将首先结合它的端口，然后加载应用程序。只要绑定端口，Heroku就开始发送流量。但是这需要花费一段时间才能加载这个缓慢的应用程序，这样流量就会超时。

这很容易通过在dev中运行Unicorn来验证，尝试在启动Unicorn后立即访问站点，并检查是否在该端口上出现“没有服务器”类型错误（合意）或非常慢的请求希望的）。

如果我们改为设置preload_app true，那么直到Unicorn绑定端口需要更长的时间，但一旦它完成并且Heroku发送流量，就可以做出响应。

来源

2017-06-16 07:09:27

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

回答

相关问题