Развертывание приложений CherryPy: автономный, WSGI Server или NGinx?

Я намерен использовать один VPS для развертывания нескольких приложений CherryPy с низким трафиком в качестве подкаталогов; например: example.com/app1, example.com/app2, так далее.

После изучения развертывания WSGI похоже, что предпочтительным методом развертывания приложений является использование сервера WSGI (Gunicorn, uWSGI и т. Д.) И NGinx в настройке обратного прокси-сервера. Кажется излишним использование двух веб-серверов в тандеме - тем более, что мое приложение CherryPy само по себе является веб-сервером - но я не хочу отклонять эту идею, поскольку она появляется везде. Я, конечно, не эксперт, поэтому я хотел бы обсудить это.

Я вижу три варианта:

  • Разверните CherryPy самостоятельно.
  • Развернуть под Gunicorn или другой сервер WSGI.
  • Развертывание под сервером WSGI и обратный прокси-сервер для NGinx, который, похоже, является решением для всех.

Мои вопросы:

  • Какова основная причина, по которой я вижу эту модель повсюду? NGinx это так хорошо?
  • Для приложений с низким трафиком достаточно ли родного сервера CherryPy, или мне даже не попробовать?

Любой совет ценится, спасибо.

Источник

2 ответа

Почему люди ставят Nginx впереди?

  1. Nginx - это асинхронный веб-сервер. Это означает, что он не выделяет поток или процесс для каждого соединения. Вместо этого он использует предпочитаемую ОС библиотеку опроса сокетов и, таким образом, способен обрабатывать сотни тысяч соединений. Почему вы, как разработчик приложений, должны заботиться? Потому что Nginx буферизует соединения и передает запрос в ваш вышестоящий экземпляр CherryPy только тогда, когда запрос полностью прочитан. То же самое для ответов. Таким образом, ваше приложение CherryPy, являющееся многопоточным сервером, во многих отношениях позади Nginx, становится асинхронным. В частности, вы махаете рукой на медленную проблему клиента и медленные DOS-атаки Лорис.
  2. Nginx имеет ограничение скорости соединения из коробки. Скажем, я не хочу более 8 одновременных подключений с одного IP.
  3. CherryPy имеет проблемы с SSL. Nginx нет.
  4. Python может отправлять байты туда и обратно почти так же хорошо, как C. Python zlib это просто обертка вокруг библиотеки C. Но поскольку Nginx эффективно обрабатывает соединение, хорошей идеей будет освободить рабочие потоки CherryPy от предоставления статического контента в производстве и выделять его только для динамического контента.
  5. Мультиплексирование нескольких экземпляров CherryPy на одном порту, домене, пути и т. Д. Как правило, дополнительная гибкость другого уровня конфигурации.

Безопасно ли использовать CherryPy самостоятельно?

По словам одного из авторов оригинала, да. Большинство веб-актуальных вещей вы можете делать с CherryPy самостоятельно.

CherryPy имеет представление о приложении, и вы можете обслуживать несколько приложений с одним экземпляром CherryPy. CherryPy также может обслуживать другие приложения WSGI.

Развертывание CherryPy

В традиционном развертывании в стиле *nix вы пишете сценарий инициализации, демонизируете процесс, отбрасываете его привилегии, пишете его PID и т. Д. Это не имеет большого значения, если у вас есть пара экземпляров CherryPy. Когда у вас есть десятки, это становится утомительным, и имеет смысл передать управление процессами в Gunicorn или uWGSI и переключить ваши экземпляры CherryPy с HTTP на WSGI.

Я написал учебник / каркас проекта https://bitbucket.org/saaj/cherrypy-webapp-skeleton, целью которого было заполнить пробелы для развертывания (традиционного) реального приложения CherryPy в Debian для веб-разработчика.

Заворачивать

  1. Мало трафика, особых требований нет → CherryPy * 1 ⇐ HTTP ⇒ Client,
  2. Высокий трафик, особые требования → CherryPy * n ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client,
  3. Десятки отдельных экземпляров CherryPy на одном сервере, жаждущих излишнего решения каждого → CherryPy * n ⇐ WSGI ⇒ Gunicorn ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client,
Источник

Причина, по которой все ставят nginx (или другой сервер, такой как Apache) перед своими серверами приложений, заключается в том, что у каждого есть статический контент, такой как изображения, CSS и JavaScript, и странные требования, уникальные для их приложений.

Ваш сервер приложений (CherryPy, gunicorn и т. Д.) Оптимизирован для запуска приложения и его вывода. Хотя сервер приложений также может обслуживать статический контент, они почти никогда не оптимизируются для этой задачи, поскольку он вторичен по отношению к основной цели сервера приложений. (Некоторые серверы приложений также помогут, сократив и сжав ваши CSS и JS, чтобы передний веб-сервер мог обслуживать эти ресурсы еще быстрее.)

Кроме того, реальный веб-сервер может делать гораздо больше, чем просто обслуживающий контент. Такие вещи, как кеширование, манипулирование заголовками, перезапись URL-адресов, геолокация и многие другие функции, которые просто раздули бы сервер приложений до бесполезной цели.

Обычно сервер приложений запускается только при разработке приложения, когда вы являетесь единственным пользователем, и производительность не является проблемой. Даже если на вашем сайте мало трафика, вы бы хотели, чтобы он был быстрее, верно? Медленные сайты с низким трафиком обычно не превращаются в сайты с высоким трафиком...

Источник
Другие вопросы по тегам