Декораторы¶

Следующие декораторы могут использоваться как с синхронными, так и с асинхронными функциями представления:

• cache_control()

• never_cache()

• no_append_slash()

• csrf_exempt()

• csrf_protect()

• ensure_csrf_cookie()

• requires_csrf_token()

• sensitivity_variables()

• sensitivity_post_parameters()

• gzip_page()

• condition()

• условная_страница()

• etag()

• last_modified()

• require_http_methods()

• require_GET()

• require_POST()

• require_safe()

• vary_on_cookie()

• vary_on_headers()

• xframe_options_deny()

• xframe_options_sameorigin()

• xframe_options_exempt()

Например:

from django.views.decorators.cache import never_cache


@never_cache
def my_sync_view(request): ...


@never_cache
async def my_async_view(request): ...

Запросы и ORM¶

За некоторыми исключениями, Django также может выполнять запросы ORM асинхронно:

async for author in Author.objects.filter(name__startswith="A"):
    book = await author.books.afirst()

Подробные примечания можно найти в Асинхронные запросы, но вкратце:

• Все методы QuerySet, вызывающие SQL-запрос, имеют асинхронный вариант с префиксом a.

• async for поддерживается во всех наборах запросов (включая выходные данные values() и values_list().)

Django также поддерживает некоторые методы асинхронной модели, использующие базу данных:

async def make_book(*args, **kwargs):
    book = Book(...)
    await book.asave(using="secondary")


async def make_book_with_tags(tags, *args, **kwargs):
    book = await Book.objects.acreate(...)
    await book.tags.aset(tags)

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

Производительность¶

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

Это также верно и для промежуточного программного обеспечения. Django попытается минимизировать количество переключений контекста между синхронизацией и асинхронностью. Если у вас есть сервер ASGI, но все ваше промежуточное программное обеспечение и представления синхронны, он переключится только один раз, прежде чем войти в стек промежуточного программного обеспечения.

Однако если вы установите синхронное промежуточное программное обеспечение между сервером ASGI и асинхронным представлением, ему придется переключиться в режим синхронизации для промежуточного программного обеспечения, а затем вернуться в асинхронный режим для представления. Django также будет держать поток синхронизации открытым для распространения исключений промежуточного программного обеспечения. Поначалу это может быть незаметно, но добавление штрафа в один поток на запрос может лишить асинхронного преимущества производительности.

Вам следует провести собственное тестирование производительности, чтобы увидеть, какой эффект ASGI по сравнению с WSGI оказывает на ваш код. В некоторых случаях производительность может быть увеличена даже для чисто синхронной базы кода в рамках ASGI, поскольку весь код обработки запросов по-прежнему выполняется асинхронно. Обычно вам нужно включать режим ASGI только в том случае, если в вашем проекте есть асинхронный код.

Обработка отключений¶

Для долгоживущих запросов клиент может отключиться до того, как представление вернет ответ. В этом случае в представлении будет выдано сообщение asyncio.CancelledError. Вы можете поймать эту ошибку и обработать ее, если вам нужно выполнить какую-либо очистку:

async def my_view(request):
    try:
        # Do some work
        ...
    except asyncio.CancelledError:
        # Handle disconnect
        raise

Вы также можете обрабатывать отключения клиентов в потоковых ответах.

async_to_sync()¶

async_to_sync(async_function, force_new_loop=False)¶

Принимает асинхронную функцию и возвращает функцию синхронизации, которая ее оборачивает. Может использоваться как прямая оболочка или декоратор:

from asgiref.sync import async_to_sync


async def get_data(): ...


sync_get_data = async_to_sync(get_data)


@async_to_sync
async def get_other_data(): ...

Функция async запускается в цикле событий для текущего потока, если он присутствует. Если текущего цикла событий нет, новый цикл событий запускается специально для одного асинхронного вызова и снова закрывается после завершения. В любой ситуации асинхронная функция будет выполняться в потоке, отличном от вызывающего кода.

Значения Threadlocals и contextvars сохраняются через границу в обоих направлениях.

async_to_sync() по сути является более мощной версией функции asyncio.run() в стандартной библиотеке Python. Помимо обеспечения работы threadlocals, он также включает режим thread_sensitivity для sync_to_async(), когда эта оболочка используется под ним.

sync_to_async()¶

sync_to_async(sync_function, thread_sensitive=True)¶

Принимает функцию синхронизации и возвращает асинхронную функцию, которая ее оборачивает. Может использоваться как прямая оболочка или декоратор:

from asgiref.sync import sync_to_async

async_function = sync_to_async(sync_function, thread_sensitive=False)
async_function = sync_to_async(sensitive_sync_function, thread_sensitive=True)


@sync_to_async
def sync_function(): ...

Значения Threadlocals и contextvars сохраняются через границу в обоих направлениях.

Функции синхронизации обычно пишутся с предположением, что все они выполняются в основном потоке, поэтому sync_to_async() имеет два режима работы с потоками:

• thread_sensitivity=True (по умолчанию): функция синхронизации будет выполняться в том же потоке, что и все другие thread_sensitivity функции. Это будет основной поток, если основной поток синхронный и вы используете оболочку async_to_sync().

• thread_sensitivity=False: функция синхронизации будет выполняться в совершенно новом потоке, который затем закрывается после завершения вызова.

Поточно-зависимый режим является совершенно особенным и выполняет большую работу по запуску всех функций в одном потоке. Однако обратите внимание, что он полагается на использование async_to_sync() над ним в стеке для правильного выполнения операций в основном потоке. Если вы используете asyncio.run() или аналогичный, он вернется к выполнению потокозависимых функций в одном общем потоке, но это не будет основной поток.

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

Вместо того, чтобы создавать потенциальные проблемы совместимости с этим кодом, мы решили добавить этот режим, чтобы весь существующий код синхронизации Django выполнялся в одном потоке и, таким образом, был полностью совместим с асинхронным режимом. Обратите внимание, что код синхронизации всегда будет находиться в различном потоке по сравнению с любым асинхронным кодом, который его вызывает, поэтому вам следует избегать передачи необработанных дескрипторов базы данных или других чувствительных к потоку ссылок.

На практике это ограничение означает, что вы не должны передавать функции объекта соединения базы данных при вызове sync_to_async(). Это приведет к запуску проверок безопасности потоков:

# DJANGO_SETTINGS_MODULE=settings.py python -m asyncio
>>> import asyncio
>>> from asgiref.sync import sync_to_async
>>> from django.db import connection
>>> # In an async context so you cannot use the database directly:
>>> connection.cursor()
django.core.exceptions.SynchronousOnlyOperation: You cannot call this from
an async context - use a thread or sync_to_async.
>>> # Nor can you pass resolved connection attributes across threads:
>>> await sync_to_async(connection.cursor)()
django.db.utils.DatabaseError: DatabaseWrapper objects created in a thread
can only be used in that same thread. The object with alias 'default' was
created in thread id 4371465600 and this is thread id 6131478528.

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