Зачем для uvicorn'а нужен gunicorn?
В питоне есть такая штука как GIL. Глобальная блокировка интерпретатора. Это фундаментальная особенность CPython-реализации питона. Эта особенность не позволяет одновременно работать более чем одному потоку. То есть в питоне можно запускать потоки, но одновременно работать 2 и больше потоков не будет. В каждый конкретный момент времени будет работать только 1 поток. А нам бы хотелось, чтобы одновременно могли обрабатываться несколько http-запросов. Потому что ядер на сервере много, а толку от них с питоновскими тредами=потоками мало.
Поээээтому, чтобы всё было чётенько и одновременно могли обрабатываться несколько http-запросов, а также были утилизированы=задействованы все процессорные ядра, вместо тредов запускают процессы. Процессы не имеют ограничений GIL, могут работать одновременно несколько процессов на многоядерных процессорах, а этого-то нам и надо.
Нооо возникает тогда задачка управления этими процессами. Запустили мы 8 процессов, пришли на них какие-то http-запросы, они легли на разные процессы, и в процессе обработки одного из этих запросов что-то пошло не так, какая-то необработанная ошибка и т.п. и процесс упал. Нужен механизм, который его переподнимет. Да и начальное создание процессов тоже задача, кто-то должен её делать. То есть нужен process manager, менеджер процессов.
Задача обработки http-запросов и задача управления процессами сервера (управления воркерами, которые делают work=работу в данном случае по обработке хттп запросов) — это разные задачи. Какие-то инструменты могут их в себе сочетать, а какие-то могут выполнять только одну из этих двух задач. Вот uvicorn не занимается управлением своими процессами, отдает это на откуп инструмента, который уже давно проверен и хорошо менеджерит процессы — gunicorn.
Вот собственно и всё!
#python #backend #IT
В питоне есть такая штука как GIL. Глобальная блокировка интерпретатора. Это фундаментальная особенность CPython-реализации питона. Эта особенность не позволяет одновременно работать более чем одному потоку. То есть в питоне можно запускать потоки, но одновременно работать 2 и больше потоков не будет. В каждый конкретный момент времени будет работать только 1 поток. А нам бы хотелось, чтобы одновременно могли обрабатываться несколько http-запросов. Потому что ядер на сервере много, а толку от них с питоновскими тредами=потоками мало.
Поээээтому, чтобы всё было чётенько и одновременно могли обрабатываться несколько http-запросов, а также были утилизированы=задействованы все процессорные ядра, вместо тредов запускают процессы. Процессы не имеют ограничений GIL, могут работать одновременно несколько процессов на многоядерных процессорах, а этого-то нам и надо.
Нооо возникает тогда задачка управления этими процессами. Запустили мы 8 процессов, пришли на них какие-то http-запросы, они легли на разные процессы, и в процессе обработки одного из этих запросов что-то пошло не так, какая-то необработанная ошибка и т.п. и процесс упал. Нужен механизм, который его переподнимет. Да и начальное создание процессов тоже задача, кто-то должен её делать. То есть нужен process manager, менеджер процессов.
Задача обработки http-запросов и задача управления процессами сервера (управления воркерами, которые делают work=работу в данном случае по обработке хттп запросов) — это разные задачи. Какие-то инструменты могут их в себе сочетать, а какие-то могут выполнять только одну из этих двух задач. Вот uvicorn не занимается управлением своими процессами, отдает это на откуп инструмента, который уже давно проверен и хорошо менеджерит процессы — gunicorn.
Вот собственно и всё!
#python #backend #IT