Как выбрать веб-сервер для приложения Python? [закрыто]
Информация и предварительные условия:
У меня есть проект, который по своей сути является базовым приложением CRUD. В нем нет длительных фоновых процессов, которые он разветвляет в начале и разговаривает с ним позже, у него нет длительных запросов или требований к постоянному подключению. Он получает запрос, делает некоторые запросы к базе данных и затем отвечает.
Чтобы быстро обслуживать статические и кэшируемые файлы, я буду использовать Varnish во всех случаях.
Вот мой вопрос:
Прочитав о различных серверах веб-приложений Python, я заметил, что все они имеют своих «поклонников» по определенным, обычно «личным» причинам, что меня запутало, поскольку каждый вариант использования отличается от следующий.
Как я могу узнать об основных отличительных факторах веб-серверов Python (чтобы) решить, насколько они подходят для моего проекта и будет ли один лучше другого?
Каковы ваши (технически обоснованные) мысли по делу?
Как мне выбрать веб-сервер Python?
Спасибо.
Часть бизнеса становится «поклонником» любой конфигурации сервера, которая вам подходит.
Для простого приложения это не имеет значения, но вы обнаружите, что развертывание и обслуживание лучше для того или иного сервера. Возможно, в вашем дистрибутиве Linux есть лучшие пакеты для apache. Может лучше для nginx. Возможно, вы не можете заставить конфигурацию работать для apache. Возможно, вам не удастся заставить его работать для nginx.
Если вы ищете простой ответ «Этот сервер является превосходным», этого просто не произойдет. Все они могут быть настроены для работы очень хорошо или очень плохо, и любой, кто работал в отрасли, видел и то, и другое и сформировал твердое мнение.
При этом я склонен придерживаться Apache. Nginx очень многообещающий, так что прыгнуть на него - неплохое решение,
The best thing you can do is ensure you target your Python web application to the WSGI specification (PEP 333/3333). Do not build your application to be dependent on specific features of particular Python web servers which fall outside of the WSGI specification. By doing this you will ensure that the web server isn't a critical component and you will not forever be bound to one specific web server. This will give you the flexibility to migrate your whole web application or parts of it to a different WSGI server if your requirements of the web server change.
Also ensure that your web application can work in multithreaded and multiprocess deployment environments and ensure that you don't somehow make your code dependent on the use of coroutines for concurrency in handling parallel requests. This is again to ensure you have the flexibility to move between WSGI servers as necessary.
Finally, don't take the stance that you must use the same technology for your whole web application. Just because one URL of your application needs to handling long polling style requests don't think that you need to reimplement your whole web application as an async application. Consider instead vertically partitioning your web application and move just specific subsets of URLs that have special requirements such as async to a separate server and use the much easier to use WSGI for the bulk of the web application. To bring all the different components of the web application under the one host, use a nginx front end to proxy to the different backends, async and WSGI etc.
In other words, always keep your options open and don't restrict yourself by buying into a specific non standard technology. Try and stick with WSGI as much as possible as it will give you most flexibility as far as WSGI server choices and PaaS hosting.