[Fastapi] asyncio 제대로 써보기 with pytest - 3

지난 포스팅에서 asyncio를 사용했을 때 더 느려지는 경우와 더 빨라지는 경우를 알아봤다.

 

특히나 asyncio를 써도 같은 상황에서 더 느려지는 경우가 있어 그 부분에 대한 분석을 했었다.

이번에는 그 분석에 따른 가설을 실험해 보고 asyncio에 대해서 좀 더 자세하게 알아보고자 한다.

 

지난 포스팅으로 알게 된 것은 어떤 메소드 안에서 비동기적 동작이 이루어 지지 않는 경우

오히려 이벤트 루프를 돌리는 비용때문에 손해를 본다는 것이었는데

그에따라 하나의 메소드 안에서 비동기적 동작이 등장한다면 더 이득을 볼 수 있을 것이다 라는 가설을 얻었다.

 

만약 user에 따른 items가 여러개 들어오고 그에 맞게 모든 item을 업로드 해야하는 상황이라면

각각의 item을 DB에 insert하는 동작을 비동기로 수행하는 경우를 생각해 볼 수 있다.

 

1.  Sync Client - Sync App

동일한 과정으로 실험할 것이다.

우선 클라이언트에서 보내는 데이터의 형태를 위와 같이 수정한다.

items에는 총 5개의 데이터가 있으며 이 데이터들을 하나의 user와 함께 전송하고 업로드하는 과정이다.

비동기를 쓰지 않고 for문을 돌려서 각 아이템을 얻고 DB에 저장한다.

세션을 만들고 닫는 시간을 고려하더라도

user만 작성할 때 보다 더 긴 시간이 걸릴 것을 예상할 수 있다.

33초에 걸쳐 순차적으로 모든 과정이 진행되었다.

 

2.  Async Client - Sync App

이번에는 aiohttp의 async Session을 이용한다.

 

이 경우 6초 정도 걸린 것을 볼 수 있다.

각각의 동작은 비동기 적으로 진행되었으며

1개의 user와 5개의 item을 작성하는 1번의 동작이 약 6초에 가까운 시간으로 수행된다고 볼 수 있다.

 

3.  Sync Client - Async App

app의 비동기적 구현을 위해 위와 같은 작업을 해 주었다.

우선 user테이블을 만들고 user 테이블로 부터 item의 owner_id 를 가져온다.

그리고 같은 owner_id를 공유하는 아이템들은 모두 비동기 세션으로 업로드 되도록 하였다.

 

이전에는 33초가 걸렸던 동작이 이번에는 30초가 걸리게 되었다.

어느 정도의 이득을 볼 수 있다.

 

4.  Async Client - Async App

이번엔 두가지 모두 비동기로 작성했을 경우다. 이 경우에는 4초 대가 나오고 가장 짧은 시간이 걸린 것을 알 수 있다.

결론

비동기 처리는 요청-응답의 시간지연에서 큰 효과를 본다.

하지만 시간지연을 감지하고 우선권을 양보하는 기능없다면 코루틴으로서 역할을 못한다.

그런경우 그냥 동기적으로 작성하는 것이 좋다.

app과 DB의 소통에서 발생하는 지연의 경우

여러 쿼리를 동시에 수행하는 경우가 아니면 오히려 이벤트루프만큼 비용이 들어가므로

순차적인 쿼리의 경우 동기적 방식으로 작성하는 것이 더 좋다.