쿼리스트링으로 keyword와 offset을 받아와서 DB에서 자료를 가져오고
로컬 쿼리 캐시에 담아 슬라이싱으로 통해 페이지네이션을 구현한 코드이다.
DB에서 가져오는 데이터가 많다 보니 (대략 100만 건 정도)
매번 DB에 접근하는 게 딜레이도 발생되고 (10초 정도)
비효율적이라 쿼리 캐시를 사용했는데
쿼리스트링에 변화가 없는, 그러니까 중복된 호출건의 경우엔
소스코드 하단에 있는 print문이 작동하지 않고 바로 결과를 반환한다.
당연히 오프셋이 바뀌거나 키워드가 바뀌는 등, 쿼리스트링에 변화가 생기면
print문은 정상적으로 출력이 된다.
기능의 구현에는 문제가 없지만 왜 print문이 무시되는지 정말 궁금해서
위코드 커뮤니티에 질문을 올렸고 답변이 올라오면 블로그 글도 업데이트할 예정이다.
되게 간단한 부분을 놓친 게 아닐까 싶은데...
이유를 알았다.
이유는 알았는데 정확한 원인을 이해하진 못했다.
MIDDLEWARE = [
'django.middleware.cache.UpdateCacheMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.cache.FetchFromCacheMiddleware',
]
django 공식 문서에 캐시 프레임워크 부분을 살펴보면 'The per-site cache' 부분에
위의 미들웨어 설정이 나온다.
UpdateCacheMiddleware와 FetchFromCacheMiddleware를 settings.py에 순서에 맞게 배치해야 하며
마지막 FetchFromCacheMiddleware를 주석 처리하면
중복된 호출일지라도 소스코드를 읽게 되므로 당연히 print문이 출력되게 된다.
FetchFromCacheMiddleware는 상태 코드 200을 갖는 GET과 HEAD 메서드로 요청이 들어올 때 전체 페이지를 캐싱하는데
중복 요청의 경우에 소스코드를 읽지 않고 캐시에서 저장된 페이지를 찾아 반환한다고 한다.
만약 해당 부문 주석 처리를 하지 않고 상태 코드를 201로 주면 똑같이 소스코드를 읽는다.
상태 코드 200의 경우 리소스를 읽어오지만 201의 경우는 새로운 리소스를 생성한다.
생성된 리소스가 헤더에 저장된다고 보았는데,
그 영향으로 동일 호출로 인식되지 않고 소스코드를 읽게 되는 게 아닌가 생각된다.
좀더 자세히 알고 싶은데 django 문서나 구글링에 잘 나오지 않아서 (내가 못 찾는 것일 수도)
이 정도로 정리할 수 있을 것 같다.
추후 좀더 자세한 내용을 알게 되면 공유해야겠다.
