Question 1

라우팅에 들어가는 함수를 async def 로 비동기로 만들어 사용하는 것과 그냥 def 라고 만들어서 쓰는것의 차이가 궁금힙니다. 이렇게 쓴다는건 db도 asyncSession으로 되있는걸로 사용할텐데 이걸로 하면 장점이 무엇인가요? 속도차이가 많이 나나요?

Answer 1

def 을 쓰면, 요청마다 쓰레드를 만드니, 멀티 쓰레딩에 대한 오버헤드가 나고 async def을 쓰면, 이벤트 루프 하나에 코루틴으로 핸들러를 등록하니, 멀티 쓰레딩에서 일어나는 오버헤드가 없습니다. https://fastapi.tiangolo.com/async/#asynchronous-code

속도 차이가 많이 나느냐 -> 요거는 실제로 async, sync로 만들고 프로덕션 서비스에서 테스트 해보신 분들이 답변해주실텐데, 보통 그렇다고들 합니다. 일단 여기의 전제는 대부분의 웹 서버는 I/O Bound 하다는 전제가 있습니다.

Question 2

기존에는 flask로 api서비스를 만들었는데 async def로 요청을 받지 않고 def로 요청을 받아오 flask 보다 더 빠른가요? 만약에 빠르다고 하면 빠른 이유가 있나요? 저는 async def를 써야지만 빠르겠구나, def로 요청을 받으면 플라스크랑 비슷하겠지 생각을 했는데, 제가 잘못생각한건가요?

Anser 2

일단 앞단에서 받는 서버가 async로 동작하기 때문에 (ASGI), 요청 핸들링 자체가 비동기입니다. 따라서 flask를 “그냥” 쓰는거보다는 훨씬 빠른거 같습니다. (제말이 틀릴 수도 있어요.) https://gist.github.com/nhymxu/814cf9b3294276629d2231248b709e26

위 링크 보시면, 누군가가 벤치마킹 테스트한 게 있는데요.

그리고 Flask -> FastAPI로 넘어오는 분들은 이런 비동기 성능 문제도 물론 있지만, 이걸 고려할 타이밍이 아닌경우, 대부분 FastAPI가 주는 기능 (Validation, Swaager)과 사용성 (Typing, Community) 때문에 넘어오시는거 같습니다.

async를 안서도 flask과 request 차이가 많이 난다

이 의견에 대한 답변: 아마 그건 시리얼라이징 성능이지 않을까 싶네요 저 벤치마킹에서 각기 어떻게 코드를 작성했는지는 모르겠지만.

의견: 시리얼라이징이라면 json library 를 바꾸는것만으로도 속도가 증가 할까요~?

노드가 JSON 시리얼라이징 할 때 기본 자바스크립트 라이브러리를 권장하지 않는 것도 그 이유였으니깐요 물론 확실하지는 않습니다. 정확한건 벤치마킹했을 때 어떤 코드를 썼는지 봐야 가장 확실하겠지요

Pydantic이 나오기 이전까지만 해도 여러 시리얼라이징 라이브러리 (Marshmallow 등)가 있었지만 Pydantic이 런타임에서 타입까지 봐주면서도 성능이 더 좋았지요

다른 분의 근거: 그러고보니 Pydantic 2.0 프리릴리즈의 경우, 코어 validation 로직을 Rust로 바꾸면서 성능향상을 목표로 하고있는 것 같더군요 https://docs.pydantic.dev/latest/blog/pydantic-v2-alpha/

맞습니다. 노드 진영에서 Rust로 빌드 속도를 늘린것처럼 파이썬 진영에서도 그런 모습을 보이고 있는 대표적인 사례가 Pydantic 입니다.