Рабочие сервера приложений порождают потоки?

Question

Я знаю, что серверы приложений, используемые веб-приложениями Ruby, имеют концепцию рабочих процессов. Например, Unicorn имеет это на unicorn.rb файл конфигурации, а для монгрел это называется serversустанавливайте обычно на ваш mongrel_cluster.yml файл.

Мои два вопроса об этом:

1) делает каждый worker/server работает как веб-сервер и спамит процессами / потоками / волокном каждый раз, когда получает запрос, или блокирует новый запрос, если уже запущен другой?

2) Это отличается от сервера приложений на сервер приложений? (Как единорог, дворняга, худой, вебрик...)

Answer 1

Это отличается от сервера приложений к серверу приложений.

Mongrel (по крайней мере, несколько лет назад) имел бы несколько рабочих процессов, и вы использовали бы что-то вроде Apache для балансировки нагрузки между рабочими процессами; каждый будет слушать другой порт. И у каждого рабочего-монгрела была своя собственная очередь запросов, поэтому, если он был занят, когда apache передал ему новый запрос, новый запрос был бы помещен в очередь, пока этот работник не завершил свой запрос. Иногда мы видим проблемы, когда из-за очень длинного запроса (генерации отчета) другие запросы накапливаются за ним, даже если другие рабочие-монгрелы были гораздо менее заняты.

Unicorn имеет главный процесс и ему нужно только прослушивать один порт или сокет unix и использовать только одну очередь запросов. Этот главный процесс только назначает запросы рабочим процессам, когда они становятся доступными, поэтому проблема, с которой мы столкнулись с Mongrel, является гораздо меньшей проблемой. Если один работник занимает очень много времени, у него не будет особых запросов на резервное копирование, он просто не сможет помочь с главной очередью запросов до тех пор, пока не закончит свой отчет или какой-либо большой запрос.

Webrick даже не следует рассматривать, он спроектирован так, чтобы работать как один рабочий в процессе разработки и все время перезагружать.

Answer 2

С моей головы, так что не воспринимайте это как "правду"

Рубиновые (МРТ) серверы:

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

Насколько мне известно, webrick запускает только один процесс, поэтому запрос 2 будет заблокирован до завершения запроса 1.

тонкий: я полагаю, что он использует 'ввод-вывод событий' для обработки http, но все еще является одним сервером процессов

серверы jruby:

Тринидад, Крутящий момент многопоточные и работают на JVM

см. также puma: многопоточный для использования с jruby или rubinious

Answer 3

Я думаю, что GitHub лучше всего объясняет единорога в их (старом, но действительном) сообщении в блоге https://github.com/blog/517-unicorn.

Я думаю, что это помещает запросы в очередь в очередь.