Асинхронні представлення Django та ASGI у 2026: продуктивність і питання співбесіди

Асинхронні представлення Django дозволяють одному worker'у обробляти сотні одночасних I/O-залежних запитів, не виділяючи окремий thread під кожне з'єднання, але лише тоді, коли шлях виконання лишається асинхронним від самого представлення до кожного мережевого виклику. Відколи Django 3.1 запровадив представлення async def, а Django 4.1 додав асинхронний інтерфейс до ORM, фреймворк перетворився на повноцінну ASGI-платформу, проте більшість продакшн-розгортань і досі працюють під WSGI, залишаючи цю конкурентність невикористаною. Цей глибокий розбір пояснює, як асинхронні представлення поводяться під ASGI, які сервери запускати у 2026 році, які пастки ORM спричиняють SynchronousOnlyOperation і які питання співбесіди відрізняють інженерів, що реально випускали асинхронний Django, від тих, хто лише читав про нього.

Як асинхронні представлення Django працюють під ASGI

WSGI за своєю природою синхронний: кожен активний запит займає один потік або процес worker'а від початку до кінця, тож 50 повільних запитів потребують 50 worker'ів. ASGI замінює цю модель на event loop, який чергує багато запитів на одному worker'і, призупиняючи корутину щоразу, коли вона очікує (await) I/O, і відновлюючи її, щойно надходять дані. Офіційна документація Django щодо async описує два адаптери, які уможливлюють таке співіснування: під ASGI Django виконує представлення async def нативно в циклі та переносить синхронні представлення до пулу потоків через sync_to_async; під WSGI він обгортає асинхронні представлення в async_to_sync і виконує їх до завершення, відкидаючи будь-який виграш у конкурентності.

Практичний наслідок різкий: представлення async def, розгорнуте на WSGI-сервері, поводиться як повільніше синхронне представлення. Конкурентність з'являється лише на ASGI-сервері. Мінімальне асинхронне представлення, що викликає зовнішній API, виглядає майже так само, як його синхронний аналог, а вся різниця зосереджена в await.

# views.py
import httpx
from django.http import JsonResponse

async def dashboard(request):
    # Під ASGI ця корутина виконується в event loop, тож worker
    # вільний обслуговувати інші запити, поки httpx очікує мережевий цикл.
    async with httpx.AsyncClient(timeout=5.0) as client:
        response = await client.get("https://api.example.com/metrics")
    return JsonResponse(response.json())

Виграш тут не в тому, що окремий запит завершується швидше; він займає той самий реальний час. Виграш у тому, що worker не заблокований під час await, тож пропускна здатність під конкурентним навантаженням зростає, а кількість процесів лишається незмінною.

Та сама модель відкриває шаблони відповідей, незручні під WSGI. Починаючи з Django 4.2, StreamingHttpResponse приймає асинхронний генератор, тож представлення може віддавати частини (chunks) у міру того, як їх виробляє джерело вище за течією, що добре пасує до Server-Sent Events і пропускання потоків токенів LLM, де з'єднання лишається відкритим секундами. Постійні двонапрямні протоколи на кшталт WebSockets усе ще проходять через Django Channels, а не через звичайні HTTP-представлення, але обидва спираються на той самий фундамент ASGI, тож проєкт, що впроваджує асинхронні представлення, вже сплатив інфраструктурну ціну для майбутніх real-time функцій.

Вибір ASGI-сервера для Django у 2026

Django постачає об'єкт ASGI-застосунку у asgi.py, але сам він не запускається; event loop приводить у рух окремий ASGI-сервер. Специфікація ASGI визначає інтерфейс, який реалізує кожен із цих серверів, і саме тому вони взаємозамінні на рівні протоколу й відрізняються переважно продуктивністю та покриттям протоколів.

| Сервер | Реалізовано на | Найкраще пасує для | |--------|----------------|----------| | Uvicorn | Python (uvloop) | Загальний ASGI, HTTP/1.1, поширений варіант за замовчуванням | | Daphne | Python | Django Channels, WebSockets, HTTP/2 | | Granian | Rust | Найвища «сира» пропускна здатність, HTTP/1 і HTTP/2 | | Hypercorn | Python | HTTP/2 і HTTP/3 (QUIC) |

Для більшості розгортань 2026 року Uvicorn, запущений як клас worker'а Gunicorn, лишається надійним вибором: Gunicorn керує життєвим циклом процесів, перезапускає аварійні worker'и й обробляє сигнали, тоді як Uvicorn приводить у рух event loop усередині кожного з них. Одна деталь міграції збиває з пантелику під час оновлень: класи worker'ів Gunicorn переїхали з ядра Uvicorn до окремого пакета uvicorn-worker починаючи з Uvicorn 0.30, тож шлях імпорту змінився.

