뷰가 코어 캐싱 메커니즘을 통해 캐시됩니까? 아니면 각 뷰에서 캐싱을 직접 설정해야합니까?

각보기마다 캐시 설정이 있습니다. 이것을 설정해야합니까? 또는 / admin / config / development / performance의 핵심 캐싱 메커니즘이 자동으로이 중 일부를 수행하며 뷰의 이러한 "추가 설정"은 drupal core의 기본 캐싱 동작을 무시하려는 경우입니까?

무엇 : 코어 성능 캐시 저장하고하면 URL의 캐시 ID로 전체 렌더링 된 페이지를 제공합니다. 뷰 캐싱은이를 넘어서 뷰 출력 만 캐시합니다.

이유 : 로그인 한 사용자에게 좋습니다. 페이지의 다른 블록은 더 역동적 일 수 있지만 뷰는 모든 사용자에 대해 매번 쿼리를 실행할 필요가 없습니다. 캐시 수명이 만료되면 페이지 캐시를 생성하는 가끔 발생하는 사용자 만 있습니다.

설정 : "렌더링 된 출력"을 쿼리보다 최신 상태로 유지하면 콘텐츠를 새로운 것으로 표시하는 데 유용합니다. 그렇지 않으면 일치시킵니다.

큰 그림 : Drupal은 서버를 사용하여 페이지를 동적으로 제공하여 PHP로 페이지를 작성하고 데이터베이스 (또는 인 메모리 캐시)에 액세스합니다. 이를 통해 멋진 기능과 컨텐츠 편집기 속도가 가능하지만 캐싱을 이해하고 올바르게 수행해야합니다.

모듈!

콘텐츠 편집시 뷰 캐시를 지우는 멋진 Views Content Cache 모듈도 있습니다. 더 나아가고 싶다면 캐시 동작 도 확인하고 싶을 수도 있습니다 . 규칙 을 미세 조정하는 것이 좋습니다 .

또한 Blockcache Alter를 사용하면 사이트의 각 블록에 대해 "역할 당", 페이지, 사용자 등의 캐싱 옵션을 설정할 수 있습니다.

페이지 관리자 및 패널을 추가 할 수도 있습니다 . 이를 통해 "사용자 별", "역할 당"또는 기타 여러 유용한 구성 설정과 같은 흥미로운 작업을 수행 할 수 있습니다. 나는 개인적으로 패널을 피하지만.

문서 : 캐싱 및 성능에 대한 일반적인 내용 은 Drupal.org 페이지를 참조하십시오 .

뷰는 Drupal 캐시 API를 사용하지만 일반적인 Drupal 페이지 / 블록 캐시와 관련이없는 자체 캐시를 생성합니다.

뷰는 렌더링 된 뷰 자체와 함께 뷰 정의 자체를 캐시합니다. 렌더링 된 뷰는 쿼리 결과 또는 뷰의 실제 HTML이라는 두 가지 방식으로 캐시 될 수 있습니다. 일반적으로 출력 된 HTML이 가장 효과적이기 때문에 출력 된 HTML을 캐시하려고합니다. 로그인 한 사용자를 기반으로 출력을 변경하려는 경우 쿼리 캐싱도 매우 효과적 일 수 있습니다.

뷰가 캐시를 저장하는 데 사용하는 테이블은 다음과 같습니다.

• cache_views
• cache_views_data

노출 된 폼이있는 뷰를 제외한 모든 뷰 (쿼리 결과 및 출력)를 자동으로 캐시하는 뷰 캐시 깡패 라는 흥미로운 모듈이 있습니다 . 이 모듈을 사용하면 캐싱에서보기를 수동으로 제외 할 수도 있습니다. 이를 통해 중심점에서 모든 뷰 (제외 된 뷰 제외)에 대해 캐싱을 설정할 수 있습니다.

Drupal 7은 페이지 캐싱을 제공하지만 페이지 캐싱은 익명 사용자에게만 작동하며보기를 캐시하지 않습니다.

뷰 캐싱은 익명 사용자와 로그인 한 사용자 모두에게 작동합니다.