Выбор сервера приложений для API-интерфейса
С таким большим выбором серверов приложений (Passenger, Thin, Unicorn, Mongrel, Puma и Rainbows!) Мне интересно, что подойдет для следующего сценария:
Rails используется исключительно для API-интерфейса (все ресурсы обслуживаются Nginx). Некоторые вызовы API основаны на других службах API, поэтому иногда их завершение занимает некоторое время.
Отзывчивое приложение используется с мобильными, планшетными и настольными клиентами, поэтому нет никаких гарантий относительно подключения клиента.
Какой сервер приложений вы считаете подходящим в этом случае? Какие вещи следует учитывать при выборе?
3 ответа
Если ваше приложение выполняет вызовы API для других служб, тогда Unicorn - плохой выбор. Unicorn - это однопоточный многопроцессорный сервер приложений, специально разработанный для быстрых и кратковременных рабочих нагрузок, связанных с процессором. Выполнение вызовов HTTP API считается длительными блокирующими запросами ввода-вывода. Это не ограничение, а явный выбор дизайна Unicorn. Это подтверждается сайтом Unicorn, раздел "Просто хуже в некоторых случаях".
Теоретически, Thin может справляться с такими рабочими нагрузками с высоким параллелизмом, потому что использует четный ввод-вывод. Однако для этого требуется явная структура и поддержка приложений в виде четного кода. Немногие фреймворки и приложения делают это. Рельсы и Синатры нет.
Таким образом, это оставляет только серверы приложений с поддержкой многопоточности. Три претендента - это Puma, Rainbows и https://www.phusionpassenger.com/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 имеет много преимуществ по сравнению с более широкими возможностями, чем Puma и Rainbows: например, он имеет внешнюю сборку мусора, может динамически регулировать количество процессов в зависимости от трафика, полностью автоматизирует повторяющиеся перезапуски, поэтому вам не нужны сценарии и т. Д.,
Вы также можете быть заинтересованы в этой статье для получения дополнительной информации.
Единственный верный способ узнать - это тестировать и измерять характеристики в реальных условиях. Все остальное будет предположениями и догадками.
В то же время, вы должны начать с одного, который, как вы знаете, достаточно хорош (единорог кажется довольно популярным и достойным выбором), и иметь дело с производительностью сервера, когда он становится узким местом.
Исходя из вашего отдельного требования, я бы порекомендовал сервер Puma или Unicorn за обратным прокси-сервером nginx. Используйте sidekiq для рабочих очередей. Это предполагает, что приложение Rails, если используется Sinatra, thin может быть достаточно для вас. Как сказал другой человек, сначала пишите для стабильности, а не для тестирования производительности.