Убить поток puma после обработки запроса rails

С помощью puma можно изменить количество потоков для обработки нескольких запросов одновременно. Но в случае с Heroku количество подключений к базе данных к postgres ограничено.

Чтобы обрабатывать больше запросов, мы можем увеличить количество динамометров, где каждый динамометр имеет, скажем, по умолчанию 0:16 потоков. В этом случае под нагрузкой каждый дино может сделать 16 подключений к базе данных.

С помощью rails ActiveRecord мы можем ограничить количество подключений к базе данных на рабочий процесс rails, используя эту конфигурацию:

Rails.application.config.after_initialize do
  ActiveRecord::Base.connection_pool.disconnect!

  ActiveSupport.on_load(:active_record) do
    config = ActiveRecord::Base.configurations[Rails.env]
    config['reaping_frequency'] = ENV['DB_REAP_FREQ'] || 10 # seconds
    config['pool']              = ENV['DB_POOL']      || ENV['MAX_THREADS'] || 5
    ActiveRecord::Base.establish_connection(config)
  end
end

Однако с ограничением соединения db, если количество dynos увеличится, ограничение соединения будет достигнуто.

Есть ли способ убить поток и закрыть соединение с базой данных, как только запрос будет обслужен?

Я пытался использовать pgbouncer как buildpack, но есть проблемы с подготовленными операторами.

Сейчас я на rails 4.0.0, использую puma 2.7.1.

Есть ли какой-то хук событий в puma, который мы можем настроить таким образом, когда запрос будет завершен?

on_worker_boot do
  ActiveSupport.on_load(:active_record) do
    ActiveRecord::Base.establish_connection
  end
end

person Praveenram Balachandar    schedule 05.04.2014    source источник


Ответы (1)


Попробуйте использовать кластерный режим пумы, если вы используете МРТ. Я предлагаю настроить 4 рабочих.

puma -w 4

Если вы используете Jruby, вам нужно указать около 20 потоков. Но оно не должно превышать количество разрешенных подключений к БД.

puma -t 20:20

Больше информации:

https://devcenter.heroku.com/articles/deploying-rails-applications-with-the-puma-web-server#thread-safety

https://devcenter.heroku.com/articles/concurrency-and-database-connections#maximum-database-connections

person Michael Nikitochkin    schedule 15.10.2014