Выбор сервера приложений для API бэкэндом

Question

С так много вариантов для сервера приложений (Passenger, Thin, Unicorn, Барбос, Puma и Rainbows!), Я задаюсь вопросом, что было бы целесообразно для следующего сценария:

Rails используется исключительно для бэкэнда API (все активы обслуживаются Nginx). Некоторые вызовы API опираются на другие сервисы API, поэтому иногда требуется некоторое время для завершения.

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

Какой сервер приложений по вашему мнению подходит именно в этом случае? Что нужно учитывать при выборе?

Answer 1

Если ваше приложение вызывает вызовы API другим службам, то Единорог является плохим выбором. Unicorn - это однопоточный многопроцессорный сервер приложений, явно предназначенный для быстрой и короткой работы с нагрузкой на процессор. Выполнение вызовов HTTP API подсчитывает как длительные блокирующие запросы ввода-вывода. Это не ограничение, но явный выбор дизайна Unicorn. Это подтверждается the Unicorn website, раздел «Хуже того, в некоторых случаях».

В теории Тонкий может обрабатывать такие высококонкурентные рабочие нагрузки, поскольку он использует события ввода-вывода. Однако для этого требуется явная поддержка фреймворков и приложений в виде кода события. Это делает несколько каркасов и приложений. Rails и Sinatra нет.

Таким образом, это оставляет только серверы приложений с поддержкой многопоточности. Три претендента - Puma, Rainbows и Phusion Passenger 4 Enterprise.

• Пума относительно новая. Rainbows немного старше, но автор не дает никаких гарантий относительно того, работает ли он хорошо. Phusion Passenger является зрелым, существует уже много лет и в настоящее время используется более чем 150000 веб-сайтов, включая такие крупные, как Pixar, New York Times, AirBnB и т. Д.
• Модели использования Puma и Rainbows похожи на модели Unicorn и Thin вы запускаете кучу процессов и подключаете их к Nginx через конфигурацию обратного прокси. С другой стороны, Phusion Passenger предназначен для непосредственного интегрирования в Nginx, поэтому для этого требуется гораздо меньшая конфигурация, управление процессами и другие административные издержки.
• Phusion Passenger 4 Enterprise не является строго многопоточным сервером, а гибридным многопроцессорным/многопоточным. Это означает, что он может запускать несколько процессов (для повышения стабильности и возможности использования нескольких процессорных ядер), каждый из которых имеет несколько потоков (для большого параллелизма ввода-вывода).
• Phusion Passenger 4 Enterprise приносит many advantages over имеет больше возможностей, чем Puma и Rainbows: например, он имеет внеполосную сборку мусора, может динамически корректировать количество процессов, основанных на трафике, полностью автоматизирует перезапуск перезагрузки, поэтому вам не нужны сценарии , и т.д.

Вы также можете быть заинтересованы в this writeup для получения дополнительной информации.

Answer 2

Единственный истинный способ знать - проверить и измерить показатели в реальных условиях. Все остальное будет предположениями и предположениями.

В то же время вы должны начать с того, кого знаете, чтобы быть достаточно хорошим (единорог, кажется, довольно популярный и достойный выбор), и иметь дело с производительностью сервера, как только он станет узким местом.

Answer 3

Основываясь на вашем автономном req, я бы рекомендовал сервер Puma или Unicorn за обратным прокси-сервером nginx. Используйте sidekiq для рабочих очередей. Это предполагает приложение Rails, если вы используете Sinatra, тонкий может быть достаточно хорош для ya. Как сказал другой человек, напишите о стабильности в первую очередь, чем результаты теста.