# Спершу встановити пакет worker'а: pip install uvicorn-worker
gunicorn myproject.asgi:application \
    --workers 4 \
    --worker-class uvicorn_worker.UvicornWorker \
    --bind 0.0.0.0:8000

Команди, що женуться за максимальною пропускною здатністю, дедалі частіше обирають Granian — сервер на Rust, який усуває накладні витрати на розбір HTTP на боці Python. Хоч який вибір, історія розгортання і є причиною того, що async з'являється у продакшні лише тоді, коли його свідомо налаштували; специфічне для ASGI налаштування віддзеркалює ту саму операційну обережність, розглянуту в модулі питань співбесіди щодо деплою Django.

Асинхронний ORM і пастка SynchronousOnlyOperation

Django 4.1 додав асинхронні методи запитів по всьому ORM: aget, acreate, asave, adelete, acount, aexists, aaggregate, а також ітерацію через async for. Вони надають зручну для async поверхню, але критичне застереження доживає до 2026 року: рівень бази даних під ними не є нативно асинхронним. Навіть із psycopg3 Django виконує запити в пулі потоків і надає їх через асинхронні обгортки, тож асинхронний ORM покращує ергономіку й уникає блокування циклу, але не забезпечує справжнього наскрізного асинхронного I/O з базою даних.

Найпоширеніший режим збою — виклик синхронного методу ORM напряму всередині асинхронного представлення. Django виявляє асинхронний контекст і відмовляється, викидаючи SynchronousOnlyOperation, щоб не дати блокувальному виклику заморозити event loop для всіх інших запитів, що поділяють цей worker.

Асинхронні представлення читаються чисто, щойно асинхронні методи запитів замінюють своїх синхронних двійників. Наведений нижче шаблон рахує рядки та стримить перші десять записів, жодного разу не залишаючи event loop.

# views.py
from django.http import JsonResponse
from .models import Article

async def latest_articles(request):
    # acount() та асинхронна ітерація — async-безпечні обгортки навколо ORM.
    count = await Article.objects.acount()
    titles = []
    async for article in Article.objects.order_by("-created_at")[:10]:
        titles.append(article.title)
    return JsonResponse({"count": count, "titles": titles})

Деякий код не має асинхронного відповідника: сторонній SDK, що пропонує лише синхронні виклики, або щільний ланцюжок обходів ORM, який не варто переписувати. Обгортання його у sync_to_async з бібліотеки asgiref переносить роботу до потоку й тримає цикл чутливим. Аргумент thread_sensitive=True — безпечне значення за замовчуванням, адже він спрямовує кожен обгорнутий виклик до одного спільного потоку-виконавця, зберігаючи стан з'єднання з базою даних і транзакції, що зламався б, якби виклики розсіялися по довільних потоках.

# views.py
from asgiref.sync import sync_to_async
from .services import build_report  # синхронна функція

async def report_view(request):
    # thread_sensitive=True тримає обгорнуті виклики на одному спільному потоці,
    # зберігаючи стан з'єднання та транзакції на межі переходу.
    report = await sync_to_async(build_report, thread_sensitive=True)(request.user.id)
    return JsonResponse(report)

Продуктивність async у Django: коли конкурентність перемагає

Продуктивність async у Django — це історія про перекриття I/O, а не про «сиру» швидкість. Найяскравіший виграш дає розпаралелювання незалежних мережевих викликів через asyncio.gather: три зовнішні запити по 200 мс кожен коштують приблизно 600 мс послідовно, але завершуються приблизно за 200 мс конкурентно, бо очікування (awaits) перекриваються на одному циклі.

# views.py
import asyncio
import httpx
from django.http import JsonResponse

async def aggregate(request):
    async with httpx.AsyncClient(timeout=5.0) as client:
        # Три незалежні виклики виконуються конкурентно, а не один за одним.
        weather, prices, news = await asyncio.gather(
            client.get("https://api.example.com/weather"),
            client.get("https://api.example.com/prices"),
            client.get("https://api.example.com/news"),
        )
    return JsonResponse({
        "weather": weather.json(),
        "prices": prices.json(),
        "news": news.json(),
    })

Зворотний випадок важливий не менше. Представлення, що виконує єдиний швидкий локальний запит, нічого не виграє від async і часто програє, бо кожен запит тепер сплачує планування event loop плюс стрибок у пул потоків до синхронного драйвера бази даних. Async також накладає тонший податок на кожній межі sync/async: змішування синхронного й асинхронного middleware змушує Django перемикатися між циклом і потоком на кожному переході, і запит, що перетинає цю лінію кілька разів за відповідь, накопичує реальну затримку. Якщо тримати стек middleware однорідно асинхронним або однорідно синхронним, ці перемикання зникають.

Рішення зводиться до форми навантаження, а не до вподобання сучасного синтаксису.

