백그라운드 작업을 사용하여 페이지를 캐시하는 방법은 무엇입니까?

Question

정의 : 자원 = 데이터베이스 레코드의 수집, 재생 = 이러한 레코드를 처리하고 해당 HTML을

전류 출력 :

• 수신 클라이언트 요청 캐시 자원에 대한
• 확인
• 그렇지 않은 경우 캐시 또는 캐시에서 만료 됨 재생 됨
• 결과가

재생성 단계에서 10-15 초 동안 단일 서버 프로세스를 묶을 수 있다는 것이 문제입니다. 몇 명의 사용자가 동일한 리소스를 요청하면 동일한 리소스를 동시에 재생하는 두 개의 프로세스가 생성 될 수 있으며 각각 10-15 초가 소요될 수 있습니다.

프론트 엔드에서 "이 리소스를 재생성하십시오."라는 메시지를 백그라운드 프로세스에 보내지 않는 것이 좋지 않을까요?

하지만 사용자에게 표시되는 내용은 무엇입니까? "Rebuilding"은 허용되지 않습니다. 모든 리소스는 미리 캐시에 있어야합니다. 데이터베이스가 파일 시스템에 거의 중복되어 메모리에 들어가기에는 너무 커서 문제가 될 수 있습니다. 이것을 피할 수있는 방법이 있습니까? 이상적은 아니지만 유일한 탈출구처럼 보입니다.

하지만 문제가 하나 더 있습니다. 동일한 두 프로세스가 자원 재생성을 동시에 요청하지 못하게하는 방법은 무엇입니까? 프론트 엔드가 동일한 자원의 재생성을 요청하면 백그라운드 프로세스가 자원을 재생성 할 수 있습니다.

플랫폼 관련 솔루션을 제공하고자하는 경우 PHP와 Zend Framework를 사용하고 있습니다. 그래도 문제는 아니지만 -이 문제는 모든 언어/프레임 워크에 적용된다고 생각합니다.

감사합니다.

Answer 1

Varnish을 사용하면 응답이 제 시간에 오지 않는 경우 사전에 캐시 된 페이지 콘텐츠를 캐시하고 유예로 캐시 된 콘텐츠를 표시 할 수 있습니다.

당신은 오래된 콘텐츠를 제공하는 기간에 대한 최적의 설정을 결정하기 위해 다이얼을 조정할 필요가 있습니다 (백엔드에서 개체를 가져 오는 중 오류 동안 니스는) 오래된 (하지만 캐시 객체를 제공) 유예 기간 사용 그리고 얼마나 오랜 시간이 걸릴지는 알지만, 그것은 당신을 위해 일해야합니다. Varnish performance 위키 페이지에 대한 추가 정보

Answer 2

나는 웹 서버 수준이 아니라 내가 각각의 경우에, 기본이 동일한 다른 몇 가지이 최근 불과했던

Answer 3

응용 프로그램에서 캐싱을 권장합니다 -이 경우의 정보는 사전 될 수 있습니다 사용하기 전에 생성됩니다.

PHP는 작업은 다음 다시 재건 것 까지 시간의 잠재적 수백 사용되는 Memcached가로 정보를 생성 (아마도 CRON에서) 정기적으로 실행됩니다.

잘 정의 된 기간 (60 분 또는 1 분)으로 캐시되지만 더 자주 재생성됩니다. 따라서 무언가가 잘못되지 않으면 Memcache에서 만료되지 않습니다. 최신 버전이 만료되기 전에 캐시되기 때문입니다. 물론, 당신은 단지 그들이 만료되지 않도록 준비 할 수 있습니다.

대기열을 통해 비슷한 작업을 수행했습니다. 이전에 'BeanstalkD'에 대한 질문을 볼 수 있습니다.

Answer 4

내용에 따라 jQuery.load()가 옵션 일 수 있습니다. (내가 트위터 피드를 사용)

단계
1 피드의 캐시 된 버전을 표시합니다.

2 단계
업데이트 jQuery.load를 통해 페이지의 내용()하고 그 결과를 캐시합니다.

.
이렇게하면 페이지가 빠르게로드되고 up2date 콘텐츠가 표시됩니다 (x 초 후에).
전체 페이지를 다시 작성 /로드하면 좋은 사용자 환경을 제공하지 못합니다.

Answer 5

몇 가지 문제를 설명합니다. 아마도 몇 가지 일반적인 아이디어가 도움이 될 것입니다.

하나의 문제는 생성 된 콘텐츠가 너무 커서 전체 저장소를 캐시 할 수 없기 때문에 생성 할 수있는 각 콘텐츠 개체를 고유하게 식별하는 방법, 콘텐츠 객체가 이미 캐시에있는 경우 캐시에서 데이터를 표시하여 백그라운드 재생성을 실행해야 함을 나타내는 정책과 캐시에서 데이터 만료 및 대체 정책을 지정합니다. 궁극적으로 고유 콘텐츠 식별을 간단하게 유지하면 성능이 향상되지만 개체 만료 정책 및 오래된 개체 표시는 콘텐츠 개체의 백그라운드 재생성 우선 순위를 정의하는 데 사용해야합니다. 이것들은 기존의 캐싱 체계에 대한 간단한 업데이트 일 수도 있지만, 반면에 희귀 한 문제가 아니기 때문에이 필요성을 해결하기 위해 특별히 제작 된 소프트웨어 패키지를 사용하는 것이 더 효과적 일 수 있습니다.

또 다른 문제는 콘텐츠를 재생성하기 위해 작품을 복제하고 싶지 않다는 것입니다. 기능이 다른 여러 개의 병렬 생성 엔진이있는 경우 이는별로 좋지 않을 수 있으며 첫 번째 생성기가 작업을 완료 할 때 각 큐에 작업을 대기시키고 다른 모든 대기열에서 작업을 제거하는 것이 가장 좋습니다. 무의식적으로 작업을 복제하지 않고 여러 백그라운드 재생 작업을 활성화 할 수 있도록 재생성이 진행 중일 때 개체 상태를 추적하는 것이 좋습니다. 다시 한번, 이것은 기존의 캐싱 시스템으로 대체되거나 전용 캐싱 소프트웨어 패키지에 의해 처리 될 수 있습니다.

세 번째 문제는 클라이언트가 캐시되지 않고 다시 생성해야하는 데이터를 요청할 때 수행해야 할 작업과 관련이 있습니다. 데이터를 완전히 재생성해야하는 경우 클라이언트가 재생성이 완료 될 때까지 기다리며 긴 컨텐츠 생성 시간에 도움이됩니다. 예를 들어 컨텐츠 객체를 캐시로 예측 예측하는 정책을 식별 할 수 있지만 컨텐츠 객체 간의 관계를 식별하는 메소드가 필요합니다 . 요청한 콘텐츠를 사용할 수있을 때까지 클라이언트를 "재생성"페이지로 제공할지 여부는 고객의 기대에 따라 다릅니다. 콘텐츠 재생성을 10-15 초 사이에 개선 할 수없는 경우 압축 된 데이터 아카이브가있는 다중 레벨 캐시를 고려하십시오.

성숙한 웹 캐싱 소프트웨어 패키지를 잘 활용하면 이러한 모든 문제를 해결할 수 있습니다.Nick Gerakines는 고객의 요구에 적합한 것으로 보이는 Varnish에 대해 언급했습니다.