it-swarm-ko.tech

부스트가 표준 캐싱을 끄는 이유는 무엇입니까?

Boost 모듈을 활성화하면 표준 Drupal 캐싱이 비활성화됩니다 ( http://drupalperformanceblog.com/drupal-performance-tips) 참조 )이지만 "공격적"캐싱과 호환되지 않는 것으로 향상을보고 "일반"으로 되돌릴 수 있습니다.
부스트가 불필요하거나 적극적으로 유해하기 때문에이 기능을 해제합니까? 아니면 어쨌든 중요하지 않습니까?

(또한 니스가 사용되는 경우 "부스트"모듈을 사용하는 것이 중복됩니까? 다중 캐싱 시스템 사용을 참조하십시오.)

5
Parsingphase

hook_boot () 또는 hook_exit () 를 구현하는 모듈이있을 때 공격적인 캐싱을 비활성화하는 것은 시스템 모듈입니다.

캐싱 유형을 선택하기 위해 양식 필드에 나타나는 설명 텍스트에 설명이보고됩니다.

일반 캐시 모드는 대부분의 사이트에 적합하며 부작용을 일으키지 않습니다. 공격적인 캐시 모드 는 Drupal를 사용하여 서비스 할 때 활성화 된 모듈 의로드 (부팅) 및 언로드 (종료)을 건너 뛰도록합니다) 캐시 된 페이지로 인해 성능이 추가로 향상되지만 원치 않는 부작용이 발생할 수 있습니다.

Verify를 실행하는 코드는 다음과 같습니다 ( system_performance_settings () ).

  $problem_modules = array_unique(array_merge(module_implements('boot'), module_implements('exit')));
  sort($problem_modules);

  if (count($problem_modules) > 0) {
    $description .= '<p>' . t('<strong class="error">The following enabled modules are incompatible with aggressive mode caching and will not function properly: %modules</strong>', array('%modules' => implode(', ', $problem_modules))) . '.</p>';
  }

Boost는 Drupal 변수와 variable_set('cache', CACHE_DISABLED)_의 내용 만 변경합니다 . hook_enable () 의 구현에서와 같이, 일반적인 캐싱이 항상 활성화되어있는 경우이를 비활성화하는 이유는 다음 변수를 변경하는 코드 앞에 주석으로보고됩니다. "Drupal의 내장 SQL 캐싱을 강제로 비활성화하여 이해 상충을 방지하십시오."
즉, Drupal 및 Boost는 자체 캐시를 사용하여 캐시에서 데이터를 얻은 다음 캐시의 내용으로 대체 함)를 피하기 위해 모듈을 비활성화합니다. 다른 캐시.

Boost가 활성화 된 경우 캐시 선택기를 숨기는 것이 더 좋을 수 있습니다. 이러한 방식으로 사용자는 활성화시 Boost가 비활성화 한 캐시를 활성화 할 수 없습니다.

참고로, hook_boot()은 Drupal 8 에서 제거되었으며 hook_exit()은 Drupal 8도 에서 제거되었습니다. Drupal 6/7에 대해 여기서보고 한 내용은 더 이상 Drupal 8.

6
kiamlaluno