Информация и предпосылки:
У меня есть проект, который по своей сути является базовым приложением CRUD. У него нет длительных фоновых процессов, которые он разветвляет вначале и с которыми разговаривает позже, а также у него нет длительных запросов или требований к постоянному подключению. Он получает запрос, делает несколько запросов к базе данных и затем отвечает.
Чтобы быстро обрабатывать статические файлы и файлы с кэшированием, я собираюсь использовать Varnish во всех случаях.
Вот мой вопрос:
Прочитав о различных серверах веб-приложений Python, я увидел, что все они имеют своих «поклонников» по определенным, обычно «личным» причинам, что меня запутало, поскольку каждый вариант использования отличается от следующего.
Как я могу узнать об основных отличительных факторах веб-серверов Python (чтобы) решить, насколько они подходят для моего проекта и будет ли один лучше другого?
Каковы ваши (технически обоснованные) мысли по этому поводу?
Как мне выбрать веб-сервер Python?
Спасибо.
Часть бизнеса - стать «поклонником» любой конфигурации сервера, которая вам подходит.
Для простого приложения это не имеет значения, но вы обнаружите, что развертывание и обслуживание лучше для того или иного сервера. Возможно, в вашем дистрибутиве Linux есть лучшие пакеты для apache. Может лучше для nginx. Возможно, вы не можете заставить конфигурацию работать для apache. Возможно, у вас не получится заставить его работать на nginx.
Если вы ищете простой ответ «Этот сервер превосходный», этого просто не произойдет. Все они могут быть настроены на работу очень хорошо или очень плохо, и любой, кто работал в отрасли, видел и то и другое и сформировал твердое мнение.
При этом я предпочитаю Apache. Nginx очень многообещающий, поэтому переходить на него - неплохое решение, но Apache по-прежнему является золотым стандартом.
Лучшее, что вы можете сделать, - это убедиться, что ваше веб-приложение Python соответствует спецификации WSGI (PEP 333/3333). Не создавайте свое приложение так, чтобы оно зависело от определенных функций конкретных веб-серверов Python, которые не подпадают под спецификацию WSGI. Таким образом вы убедитесь, что веб-сервер не является важным компонентом, и вы не будете навсегда привязаны к одному конкретному веб-серверу. Это даст вам гибкость для переноса всего веб-приложения или его частей на другой сервер WSGI, если ваши требования к веб-серверу изменятся.
Также убедитесь, что ваше веб-приложение может работать в средах многопоточного и многопроцессорного развертывания, и убедитесь, что вы каким-то образом не ставите свой код в зависимость от использования сопрограмм для параллелизма при обработке параллельных запросов. Это снова необходимо для обеспечения гибкости при перемещении между серверами WSGI по мере необходимости.
Наконец, не придерживайтесь позиции, что вы должны использовать одну и ту же технологию для всего веб-приложения. Просто потому, что один URL-адрес вашего приложения должен обрабатывать длинные запросы стиля опроса, не думайте, что вам нужно повторно реализовать все ваше веб-приложение как асинхронное приложение. Вместо этого рассмотрите возможность вертикального разделения веб-приложения и перемещения только определенных подмножеств URL-адресов, которые имеют особые требования, такие как асинхронность, на отдельный сервер, и используйте гораздо более простой в использовании WSGI для основной части веб-приложения. Чтобы объединить все различные компоненты веб-приложения на одном хосте, используйте внешний интерфейс nginx для прокси-сервера к различным серверным модулям, асинхронным, WSGI и т. Д.
Другими словами, всегда оставляйте свои возможности открытыми и не ограничивайте себя, покупая определенную нестандартную технологию. Постарайтесь как можно больше придерживаться WSGI, поскольку это даст вам максимальную гибкость в выборе серверов WSGI и хостинга PaaS.