2010-12-14 3 views
2

전체 사이트 또는 전체보기를 캐싱하는 대신 저수준 캐싱 API를 사용하여 몇 가지 무거운 쿼리 만 캐시하기로 결정했습니다.Django로 저수준 캐싱

내가 예상대로 그것은 거의 작동이

key = ... 
value = cache.get(key) 
if value is None: 
    value = ... 
    cache.set(key, value, CACHE_TIMEOUT) 

처럼 뭔가를하고 있어요 :
을 (질문 01?은 그것을 할 수있는 더 좋은 방법이있다)하지만 난에 CACHE_TIMEOUT을 설정하는 경우 큰 값 (86400 : db가 하루에 한 번 업데이트 됨)
CACHE_TIMEOUT이 다른 값으로 대체되고 있으며 그 값은 몇 분 동안 캐시됩니다.

(질문 02 :) 무엇이 잘못 되었나요?
시간 초과가 너무 깁니 까? 아니면 너무 많은 정보를 캐싱하고 있습니까? (value은 ~ 500-1000 개의 개체를 포함하고 있으며, 50-60 개의 다른 페이지/키로 평가됩니다.)

답변

1

일부 캐시 서버 (예 : memcached)는 손실이 있으며 최신 항목은 이전 항목을 캐시에서 강제로 제거합니다. 캐시 통계를 모니터하고 구성 및/또는 동작을 적절하게 수정하십시오.

+0

나는 memcached와 함께 노력하고있어. 당신은 내가 다른 것을 시도해야한다고 생각합니까? – dolma33

+0

을 당신이 캐시 통계를 모니터링해야한다고 생각 –

+0

고맙습니다 ... 문제점을 발견했습니다 ... 전체 사이트 캐싱 (3 개의 미들웨어 클래스)을 비활성화하지 않고 저수준 API로 작업하고있었습니다. 캐시 통계는 진실을 알고 있습니다. – dolma33

0

난 당신이 사용하고도 어떻게 정확하게 시간 제한을 설정하지만, 어쩌면 당신합니다 (django documentation on caching에서) 잘못하고있어 어떤 캐시 백엔드 모르는 :

각 캐시 백엔드 인수를 취할 수있다. CACHE_BACKEND 설정에서 쿼리 문자열 형식으로 제공됩니다. 다음과 같이 유효한 인수 은 다음과 같습니다

  • 시간 제한 : 기본 제한 시간 (초), 캐시에 사용할. 300 초 (5
  • 이 인수 기본값 ...

CACHE_BACKEND = "memcached://127.0.0.1:11211/?timeout=60

+1

'cache.set()'에 전달 된 값은 이것을 오버라이드한다. –