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

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

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

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

Мои вопросы:

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

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

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

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

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

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

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

1. Nginx - это асинхронный веб-сервер. Это означает, что он не выделяет поток или процесс для каждого соединения. Вместо этого он использует предпочитаемую библиотекой опроса сокетов ОС и, таким образом, способен обрабатывать сотни тысяч соединений. Почему вы, как разработчик приложения, должны заботиться? Потому что Nginx буферизует соединения и передает запрос вашему экземпляру CherryPy upstream только тогда, когда запрос полностью прочитан. То же самое для ответов. Таким образом, ваше приложение 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.

Я написал учебник / скелет проекта 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.