https://fastapi.tiangolo.com/ko/async/#_16
fastapi 공식문서 보면 def로 API 만들면 내부적으로 스레드풀을 써서 메인 스레드 락을 안 건다고 하는데
그럼 def로 만든 API를 동시에 여러 번 호출했을 때, 그 안에서 CPU bound 작업을 하면 결국 파이썬 GIL 때문에 성능 이슈가 생기나요?
추가로 궁금한 게, fastapi의 BackgroundTasks는 메인 스레드를 사용하기에
def API에서 쓰더라도 결국 락이 걸리는 걸로 알고 있는데,
락 없이 BackgroundTasks처럼 API 응답 후에 따로 백그라운드로 작업 돌리는 방법은 어떤 식으로 구현하는 게 좋을까요?
1. 백엔드 갤러리 가서 물어봐라 양질의 답변을 얻을 수 있다. 2. chat-gpt같은 LLM 유료결제 중이면 거기다가 물어보면 훨씬 좋다 3. 곧 ㅆㅇㅆ 라는 비전공 앰생 개백수새끼가 와서 아는척 할텐데 백수새끼에 아는거 ㅈ도 없는 ㅈ문가니까 왠만해선 그새끼 말만큼은 듣지 마라
내 생각엔 이전에 에이도비가 말했듯이 Celery 쓰는게 맞는거 같은데,
엄청 규모가 큰 서비스는 아니라서 가급적이면 자체 문법으로 해결해보려고 합니다. 겸사겸사로 파이썬 문법에 대해서도 더 잘 알고 싶기도하고요!
@ㅇㅇ(61.97) 나는 이 부분은 잘모르겠다 미안해
그니까 자식 프로세스가 자신만의 GIL 가지는거
이새낀 아는척 안하는 분야가 없네 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
파이쓴 버전 몇쓰노?
3.13 부터 GIL 없다고 듣긴 했는데 그 아래 버전이라고 가정해주시면 감사할 것 같습니다.
그 상황에서 gil 때문에 생기는 이슈는 없다고 보면 됨 그리고 gil 억지로 우회하려고 하지 마. 코어를 거스르려고 하면 안됨 그건 금기야. 업데이트로 철퇴맞을 수도 있고 이후에 하위호환이 어려워질 수도 있고 여하간 정신적으로 별로 안좋음 그거 우회한다고 성능폭 별로 안늘어남 글고 gil걱정하는 거 보니 웹페이지 같은 걸 개발하나본데 그 경우는 한 두번 요청 주고 받기에 실패해도 재시도만 잘해주면됨. 따라서 레디스 셀러리 이런 거 써서 개발하는 게 훨씬 생산성 높음 무거운 작업(답변이 늦게 돌아오는 작업)은 워커로 돌리면 좋고 아예 여러 세션 워커들을 만들어서 여유있는 워커가 처리하는 것도 좋음 - dc App
파이썬은 3.10을 쓰는 게 지금으로서는 호환이 제일 넓게 되어서 좋을 거임 gil우회보다 멱등성 보장부터 배우는 게 기본이니 이거부터 하셈 gil 우회 같은 게 끌리면 고성능 파이썬이란 책을 읽어봐. 그런 뒤 그 책이랑 요즘 파이썬 사이의 갭은 본인이 패치노트 따라가면서 조금씩 따라잡으면됨 근데 실무자면 솔직히 고성능 파이썬 어쩌구 하느니 c++로 개발 후 래핑하겠지... - dc App