비동기 지원¶

Decorators¶

The following decorators can be used with both synchronous and asynchronous view functions:

• cache_control()

• never_cache()

• no_append_slash()

• csrf_exempt()

• csrf_protect()

• ensure_csrf_cookie()

• requires_csrf_token()

• sensitive_variables()

• sensitive_post_parameters()

• gzip_page()

• condition()

• conditional_page()

• 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¶

몇가지 예외를 제외하고 장고는 ORM 쿼리를 비동기식으로도 실행할 수 있다.

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

자세한 내용은 :ref:`async-queries`에서 확인 가능하다. 요약하면:

• SQL 쿼리를 발생시키는 ``QuerySet``의 모든 메서드는 접두사 ``a``가 붙은 비동기 메서드가 있다.

• 모든 QuerySets(``values()``와 ``values_list()``의 결과 값 포함)에서 ``async for``가 지원된다.

장고는 데이터베이스에 접근하는 모델 메서드 일부에 대해서도 비동기 호출을 지원한다:

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)

아직 트랜잭션 처리는 비동기로 동작하지 않는다. 코드 중 트랙젝션으로 처리가 필요한 부분에 대해서는 별도 동기 함수로 작성한 다음 :func:`sync_to_async`를 사용해 호출하자.

Persistent database connections, set via the CONN_MAX_AGE setting, should also be disabled in async mode. Instead, use your database backend’s built-in connection pooling if available, or investigate a third-party connection pooling option if required.

성능¶

뷰가(예를 들어, WSGI에서의 비동기식 뷰, ASGI에서의 전통적 동기식 뷰) 맞지 않은 모드를 실행할 때, django는 코드가 실행되도록 하기 위해서 다른 호출 방식을 모방해야한다. 컨텍스트 스위치는 1 밀리초 전후의 작은 성능 상의 패널티를 유발한다.

이는 미들웨어에서도 TRUE이다. django는 동기식과 비동기식 사이의 컨텍스트 스위칭 횟수를 최소화하도록 시도하다. 만약 ASGI 서버에서 모든 미들웨어와 뷰는 동기식이나, 스택에 미들웨어를 넣기 전에, 스위치는 한 번만 발생할 것이다.

그러나, 동기식 미들웨어를 ASGI 서버와 비동기식 뷰 사이에 넣는다면, 미들웨어의 동기식 모드를 스위치할 것이고 뷰의 비동기식 모드로 돌아갈 것이다. django는 미들웨어 예외 전파를 막기 위해 동기식 스레드를 열린 상태로 유지할 것이다. 처음에는 인지되지 않을 것이나, 요청마다의 한 스레드의 패널티를 더하면 비동기식 성능의 이점을 제거한다.

ASGI와 WSGI 코드에 어떤 영향을 끼치는지 자체 성능 테스팅을 해야한다. 일부 케이스에서는 요청 핸들링 코드는 여전히 비동기식으로 실행되고 있기 때문에 심지어 순전히 ASGI 서버에서의 동기식 코드베이스이나 성능이 향상될 수 있다. 일반적인 경우, 비동기식 코드가 프로젝트에 있는 경우에만 ASGI 모드를 쓸 수 있게 하다.

Handling disconnects¶

For long-lived requests, a client may disconnect before the view returns a response. In this case, an asyncio.CancelledError will be raised in the view. You can catch this error and handle it if you need to perform any cleanup:

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

You can also handle client disconnects in streaming responses.

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(): ...

이벤트 루프가 존재한다면, 비동기식 함수는 현재의 스레드에 대한 이벤트 루프에서 실행된다. 현재의 이벤트 루프가 없다면, 새로운 이벤트 루프가 단일 비동기식 호출에 대해서만 스핀업 하고, 완료하면 다시 종료된다. 두 상황 모두, 비동기식 함수는 호출 코드에 대한 다른 스레드에서 실행될 것이다.

Threadlocals와 contextvars 값은 양 방향의 경계를 넘어 유지된다.

async_to_sync() 는 파이썬의 표준 라이브러리에 있는 함수 asyncio.run`의 본질적으로 더 강한 버전이다. threadlocal 수행이 되는 것 뿐만 아니라,  또한 그 아래에 래퍼가 쓰일 때 :func:`sync_to_async`의 ``thread_sensitive`() 모드를 쓸 수 있게 하다.

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 값은 양 방향의 경계를 넘어 유지된다.

동기식 함수는 메인 스레드에서 모두 실행된다고 가정하여 쓰이는 경향이 있어서, :func:`sync_to_async`는 두 개의 스레딩 모드를 가진다.

• thread_sensitive=True (디폴트): 동기식 함수는 다른 모든``thread_sensitive`` 함수처럼 같은 스레드에서 실행할 것이다. 만일, 메인 스레드가 동기식이고 async_to_sync() 래퍼를 이용하면, 이것이 메인 스레드일 것이다.

• thread_sensitive=False: 동기식 함수는 호출이 한 번 완료하면 종료되는 완전 새로운 스레드에서 실행될 것이다.

Thread-sensitive 모드는 특별하고, 같은 스레드의 모든 함수를 실행하기 위해 많은 작업을 수행한다. 그럼에도 불구하고, 메인 스레드에서 올바르게 실행하기 위해 스택에서 async_to_sync`의 *용례를 필요로 하다*. ``asyncio.run()`() 또는 유사한 것을 사용한다면, 단일의, 공유되는 스레드의 thread-sensitive 함수를 실행하는 것으로 돌아갈 것이지만, 이는 메인 스레드는 아닐 것이다.

django에서 필요한 이유는 많은 라이브러리들 중 특히 데이터베이스 어댑터들은, 라이브러리들이 생성된 같은 스레드에 액세스하는 것을 필요로 하기 때문이다. 또한 기존의 많은 django 코드는 같은 스레드에서 모두 실행하는 것을 가정하고, 예를 들어, 미들웨어는 뷰에서 이후에 사용할 것을 위한 것을 요청에 추가한다

이 코드의 잠재적인 호환성 문제를 내놓는 것 대신에, 존재하는 모든 django 동기식 코드가 같은 스레드에서 실행하고 비동기식 모드와 완전히 호환이 될 수 있도록 이 모드를 추가하기로 선택하였다. 동기식 코드는 항상 호출하는 비동기식 코드와 다른 스레드에 있으므로, 원시 데이터베이스 핸들이나 다른 thread-sensitive 참조를 전달하지 않아야 한다.

즉, 실 사용 시 데이터베이스 connection 객체의 기능들을 ``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.

Rather, you should encapsulate all database access within a helper function that can be called with sync_to_async() without relying on the connection object in the calling code.