3
대용량 데이터가있는 Symfony 1.4 프로젝트를 실행합니다. 기본 페이지 및 카테고리 페이지는 사용 가능한 행의 수를 알아야하는 호출기를 사용합니다. 나는이 페이지들에서 1 분의 로딩 시간을 이끌어내는 호출기에 조인을 포함하는 질의를 전달하고있다.자동으로 캐시를 다시 작성
각 작업에 대해 cache.yml을 구성했습니다. 하지만 해결 방법이 충분하지 않으며 여기에 내 가정이 있다고 생각합니다.
Symfony는 사용자가 한 번의 요청으로 캐시를 다시 작성합니다. 사물을 단순화하기 위해이 사용자를 "캐시 피해자"라고 부르 자.
우리의 경우 데이터를 최신 상태로 업데이트해야하므로 10 분이면 충분합니다. 분명히 사용자가 "캐시 피해자"가되어서 기꺼이 요청을 취소하지 않으면 캐시가 다시 작성되지 않습니다. 이 가정은 정확합니까?
그래서이 아이디어를 내놓았습니다 : Symfony는 캐시를 재 구축 한 후 http-request를 위장해야합니다. 새 캐시 항목은 임시 파일/디렉토리에 기록해야하며 캐시 재구성이 완료되면 바로 이전 캐시 항목으로 스와핑해야합니다.
이것이 가능합니까?
제 생각에는 이중 버퍼링의 개념과 비슷합니다.
화면이 한 줄씩 늘어나는 멀티 플레이어 게임에 "gpu-victim"이 하나만 있다면 어리석지 않습니까? (이것은 내가 알고하는 베다 양면 비교입니다 ...;))
편집에는 "캐시 피해자가"없다
- 매 10 초마다 페이지를 다시로드는 모든 사용자에게 1 분이 소요됩니다.
은 솔직히 (? 내가 제대로 이해하면) 내가 먼저 왜 호출기에 대한 행을 계산에보고 싶은데 1 분 소요에 참조 완료하십시오. 어느 쪽이든 해결해야 할 분명한 문제는 부실 캐시가있는 로딩 시간입니다.둘째, 요청을 취소하는 사용자는 일반적으로 웹 서버가 요청 실행을 완료하지 못하도록합니다 (시간이 초과되거나 다른 한도에 도달하지 않는 한). – Gerry
알겠습니다. 그러면 "요청 처리 중"이 취소됩니다. 많은 양의 데이터와 조인 때문에 1 분이 소요됩니다. 호출기 - 쿼리 자체는 매우 간단합니다. 호출기는 사용 가능한 페이지 수를 계산하므로 항목 수를 알아야합니다. – fishbone
먼저 그 일을해야한다고 제안합니다. 왜 호출기를 채우는 것이 그렇게 오래 걸릴지에 대한 현명한 설명을 볼 수 없습니다. 나는 당신이 그것을 최적화 할 수 있다고 확신하지만, 구체적인 것을 알지 못하면 더 이상 논평 할 수 없습니다. – Gerry