Назад | Перейти на главную страницу

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

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

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

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

Мои вопросы:

Любые советы приветствуются, спасибо.

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

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

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

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

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

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

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

Я написал скелет учебника / проекта, Cherrypy-webapp-скелет, целью которого было заполнить пробелы в развертывании (традиционного) реального приложения 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, геолокация и многие другие функции, которые просто раздувают сервер приложений без всякой пользы.

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