Я немного смущен этой архитектурой. В одном из проектов, над которыми я работаю, Unicorn был выбран как сервер Rails. И он стоит за веб-сервером Nginx. Насколько я понимаю, Unicorn - полностью функциональный веб-сервер, и мы не планируем размещать какие-либо другие приложения Rails на одном экземпляре сервера.
Итак, мой вопрос: каковы преимущества наличия дополнительного слоя в цепочке:
client -> nginx -> unicorn -> unicorn worker
Единорог не был предназначен для обработки "медленных клиентов". Подробнее об этом можно узнать в PHILOSOPHY файле справки:
Большинство тестов, которые мы видели, не говорят вам об этом, и единорог не заботится о медленных клиентах... но вы должны.
"Медленный клиент" может быть любым клиентом за пределами вашего центра обработки данных. Сетевой трафик в локальной сети всегда быстрее, чем трафик, который пересекает его. Законы физики не позволяют иначе.
В HTTP/1.1 были установлены постоянные соединения, которые сокращают время ожидания от установления соединения и медленного запуска TCP. Они также теряют ресурсы сервера, когда клиенты не работают.
Стойкие соединения означают, что один из рабочих процессов единорога (в зависимости от вашего приложения, он может быть очень голоден в памяти) потратит значительное количество времени на простоя, сохраняя соединение живым и ничего не делая. Будучи однопоточным и используя блокирующий ввод-вывод, рабочий не может обслуживать других клиентов, сохраняя соединение живым. Таким образом, единорог не реализует постоянные соединения.
Если ваши ответы на приложения больше, чем буфера сокета, или если вы обрабатываете большие запросы (закачки), рабочие процессы будут также узко распространены по скорости клиентского соединения. Вы не должны позволять единорогу обслуживать клиентов за пределами вашей локальной сети.