Two Scoops of Django - #24장

이번장은 장고 성능 향상하기에 대한 내용이다.

생각보다 병목현상은 자주 일어날 수 있는데, 이를 해결하기 위한 팁들을 모아놓은 챕터인 거 같다.

 

1. 정말 (성능이란 것이) 신경 쓸 만한 일일까? : 서툰 최적화는 오히려 해가 될 수 있다. 아직 중소규모이고 페이지 로딩 속도에 문제가 없으면 신경 쓰지 않아도 된다.

 

2. 쿼리로 무거워진 페이지의 속도 개선 : 너무 많은 쿼리 때문에 생겨난 병목 현상을 줄이는 방안과 예상과는 달리 느리게 반응하는 쿼리 때문에 생긴 문제를 다룰 예정

 - django-debug-toolbar를 이용하여 문제가 되는 쿼리 찾기 : 페이지에서 중복된 쿼리, 예상한 것보다 많은 양의 쿼리를 호출하는 ORM은 호출(call), 느린 쿼리

 - 그런데 API 서버일 경우 장고 디버그 툴바는 사용 못할 듯..

 - 쿼리 수 줄이기 : selecte_related(), prefetch_related() 이용해 보기. 템플릿 하나당 하나 이상의 같은 쿼리가 호출되면 해당 쿼리를 파이썬 뷰로 이동시켜서 콘텍스트 자체를 변수로 처리하고 콘텍스트 변수에서 템플릿 ORM이 호출될 수 있도록 시도. 키/값 형식을 이용할 수 있는 캐시를 구현하거나 Memcached 등을 이용할 것.

 - 일반 쿼리를 빠르게 하기 : 개별 쿼리 속도 또한 병목 지점이 될 수 있음. 쿼리 속도를 늘리기 위한 몇 가지 팁 제공

  = 일반적으로 느린 쿼리들은 대부분 인덱스로 최적화 가능. 생성된 SQL문에서 WHERE/ORDER_BY를 자세히 볼 것

  = 실제 상용 환경에서 생성된 인덱스들이 정확히 어떤 역할을 하는지 살펴볼 것. (개발 서버랑은 다를 수 있음)

  = 쿼리 플랜을 살펴볼 것.

  = 데이터베이스에서 느린 쿼리 로깅 기능을 활성화하고 빈번히 발생하는 느린 쿼리 확인할 것

  = django-debug-toolbar를 이용하여 느려질 가능성 있는 쿼리 찾아낼 것

  = 가능한 한 작은 크기의 쿼리 결과가 반환되도록 로직 재구성해볼 것

  = 인덱스가 좀 더 효과적으로 작동할 수 있도록 모델을 재구성해 볼 것
  = SQL이 ORM에 의해 생성된 쿼리보다 더 효과적일 경우 SQL 직접 이용할 것

 - ATOMIC_REQUESTS 비활성화하기 : 보통은 True로 해도 무관하나 모든 쿼리를 트랜잭션으로 이용 시 속도 이슈가 발생할 수 있다.

 

3. 데이터베이스의 성능 최대한 이용하기 : 데이터 베이스 자체 최적화 필요

 - 데이터베이스에서 삼가야 할 것들 : 로그, 일시적 데이터 저장하지 말 것

 - DB 특성 최대한 활용

 

4. Memcached나 레디스를 이용하여 쿼리 캐시 : 간단한 세팅으로도 장고의 내장 캐시 시스템을 Memcached나 레디스와 연동 가능. 이러한 세팅으로 엄청난 성능 향상 가능. 사이트 전반에서 적용되는 캐시를 설정할 수도 있고 각 뷰나 템플릿 별로 캐시를 할 수도 있음. 파이썬 객체를 장고의 로우 레벨 캐시 API를 이용하여 캐시 할 수도 있음.

 

5. 캐시를 이용할 곳 정하기 : 고려해야 할 사항들

 - 가장 많은 쿼리를 포함하고 있는 뷰와 템플릿은 어떤 것인가?

 - 어떤 URL이 가장 많은 요청을 받는가?

 - 캐시를 삭제해야 할 시점은 언제인가?

 

6. 서드 파티 캐시 패키지

 - 쿼리 세트 캐시, 캐시 삭제 세팅과 메커니즘, 다양한 캐시 백엔드, 기존 캐시 시스템에 대한 대안과 실험적이며 과도기적 방법론 등의 기능 제공

 - 인기 있는 장고 캐시 패키지 : django-cache-machine, johnny-cache. 그러나 너무 신뢰하지는 말 것

 

7. HTML, CSS, 자바스크립트 압축과 최소화하기 : 아파치나 Nginx 같은 웹 서버를 이용하여 외부로 나가는 콘텐츠 압축할 것

 

8. 업스트림 캐시나 CDN 이용 : Varnish 같은 업스트림 캐시는 매우 유용. CloudFlare도 비슷한 서비스일 듯