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

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

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

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

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

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

Заключение

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