У меня есть приложение на Python, которое предоставляется через wsgi, и я собирался развернуть его по всему миру. Из него не обслуживаются статические ресурсы. Приложение будет развернуто на одном компьютере. Я собираюсь обслуживать приложение wsgi с помощью uwsgi и могу подумать о двух вариантах:
обслуживать через один экземпляр uwsgi на машине (выяснить и вертеться с большим количеством рабочих / процессов для использования, возможно, начать с 2 * # ядер)
Запустите несколько экземпляров uwsgi, каждый с одним рабочим, за nginx на одной машине.
Запустить один экземпляр uwsgi за nginx
Следует иметь в виду, что сервер уже находится за балансировщиком нагрузки.
Я бы подумал об эксперименте с №2 или №3, если бы у меня были статические ресурсы для обслуживания. Поскольку нет статических файлов, это кажется излишним.
В этом случае будет ли польза от запуска uwsgi за nginx? против одного сервера uswgi с соответствующим количеством рабочих?
Я мало что знаю о uWSGI, но я не могу представить себе ни одного варианта использования, где было бы разумно иметь несколько подобных экземпляров, работающих на одной и той же машине / vm, поскольку он, очевидно, предназначен для многопоточности. Это просто дополнительные накладные расходы. Итак, №2 на самом деле не вариант (если ваше приложение нужно часто перезапускать, исправьте свой код, а не используйте такую настройку).
# 3 сейчас звучит бесполезно, но это не так. nginx не требует больших накладных расходов, его производительность и объем памяти, вероятно, в этом случае незначительны по сравнению с приложением python. Это действительно влияет на задержку, но опять же, это не должно иметь значения для чего-либо, кроме игрового сервера RTS (и http в любом случае не предназначен для низкой задержки). Настоящая проблема - это дополнительная настройка и еще одна точка отказа. Однако у вашего приложения гораздо больше шансов выйти из строя, чем у хорошо протестированного, активно используемого веб-сервера, поэтому все в основном сводится к конфигурации.
Разобравшись с этим, вот некоторые вещи, которые следует учитывать.
Если вы уверены, что ваше приложение не будет масштабироваться быстрее, чем вы можете масштабировать код (или не собираетесь масштабироваться вообще), вам не нужны его дополнительные функции (ваше приложение не так стабильно, как вы думаете !) и вы уверены в возможности балансировки нагрузки хостеров, пропустите nginx. Если нет или вы не на 100% уверены, что это останется верным, используйте nginx. Это не так много накладных расходов, но может избавить вас от многих проблем.