update_post_ (meta / term) _cache에 대한 설명


23

좀 이상 읽고 있었다 10up에서 모범 사례 (무엇을 당신에게있는 거 질의에 따라) 그리고 그들은 WP_Query에 거짓이 두 플래그를 설정 말할 것도 :

  • 'update_post_meta_cache' => false: 포스트 메타가 활용되지 않을 때 유용합니다.
  • 'update_post_term_cache' => false: 분류 용어가 사용되지 않을 때 유용합니다.

나는 그것을 무언가를 사용 한다고 가정update_post_caches() 하지만 그 의미가 100 % 확실하지 않습니다. 누군가이 두 깃발이 무엇을 의미 WP_Query하고 얼마나 유용한 지 설명 할 수 있습니까? WordPress가 물건을 캐시하는 방법에 대해 많이 알지 못하지만이 두 플래그에 대해 잘 생각하는 답변도 허용됩니다.

답변:


30

어디서나 객체 캐시

WordPress는 가능한 한 많은 데이터베이스 쿼리 수를 줄이려고합니다.

예를 들어, 메타 필드 또는 분류 체계 필드를 얻을 때마다 데이터베이스를 쿼리하기 전에 WordPress가 해당 쿼리가 이미 쿼리되어 캐시에 저장되어 있는지 확인한 다음 데이터베이스를 쿼리하는 대신 해당 필드에서 반환합니다.

"캐시 작업"은 WP_Object_Cache클래스 및 wp_cache_*함수 (해당 클래스 메소드의 랩퍼)를 통해 수행됩니다 .

캐시가있는 곳

기본적으로 "캐시"는 PHP 전역 변수에 지나지 않습니다. 메모리에 있음을 의미하지만 모든 요청에서 사라지는 것을 의미합니다.

그러나 드롭 인 ( advanced-cache.php및 / 또는 object-cache.php)을 통해이 캐시를 처리하는 사용자 정의 방법을 설정할 수 있습니다.

일반적으로이 드롭 인은 단일 요청을 "생존"하는 일종의 캐싱 메커니즘을 설정하는 데 사용됩니다.

이러한 이유로, WP 사람들 사이에서 "퍼시 스턴트 캐시"플러그인으로 알려져 있습니다 (버블 외부에서 "캐시"와 "퍼시 스턴트"라는 단어가 함께 이해되지는 않습니다).

요즘 인기있는 선택은 Memcached 또는 Redis 입니다.

따라서 "영구 캐시"플러그인을 사용하면 모든 요청에서 캐시가 업데이트되지 않기 때문에 데이터베이스 쿼리 수를 대폭 줄일 수 있습니다.

몇 가지 예

$foo = get_post_meta('foo', $post_id, true);
// a lot of code in the middle
$bar = get_post_meta('bar', $post_id, true);

위의 두 줄의 코드는 최대 1 개의 데이터베이스 쿼리를 트리거합니다.

실제로 사용자 정의 필드를 쿼리하면 해당 게시물의 모든 필드가 데이터베이스에서 검색되고 개체 캐시를 통해 캐시되며 후속 요청은 db가 아닌 캐시에서 데이터를 가져옵니다.

분류 용어에 대해서도 마찬가지입니다. WordPress는 분류에 대한 모든 용어를 한 번 가져온 다음 캐시에서 반환합니다.

개체 캐시는 WordPress에서 매우 널리 사용됩니다. 게시물, 메타 값 및 분류법뿐만 아니라 사용자, 의견, 테마 데이터도 ...

WP_Query이 모든 것과 어떤 관련 이 있습니까?

을 통해 일부 게시물을 쿼리 할 때 WP_Query기본적으로 WordPress는 데이터베이스에서 (또는 캐시 된 경우 캐시에서) 게시물을 가져올 뿐만 아니라 가져온 모든 게시물과 관련된 모든 사용자 정의 필드 및 모든 분류 체계에 대한 캐시를 업데이트합니다 .

따라서 예를 들어 호출 get_the_terms()하거나 get_post_meta()게시물을 반복하는 동안 WP_Query실제로 데이터베이스 쿼리를 트리거하지 않고 캐시에서 정보를 가져옵니다.

좋은가요?

네,하지만 비용이 듭니다.

메타를 위해 및 분류 체계 WP_Queryupdate_meta_cache위해 게시물을 가져올 때 WordPress에서 수행하는 캐시 업데이트 "마법" update_object_term_cache.

해당 함수의 소스 코드를 보면 WordPress가 각 함수마다 하나의 db 쿼리를 수행하지만 많은 처리를 수행한다는 것을 알 수 있습니다. 예를 들어,에서 update_object_term_cache7 중첩foreach ... 당신은 분류 체계의 많은 경우, 페이지 당 게시물의 수가이 매우 확대됨 아니다 높다.

