У меня есть сайт Django, работающий на Gunicorn с обратным прокси через Nginx. Разве Nginx - это не лишние лишние накладные расходы? Как помогает добавление этого поверх Gunicorn?
Я собираюсь сосредоточиться на медленном поведении клиентов и на том, как ваша конфигурация справляется с этим, но не поддавайтесь соблазну полагать, что это единственное преимущество. Тот же метод, который приносит пользу медленным клиентам, также имеет преимущества для быстрых клиентов, обработки SSL, борьбы с скачками трафика и других аспектов обслуживания HTTP в Интернете.
Gunicorn - это программа для предварительного форка. Для связи с малой задержкой, такой как балансировщик нагрузки на сервер приложений или связь между службами, системы до форка могут быть очень успешными. Нет никаких затрат на развертывание процесса для обработки запроса, и один процесс может быть выделен для обработки одного запроса; Устранение этих вещей может привести к созданию более быстрой и эффективной системы до тех пор, пока количество одновременных подключений не превысит количество доступных процессов для их обработки.
В вашей ситуации вы имеете дело с клиентами с высокой задержкой через Интернет. Эти медленные клиенты могут связывать одни и те же процессы. Когда QPS имеет значение, код приложения должен получить, обработать и разрешить запрос как можно быстрее, чтобы он мог перейти к другому запросу. Когда медленные клиенты общаются напрямую с вашей системой, они связывают этот процесс и замедляют его. Вместо того, чтобы обрабатывать и удалять запрос как можно быстрее, этот процесс теперь также должен ждать медленного клиента. Снижается эффективный QPS.
Обработка большого количества соединений с очень небольшими затратами на процессор и память - вот что хорошо умеют асинхронные серверы, такие как Nginx. Медленные клиенты не влияют на них так же негативно, потому что они умеют обрабатывать большое количество клиентов одновременно. В случае Nginx, работающего на современном оборудовании, он может обрабатывать десятки тысяч соединений одновременно.
Nginx перед сервером предварительного форка - отличное сочетание. Nginx обрабатывает связь с клиентами и не несет штрафов за работу с медленными клиентами. Он отправляет запросы на серверную часть так быстро, как она может обрабатывать эти запросы, что позволяет бэкенду максимально эффективно использовать ресурсы сервера. Бэкэнд возвращает результат, как только вычисляет его, а Nginx буферизует этот ответ, чтобы скормить его медленным клиентам в их собственном темпе. Между тем, серверная часть может перейти к обработке другого запроса, даже если медленный клиент все еще получает результат.
@blueben прав. Конкретный и распространенный пример того, что может случиться, когда обратный прокси-сервер не используется, - это то, что серверная база данных может обрабатывать дескрипторы подключения к базе данных там, где нет прокси и есть всплеск трафика. Это связано с медленным выпуском соединений, как описано в @blueben.
Первым побуждением увидеть исчерпанные дескрипторы базы данных может быть поддержка большего количества подключений к базе данных. Но, добавив обратный прокси-сервер перед приложением, вы увидите, что количество необходимых подключений к базе данных для высокой нагрузки значительно снизится и стабилизируется - уровень подключения к базе данных не будет увеличиваться почти так же сильно, когда произойдет всплеск трафика.
Nginx также отлично подходит для обслуживания статического контента, кеширования и множества других HTTP-задач, позволяя вашему серверу приложений сосредоточиться на роли сервера приложений.
@naill Donegan упоминает об этом в комментарии выше, но это достаточно важно, чтобы получить ответ.
Nginx останавливает медленную атаку лори, с которой не справляется Gunicorn.