매일 글을 쓰다보니 인풋을 찾게 되는데, 그러다 프레임워크의 성능에 대한 아티클을 몇개 읽었다.
그러다 비디어스에 적용할만한 요소가 있어서, 테스트를 해봤다.
이번 테스트를 해보게 된 계기인 ujson을 먼저 테스트해봤다. ujson은 UltraJSON 이라는 패키지인데, 설명을 보면
UltraJSON is an ultra fast JSON encoder and decoder written in pure C with bindings for Python 3.8+.
라고 쓰여있다. C 로 작성된 코드를 바인딩 해놓은 패키지이기 때문에 성능이 굉장히 훌륭하다고 한다.
실제로 여러 커뮤니티나 사용자 후기를 보는데, 파이썬에 내장된 json 패키지보다 월등히 성능이 좋다고 한다.
그래서 기대를 안고 테스트를 했다.
현재 비디어스를 리뉴얼하면서 통합 검색 API가 추가되었는데, 이 API 와 포트폴리오, 공고 상세에 대한 API로 테스트를 했다. 결론부터 얘기하면 오차범위 내 변화라 사실상 성능 변화가 느껴지지는 않는다.
테스트 환경
파이썬 버전 | 3.10, 3.11 |
Django 버전 | 4.1.3 |
DRF(Django REST Framework) 버전 | 3.12.2 |
DRF(Django REST Framework) + ujson
통합 검색 API
Renderer: rest_framework.renderers.JSONRenderer
회차 | API 응답시간 (초) |
---|---|
1회차 | 0.170364 |
2회차 | 0.171526 |
3회차 | 0.179104 |
4회차 | 0.177258 |
5회차 | 0.186122 |
6회차 | 0.175520 |
7회차 | 0.173822 |
8회차 | 0.211458 |
9회차 | 0.179277 |
10회차 | 0.205453 |
평균 | 0.18125779 |
Renderer: drf_ujson.renderers.UJSONRenderer
회차 | API 응답시간 (초) |
---|---|
1회차 | 0.170603 |
2회차 | 0.166884 |
3회차 | 0.172315 |
4회차 | 0.163895 |
5회차 | 0.180874 |
6회차 | 0.179463 |
7회차 | 0.177123 |
8회차 | 0.184023 |
9회차 | 0.186473 |
10회차 | 0.180005 |
평균 | 0.1794636 |
아주 미묘하게 성능 향상이 있는 것 같지만, 각 회차별 응답 시간을 보면 차이가 없다고 느껴진다.
공고 상세 API
Renderer: rest_framework.renderers.JSONRenderer
회차 | API 응답시간 (초) |
---|---|
1회차 | 0.211953 |
2회차 | 0.226056 |
3회차 | 0.225630 |
4회차 | 0.225215 |
5회차 | 0.223587 |
6회차 | 0.220053 |
7회차 | 0.224348 |
8회차 | 0.229481 |
9회차 | 0.227375 |
10회차 | 0.227100 |
평균 | 0.224078 |
Renderer: drf_ujson.renderers.UJSONRenderer
회차 | API 응답시간 (초) |
---|---|
1회차 | 0.221158 |
2회차 | 0.213329 |
3회차 | 0.225868 |
4회차 | 0.230292 |
5회차 | 0.229035 |
6회차 | 0.227065 |
7회차 | 0.216055 |
8회차 | 0.229859 |
9회차 | 0.227423 |
10회차 | 0.226981 |
평균 | 0.2247065 |
사실, 이렇게까지 차이가 없을 줄은 몰랐다. 한창 테스트하다 말고 DRF 의 JSONRenderer의 코드를 뜯어서 파이썬 내장 json 패키지를 사용하고 있는 것이 맞는 지까지 확인했다.ㅎㅎ
포트롤리오 상세 API
큰 의미가 없어서 평균만 추가했다.
rest_framework.renderers.JSONRenderer | drf_ujson.renderers.UJSONRenderer |
---|---|
0.0428815 | 0.0432197 |
결론적으로, 데이터 분석이나 엔지니어링과 같이 큰 데이터를 JSON 으로 활용하기 위해서 사용할 때 큰 차이가 있을 것 같다.
CONN_HEALTH_CHECKS
Django 의 ORM은 API 요청을 받고 DB에 접근하는 순간 DB에 커넥션을 구축하고, API 처리가 완료되면 커넥션을 닫는다. 이렇게 만든 이유는 다른 옵션들을 통해 확인할 수 있는데, 트랜잭션 처리를 위해 이렇게 처리한 것 같다.
실제로 커넥션을 POOL로 관리하도록 사용할 수 있는 패키지가 있는데, 이런 패키지들을 사용할 경우 트랜잭션 이슈로 DISABLE_SERVER_SIDE_CURSORS
을 True로 변경해야 한다고 한다. (관련내용)
4.1에서 추가된 이 옵션은 DB open/close 의 오버헤드를 줄이기 위해 추가된 옵션이다. 기존에는 CONN_MAX_AGE 를 설정하여 커넥션의 라이프타임을 설정하거나 무제한 설정하여 비슷한 기능을 제공했지만, CONN_HEALTH_CHECKS옵션을 통해 무제한 설정이 가능하면서도 장애 상황에 커넥션 재구축을 자동으로 처리할 수 있게 해준다.
이 옵션은 사실 테스트해보기 전부터 꽤 성능향상이 있을 것 같았다. DB 커넥션을 구축하는 일은 꽤 무거운 작업이기 때문이다.
통합 검색 API
기존 | CONN_HEALTH_CHECKS: True |
---|---|
0.1917764 | 0.1749721 |
역시나 눈에 띄게 성능이 나아졌다.
파이썬 3.11 업데이트
현재 사용중인 파이썬 버전은 3.10 인데, 3.11 버전을 사용하면 성능이 10% ~ 60% 향상이 된다고 알려져있어서 시도했다.
통합 검색 API
Python 3.10 | Python 3.11 |
---|---|
0.1749721 | 0.1795899 |
역시 언어의 성능 향상은 실제 향상으로 기대하긴 어려운 것 같다.
잉여 시간이 생기니 이렇게 즐거울 일이다~~