Rails 4 - 如何优化我的 Heroku 生产环境？答案

【问题标题】：Rails 4 - How do I optimize my Heroku production environment?Rails 4 - 如何优化我的 Heroku 生产环境？
【发布时间】：2015-04-09 13:34:25
【问题描述】：

如何提高我的 rails 应用程序性能并最大限度地使用分配的 heroku 资源？例如，一半的内存仍未使用。

我应该增加工作进程并减少超时限制吗？在网站流量小幅增加后，H12 和 H18 错误有所增加。

我应该什么时候购买 Heroku worker？它会减少 H18 和 H12 错误吗？

请分享您的见解以微调事物以提高性能并减少错误。

我最近开始学习 Rails。对不起，如果问题非常基本。

config/unicorn.rb

# config/unicorn.rb
worker_processes Integer(ENV["WEB_CONCURRENCY"] || 3)
timeout 65
preload_app true

before_fork do |server, worker|
  Signal.trap 'TERM' do
    puts 'Unicorn master intercepting TERM and sending myself QUIT instead'
    Process.kill 'QUIT', Process.pid
  end

  defined?(ActiveRecord::Base) and
    ActiveRecord::Base.connection.disconnect!
end

after_fork do |server, worker|
  Signal.trap 'TERM' do
    puts 'Unicorn worker intercepting TERM and doing nothing. Wait for master to send QUIT'
  end

  defined?(ActiveRecord::Base) and
    ActiveRecord::Base.establish_connection
end

宝石文件

source 'https://rubygems.org'
ruby   '2.1.4'
.
.
.
group :production do
  gem 'pg', '0.17.1'
  gem 'rails_12factor', '0.0.2'
  gem 'unicorn'
end

一些附加信息。

【问题讨论】：

您是否将 WEB_CONCURRENCY 设置为环境变量？
@DavidAldridge 看起来我还没有设置它。请检查更新的信息。
关于H18，请查看stackoverflow.com/questions/12704777/…。它们可能是由于不良客户端造成的，例如手机。

标签： ruby-on-rails ruby performance ruby-on-rails-4 heroku

【解决方案1】：

这个问题实际上不是基本的，这东西很棘手。我不完全清楚为什么您会因为流量的小增加而收到 H12（请求超时），尤其是 H18（请求中断）错误。尝试弄清楚发生了什么是值得的——对于 H12，查看日志（或使用新遗物设置日志记录），以了解处理单个请求需要多长时间。如果没有负载的单个请求花费的时间超过几秒钟（这已经有点长了），您可能需要努力找出原因并加快速度——通过修改您的实际应用程序代码来避免这些缓慢的反应。 H18对我来说更加神秘。

但是，如果单个请求的速度相当快，而您的问题确实只是没有足够的处理能力来处理您的流量（根据您告诉我们的内容，我不一定会假设）- 那么您可以做一些事情充分利用您可用的处理能力。或者你也可以肯定地增加测功机的数量。如果这真的是问题。

为了最大限度地利用你所拥有的资源，我会使用 puma 而不是 unicorn -- puma is currently the heroku-recommended app server for Rails。

puma，正如 heroku 文档所解释的，允许您运行多个 Rails 进程，以及让每个进程同时使用多个线程处理请求。尽管多线程请求处理要求您的应用程序是线程安全的——Rails 本身是线程安全的，但您的应用程序代码或您正在使用的 gem 可能不是。 Rails 中的线程安全基本上只是避免共享全局状态（类或模块变量；全局变量），除了在程序启动时设置的只读状态（或为多线程访问正确同步的全局状态）。

与其他一些答案相反，我很确定 Unicorn 根本不使用多线程，它只使用多个进程。 Puma 可以运行多个进程，每个进程也使用多个线程。

对于大多数在 I/O（通常是数据库）上花费大量时间等待的典型 Rails 应用程序，多线程请求处理绝对是在给定硬件限制内最大化吞吐量和最小化延迟的方法。即使使用 MRI ruby，它也是“全局解释器锁定”。为了获得更好的性能，请部署在没有 GIL 的 JRuby 或 rubinius 上。

无论哪种方式，这只是一个计算多少 puma 进程的问题，每个进程可以容纳多少个最大线程，而不会耗尽内存。 heroku 文档建议您通常可以在 1x dyno 中运行 2-4 个 puma 进程。您可能让每个线程配置的最大线程配置为 2 甚至 10 个线程。

heroku puma docs 非常好，应该可以让您大致了解这些注意事项。

但这一切都是假设，正如您的问题所做的那样，您对 heroku 的 H12 和 H18 错误的问题确实是您需要更多的处理能力来处理您的请求流量。我不确定那是真的，但它可能是。

【讨论】：

【解决方案2】：

默认的独角兽配置可能假设您在 1x dynos 上运行。

由于您使用的是 2x dyno（应该如此），因此您可以增加每个 dyno 的线程数。尝试将 WEB_CONCURRENCY 设置为 5 并检查内存使用情况。

您还应该使用像 NewRelic 这样的服务来分析您的应用程序，以查看哪些方法调用很慢。

默认情况下，添加 Heroku worker 不会提高应用程序的速度或消除错误。但是，如果您的应用程序中有缓慢的操作可以异步运行（生成响应不需要这些操作 - 例如，发送电子邮件），那么您可以使用 ActiveJob 将它们排队等待后台处理，您可以使用Heroku Worker 来执行工作。

【讨论】：