В чем разница между обработкой запросов в режиме Django 3 ASGI и режимом WSGI?

Question

Django 3 должен быть выпущен в ближайшее время, и он сможет работать в режиме ASGI. Режим ASGI, кажется, делает Django более эффективным при обработке запросов, чем в режиме WSGI (если я верю правильно, можно обрабатывать больше запросов за единицу времени). Как это достигается? Это похоже на то, что Django может обрабатывать одновременно несколько запросов, но большинство из них будет ожидать таких событий, как выборка данных из базы данных или другие операции ввода-вывода?

Answer 1

Основным отличием является синхронный и асинхронный характер. Синхронный код блокировался, хотя выполнялся в другом потоке или процессе и возвращал ответ. Не было триггерного подхода для выполнения чего-то еще.

Асинхронное программирование позволяло помещать фрагмент кода в цикл обработки событий. Делайте что-нибудь еще, пока он не выполнится, а после завершения сделайте что-нибудь с ним. Это неблокирующий подход, основанный на событиях.

Из документов

Что не так с WSGI?

Вы можете спросить: «Почему бы просто не обновить WSGI? «? Это задавалось много раз на протяжении многих лет, и проблема обычно заключается в том, что одноразовый интерфейс WSGI просто не подходит для более сложных веб-протоколов, таких как WebSocket.

Приложения WSGI представляют собой единый синхронный вызов. принимает запрос и возвращает ответ;это не учитывает долгоживущие соединения, как вы получаете с соединениями HTTP или WebSocket с длительным опросом.

Даже если мы сделали эту вызываемую асинхронную, у нее все еще есть только один путь для предоставления запроса, поэтомупротоколы, которые имеют несколько входящих событий (например, получение фреймов WebSocket), не могут инициировать это.

Как работает ASGI?

ASGI структурирован как один асинхронный вызов,Он принимает область действия, которая содержит сведения о входящем запросе, отправке, ожидании, которое позволяет отправлять события клиенту, и получении, ожидании, которое позволяет получать события от клиента.

Это позволяет не только нескольковходящие события и исходящие события для каждого приложения, но также допускает фоновую сопрограмму, чтобы приложение могло выполнять другие действия (например, прослушивание событий по внешнему триггеру, например, очереди Redis).