WP_Query논쟁에 대해 마침내

무엇 'update_post_meta_cache''update_post_term_cache'로 설정하면 일은 false각각 사용자 정의 필드 및 분류 체계에 대한 업데이트 캐시에 워드 프레스를 방지하는 것입니다.

이 경우 사용자 지정 필드 나 분류 체계를 처음 쿼리하면 데이터베이스 쿼리가 트리거되고 데이터가 캐시됩니다.

그만한 가치가 있습니까?

평소와 같이 대답은 에 달려 있습니다. 이러한 값을로 설정하는 대부분의 시간 false은 불필요한 처리 및 데이터베이스 쿼리가 필요하지 않은 경우를 방지하고 사용자 정의 필드 / 분류법 용어가 처음 필요할 때 캐시가 업데이트되므로 좋은 선택입니다.

그러나 get_post_meta()루프 중에 한 번이라도 전화를 걸고 get_the_terms()게시물이 지원하는 모든 분류 (또는 대부분) 를 호출 하려는 경우 캐시 업데이트가 트리거되며 실제 이점이 없을 수 있습니다. 해당 쿼리 인수를로 설정하십시오 false.


산뜻한! 언제나 그렇듯이 통찰력은 언제나 높이 평가됩니다. GM. 과도는 "영구 캐시"로 간주됩니까? WP_Query 중에 Object Cache wp_reset_postdata()를 재설정 global $post하고 재설정하는 이유 는 무엇입니까? 사용자 정의 WP_Query를 수행하면 새로운 캐시 된 객체가 생성되지만 재설정하면 원래 캐시를 가져 오기 위해 다시 쿼리 해야하는 것처럼 들립니다. 아니면이 질문의 맥락에서 너무 멀리 나가고 있습니다.
Howdy_McGee

1
@Howdy_McGee 개체 캐시와 게시 개체는 관련이 없습니다. 따라서 wp_reset_postdata()개체 캐시와 관련하여 아무 것도 수행하지 마십시오. wp_reset_postdata()캐시되지 않은 글로벌 포스트 객체, 즉 또 다른 글로벌 변수 만 재설정하십시오. 과도는 하이브리드 일입니다. 일시적인 영구 캐시 플러그인이 설치되어있을 때 일시적으로 사용하지만 영구 캐시 플러그인이 없으면 과도 상태입니다. 데이터베이스를 사용하십시오.
gmazzap

아, 난 그냥에 래치 global variable개념과는 있었다 가정 global $post또는 글로벌 $wp_query객체 정화를위한 감사합니다!
Howdy_McGee

켜짐 (!) 참고 , fields => 'ids'모두 캐시를 설정합니다 false. 나는 그것이 객체 캐시는 객체에 작동 말이 생각하지만 난 그냥 언급 할 것이라고 생각 : D
Howdy_McGee

3

여기서 주요 관심사는 update_post_caches기능입니다. WP_Query가 DB에서 모든 게시물을 얻은 후에 호출됩니다. 일반적으로 게시물을 처음에 게시하려는 이유는 메타 데이터를 기반으로 용어와 무언가를 표시하는 것을 의미합니다. 따라서 WP_Query는 기본적으로 반환 된 게시물과 관련된 메타 및 용어 데이터에 대해 DB를 쿼리합니다. 캐시에 저장합니다 *. 이 정보는 WP_Query에서 리턴 된 데이터에서 명시 적으로 사용 가능하지 않지만 특정 게시물의 용어 및 메타 정보를 얻기 위해 관련 API를 호출 할 때 이미 메모리에서 사용 가능하며 새로운 메시지를 보낼 필요가 없습니다. DB에 쿼리하십시오.

이를 통해 워드 프레스는 각 게시물마다 요청을 보내는 대신 하나의 요청 만 보내 모든 게시물에 대한 정보를 가져옴으로써 DB로 요청을 보내는 것과 관련된 오버 헤드를 줄일 수 있습니다.

지금은 캐시를 업데이트하지 않으려는 사소한 예를 찾을 수 없지만 모든 게시물의 제목 목록을 원한다면 사소한 것일 수 있습니다. 이를 위해 용어 또는 메타 데이터가 필요하지 않습니다.

* 캐시-여기서 가장 중요한 것은 WP가 객체 캐싱 플러그인을 활성화하지 않아도 WP가 DB에서 얻는 모든 것을 알 모트에 저장하는 메모리 기반 캐시입니다. 분명히 객체 캐싱이 있으면 정보도 저장됩니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.