我是否正确地在Heroku + Unicorn中预载应用程序？
在Heroku上使用独角兽时。 扩大规模将会产生问题，因为新的缩放网络动态码可以通过请求访问，当它仍在加载应用程序时。 这主要导致Timeout错误。
我在http://codelevy.com/2010/02/09/getting-started-with-unicorn.html和https://github.com/blog/517-unicorn上阅读了一些内容
这两篇文章建议使用preload_app true 。 还有一个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
预计你在这里看到的是什么。 当你通过测功机扩大规模时，Heroku平台会将这个slu deploy部署到一个新的测功机上，这个测功机完全与其他的dynos（即另一个独角兽的主人）隔离。
一旦dyno被部署并运行（有效启动），路由网格将开始向该dyno发送请求，这就是Rails将在Unicorn上启动的时间，或者任何你已经安装的服务器。
但是，一旦该请求到达，您将有30秒的时间窗口返回数据，或者请求将在路由网格上超时（错误H12）。
因此，总而言之，您的问题与分叉无关，这是您的应用程序无法在30秒内启动，因此早期超时。 担心分叉和PID文件不是您在Heroku平台上需要担心的问题。
只有部分答案，但我能够通过这个Unicorn配置减少这些令人讨厌的缩放超时：
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
preload_app true对我们的应用程序有帮助，所以如果您在部署/重新引导期间看到超时问题，请给它一个镜头。 评论说这没有帮助，我认为这不值得尝试，然后意识到这确实是我们需要的修复。
我们的情况是使用预引导的慢启动Rails应用程序。 在某些部署和重新启动时，我们会收到很多超时，直到该网站被我们的正常运行时间监控所认为的为止。
我们意识到，如果preload_app false ，Unicorn将首先绑定其端口，然后加载应用程序。 只要绑定端口，Heroku就开始发送流量。 但是这需要花费一段时间才能加载这个缓慢的应用程序，这样流量就会超时。
这很容易通过在dev中运行Unicorn来验证，尝试在启动Unicorn后立即访问站点，并检查是否在该端口上出现“没有服务器”类型错误（合意）或非常慢的请求（不合意）。
当我们改为将preload_app true设置preload_app true ，则需要更长的时间直到Unicorn绑定端口，但一旦它和Heroku发送流量，就可以做出响应。