| Тип навантаження | Кращий варіант за замовчуванням | |----------|----------------| | Кілька повільних викликів до зовнішніх API на запит | Асинхронне представлення з asyncio.gather | | Довгий стримінг або Server-Sent Events | Асинхронне представлення з асинхронним генератором | | Єдиний швидкий запит до бази, легкий по CPU | Синхронне представлення, більше worker'ів Gunicorn | | CPU-залежний рендеринг чи обчислення | Синхронне представлення, винесення в чергу задач |

Для по-справжньому довготривалих задач асинхронні представлення — цілком хибний інструмент; тримати запит відкритим, щоб виконувати хвилини роботи, марнує з'єднання незалежно від моделі конкурентності. Така робота належить фоновому worker'у — компроміс, розглянутий у посібнику про асинхронні задачі Celery у Django.

Впровадження має спиратися на вимірювання, а не на інтуїцію. Чесний спосіб обґрунтувати async — навантажити конкретний ендпоінт інструментом на кшталт Locust чи k6 за реалістичної конкурентності, порівнюючи синхронну версію на N worker'ах з асинхронною версією на тому самому залізі. Ендпоінти, у яких домінує єдиний зовнішній виклик із високою затримкою, показують широкий розрив на користь async; ендпоінти, де домінують швидкі запити, часто показують async трохи позаду, щойно враховано стрибок у пул потоків. Профілювання запиту наперед також показує, чи є вузьким місцем взагалі I/O, адже async нічого не дає представленню, що повільне через неіндексовані запити — проблему, розглянуту в покроковому розборі про оптимізацію запитів Django ORM.

Питання співбесіди щодо async у Django на 2026

Співбесіда з асинхронного Django перевіряє, чи кандидат розуміє модель, чи лише впізнає ключові слова. Наведені нижче питання відображають те, що насправді запитують на сеньйорних співбесідах у 2026 році, і кожне супроводжується відповіддю, яку дає досвідчений інженер.

Що змінюється, коли асинхронне представлення виконується під WSGI замість ASGI? Під WSGI Django обгортає корутину в async_to_sync і виконує її до завершення в потоці запиту, тож вона поводиться як повільніше синхронне представлення без жодного виграшу в конкурентності. Лише ASGI-сервер, що запускає event loop, дозволяє worker'у обслуговувати інші запити під час await.

Чому Article.objects.get(pk=1) викидає SynchronousOnlyOperation усередині асинхронного представлення? Синхронний виклик ORM заблокував би event loop, зупинивши всі інші запити на цьому worker'і. Django виявляє асинхронний контекст і відмовляється. Виправлення — асинхронний метод await Article.objects.aget(pk=1) або sync_to_async для коду без асинхронного відповідника.

Чи справді асинхронний ORM Django неблокувальний? Ні. Асинхронні методи — це ергономічні обгортки; підлеглі запити все одно виконуються в пулі потоків, бо драйвери бази даних не інтегровані для нативного наскрізного асинхронного виконання. Виграш у тому, щоб тримати цикл вільним, а не в паралельному I/O з базою на рівні драйвера.

Коли слід обирати асинхронні представлення замість черги задач на кшталт Celery? Асинхронні представлення пасують для I/O-конкурентності в межах запиту, яка має завершитися до відповіді, наприклад агрегація кількох API. Робота, що переживає запит, потребує повторних спроб або триває хвилинами, належить Celery чи фоновим задачам Django, адже тримати відкритим HTTP-з'єднання заради неї марнує ресурси сервера.

Яка ціна змішування синхронного й асинхронного middleware? Кожен перехід між синхронним і асинхронним компонентом змушує Django стрибати між event loop і потоком через sync_to_async чи async_to_sync. Запит, що багаторазово перетинає цю межу, сплачує накопичувальні накладні витрати, тож однорідний стек middleware працює краще за перемежований.

Висновок

• Асинхронні представлення забезпечують конкурентність лише на ASGI-сервері; те саме представлення під WSGI виконується синхронно через async_to_sync.
• Розгортання Uvicorn варто виконувати через пакет uvicorn-worker під Gunicorn або Granian для максимальної пропускної здатності, а налаштування ASGI слід сприймати як окремий крок деплою.
• Асинхронні представлення доречні, коли запит очікує на кілька повільних зовнішніх I/O-викликів; ендпоінти зі швидкими запитами й CPU-залежні варто тримати синхронними з більшою кількістю worker'ів.
• Усередині асинхронних представлень слід використовувати aget, acreate та async for, пам'ятаючи, що ORM усе ще виконує запити в пулі потоків, а не нативно асинхронно.
• SynchronousOnlyOperation варто сприймати як запобіжник: виправляти його асинхронними методами або sync_to_async(thread_sensitive=True), ніколи не вимикаючи перевірку.
• Стек middleware має лишатися однорідно синхронним або асинхронним, щоб не платити штраф за перемикання потоків на кожному перетині межі.