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