랜덤 캐시 만료

개별 요청으로 여러 항목을 한 번에 업데이트 해야하는 상황을 피하기 위해 임의의 캐시 만료 시간을 실험했습니다. 예를 들어, 웹 페이지에는 5 가지 구성 요소가 포함될 수 있습니다. 각각 30 분 안에 시간 초과되도록 설정하면 사용자는 30 분마다 대기 시간이 길어집니다. 대신 15 분에서 45 분 사이의 임의의 시간으로 모든 페이지로드에 대해 최대 하나의 구성 요소 만 다시로드 할 수 있도록 설정하십시오.

이 주제에 대한 연구 또는 지침 (예 : 최적 분산 변수)을 찾으려고합니다. Google (?) 이이 기술을 사용하는 방법에 대한 기사를 보았지만 찾을 수 없으며 주제에 대해 많이 쓰여 있지 않은 것 같습니다.

일부 문서 :

• 캐싱 최적화 로부터 하자 만들기 웹 빠른 구글 시리즈 (난 당신이 하나를 의미하는 것 같은데요?)
• 캐싱 튜토리얼 에 mnot.net
• SO 관련 질문도 있습니다.
  • Google PageSpeed에서 권장하는 HTTP 캐싱 만료 설정
  • Google 및 Yahoo에서 권장하는 HTTP 캐싱 만료 설정
• 그리고 다른 StackExchange 호스팅 질문도 있습니다.
  • 캐시 제어를위한 강력하고 빠른 규칙은 무엇입니까?

내 자신의 질문에 대답하기 위해 돌아 오는 주요 문제는 항상 동시에 만료되는 모든 것을 피하는 방법입니다. 이것이 허용되면 시스템은 캐시를 다시 채우는 동안 속도가 느려지고 정체됩니다.

대부분의 경우 실제로 이것은 실제로 문제가되지 않습니다. 시간이 지남에 따라 모든 구성 요소는 만료 시간 측면에서 표류하는 경향이 있습니다. 여러 개의 구성 요소가 동시에 동시에 재 구축되는 경우 단일 구성 요소로 함께 캐시되어야하기 때문에 코드 냄새가납니다 (예 : 페이지의 고유 한 머리글, 본문 및 바닥 글이 별도로 캐시 된 경우) 페이지 자체를 캐시하십시오).

전체 캐시를 지우거나 캐시 키를 회전 한 경우와 같이 시스템을 시작한 후 한 번에 많은 항목을 캐시해야하는 경우가 있습니다. 이 경우 구성 요소가 빠르게 채워지기 때문에 일반적으로 그렇게 나쁘지 않으며 만료는 나중에 표류합니다.

이것이 문제가되는 한, 몇 가지 해결책이 있습니다.

• 고정 된 기간 대신 범위 내에서 임의의 캐시 만료 기간을 선택하면됩니다 (예 : 60 분 대신 15 분에서 90 분 사이의 임의의 정수).
• 오래된 응답을 허용하십시오. 캐시 항목이 만료되었다고해서 여전히 캐시 항목을 사용할 수 없다는 의미는 아닙니다. 비즈니스 요구에 따라 만료 후 원본 버전을 가져 오는 성능 문제가있는 경우이를 사용할 수 있습니다. HTTP에서 이는 "must-revalidate"의 목적입니다 (만약 true이면 만료 후 캐시 된 버전을 사용 하지 않음 을 의미합니다 ).