рабочие пумы против отдельных экземпляров ec2

Question

Я пришел из стека Java / Tomcat и полностью новичок в стек RoR.Я пытаюсь понять некоторые концепции конфигурации пумы.Я прочитал это и это , но мне все еще неясно с терминологией рабочих.

Я понимаю, что рабочие приводят к тому, что ребенок запускает пуму.По сути, это позволяет вам достичь параллелизма при использовании многоядерного экземпляра.Но вы также можете сделать то же самое, запустив столько экземпляров одноядерного ec2?

Кроме того, будет ли когда-либо целесообразно задавать рабочие параметры> 0, если экземпляр не многоядерный.

Любая информация здесь очень поможет мне.Спасибо!

Answer 1

В контексте Puma рабочие и потоки используются для достижения параллелизма, так что Puma может обрабатывать запросы, не ожидая завершения предыдущих запросов.Хорошая конфигурация должна найти хороший баланс между количеством работников и потоков, и необходимо принять во внимание несколько аспектов развернутого приложения:

• Рабочие:

  • Имеет большие накладные расходы памяти, так как каждому разветвленному процессу нужна своя память (это уменьшается в Linux из-за (https://en.wikipedia.org/wiki/Copy-on-write), но все еще является фактором)
  • Разрешить параллелизм, когда несколько ядер работаютЭто в основном вызывает беспокойство, когда обработка запросов требует больших вычислительных ресурсов, чего следует избегать, если запрос требует выполнения некоторых сложных вычислений, рекомендуется перенести его в фоновое задание с помощью библиотеки, например (https://github.com/mperham/sidekiq)
  • Не может использоваться на JRuby, так как он не поддерживает разветвление

• Потоки

  • Настроенное количество потоков будет запущено длякаждый рабочий процесс - то есть, если у вас есть workers x и threads y, то вы получаете x * y потоков обработки запросов
  • Совместно используйте память, чтобы они занимали меньше места (хотя здесь есть и ошибки: (https://www.speedshop.co/2017/12/04/malloc-doubles-ruby-memory.html)
  • В MRI, которая является реализацией Ruby по умолчанию, потоки не позволяют выполнять код Ruby параллельно из-заGIL - это не должно вызывать беспокойства, поскольку GIL не блокируется во время ожидания ввода-вывода, на который тратится много времени выполнения - доступа к базе данных, связи с API и т. д.
  • Вкл.Потоки JRUBY могут достигать параллелизма.
  • Не может использоваться, если ваше приложение не является потокобезопасным.Rails сам по себе ориентирован на многопотоковое исполнение, но у вас нет никаких гарантий для любого стороннего кода, от которого зависит приложение, или самого кода приложения.Если приложение не является потокобезопасным, ответ здесь прост - не используйте потоки (то есть настройте минимальные и максимальные потоки на 1).Отсутствие безопасности потоков является ситуацией, когда конфигурация с несколькими рабочими имеет смысл даже для одного экземпляра ядра.
  • Для любого количества потоков необходимо убедиться, что в пуле соединений достаточно соединений с базой данных.Как правило, это означает, что в качестве размера пула соединений Rails задано количество потоков, запущенных в рабочем процессе.

Сравнение нескольких рабочих с развертыванием на нескольких экземплярах EC2 пропускает частькартинка: при использовании Puma с несколькими рабочими процессами есть главный процесс Puma, который прослушивает порт и направляет каждый запрос доступному рабочему процессу.Если у вас есть несколько экземпляров EC2, вам нужно каким-то образом позаботиться о балансировке нагрузки между ними - в случае AWS это может быть ELB или ALB.Развертывание на нескольких экземплярах и распределение нагрузки - это правильный способ развертывания любого серьезного веб-приложения любым способом, но это не должно помешать вам лучше использовать ресурсы экземпляров через рабочих и потоки.

Я бы предложил поэкспериментировать с конфигурацией рабочихи потоки и начиная с установки рабочих на число ядер и потоков на 10 - затем внесите коррективы, если у вас возникнут проблемы с использованием памяти или использованием ресурсов.