Caché de objetos en todas partes

WordPress intenta reducir el número de consultas de base de datos tanto como sea posible.

Por ejemplo, cada vez que obtiene un metacampo o un campo de taxonomía, antes de consultar la base de datos, WordPress busca si eso ya fue consultado y almacenado en el caché, y lo devuelve desde allí en lugar de consultar la base de datos.

El "trabajo de caché" se realiza a través de WP_Object_Cache class y wp_cache_* funciones (que están más ajustados a eso) métodos de clase.)

Donde vive el caché

Por defecto, el "caché" no es más que una variable global de PHP. Significa que está en la memoria, pero también significa que desaparece con cada solicitud.

Sin embargo, a través de dropins ( advanced-cache.php y / o object-cache.php ), es posible configurar una forma personalizada para manejar este caché.

Generalmente, estos dropins se utilizan para configurar algún tipo de mecanismo de almacenamiento en caché que "sobrevive" a las solicitudes singulares.

Por esta razón, entre las personas de WP, estos se conocen como complementos de "caché persistente" (incluso si fuera de la burbuja las palabras "caché" y "persistente" no tienen mucho sentido juntas).

Las opciones populares hoy en día son Memcached o Redis .

Por lo tanto, al usar los complementos de "caché persistente" puede reducir drásticamente el número de consultas de la base de datos, ya que el caché no se actualiza en cada solicitud.

Algunos ejemplos

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

Las 2 líneas de código anteriores activarán, como máximo, 1 consulta de base de datos.

De hecho, cuando consulta un campo personalizado, todos los campos para esa publicación se recuperan de la base de datos, se almacenan en caché a través del caché de objetos, y las solicitudes subsiguientes extraen datos del caché y no de la base de datos.

Lo mismo sucede con los términos de taxonomía, WordPress extrae todos los términos de una taxonomía una vez y luego los devuelve de la caché.

El caché de objetos se usa mucho en WordPress. No solo para publicaciones, meta valores y taxonomías, sino también para usuarios, comentarios, datos de temas ...

¿Qué WP_Query tiene que ver con todo esto?

Cuando consulta algunas publicaciones a través de WP_Query , WordPress no solo las extrae de la base de datos (o de la caché si están almacenadas en caché) sino que también actualiza la caché para todos los campos personalizados y todas las taxonomías relacionado con las publicaciones extraídas.

Entonces, cuando llama, por ejemplo, get_the_terms() o get_post_meta() , mientras que las publicaciones en bucle se obtienen a través de WP_Query , en realidad no activa ninguna consulta de la base de datos, sino que extrae información de la caché.

Agradable, ¿no es así?

Bueno, sí, pero tiene un costo.

La actualización "mágica" de la memoria caché que WordPress realiza cuando se extraen publicaciones a través de WP_Query ocurre en update_meta_cache para meta y en update_object_term_cache para taxonomías.

Si observa el código fuente de esas funciones, verá que WordPress realiza solo una consulta de db en cada función, pero también realiza mucho procesamiento. Por ejemplo, en update_object_term_cache hay 7 anested foreach ... si tiene muchas taxonomías y el número de publicaciones por página es alto, esto no es muy eficaz.

Sobre esos argumentos WP_Query , finalmente

Lo que hacen 'update_post_meta_cache' y 'update_post_term_cache' cuando se establece en false es evitar que WordPress actualice la caché para campos personalizados y taxonomías, respectivamente.

En ese caso, la primera vez que se consulta un campo personalizado o una taxonomía, se desencadena una consulta de base de datos y los datos se almacenan en caché.

¿Vale la pena?

Como de costumbre, la respuesta es depende . La mayoría de las veces para establecer esos valores en false , es una buena opción, porque evita el procesamiento innecesario y las consultas de la base de datos si no son necesarias, y la caché se actualiza de todos modos la primera vez que se requieren términos personalizados de campo / taxonomía.

Sin embargo, si va a llamar, incluso una vez, get_post_meta() durante el ciclo y va a llamar a get_the_terms() para todas (o la mayoría) de las taxonomías soportadas por las publicaciones, entonces la actualización de la caché se activa de todos modos y es posible que no haya un beneficio real al configurar esos argumentos de consulta en false .

El principal punto de interés aquí es la función update_post_caches . Se llama después de que WP_Query obtuviera todas las publicaciones del DB. Por lo general, la razón por la que desea que las publicaciones sean, en primer lugar, es mostrarlas, lo que generalmente significa mostrar los términos y algo en función de los metadatos, por lo tanto, WP_Query también consultará por defecto la base de datos para los datos de metadatos y términos relacionados con las publicaciones devueltas y lo almacena el caché *. Esta información no está disponible explícitamente en los datos devueltos por WP_Query, pero cuando llame a las API relevantes para obtener el término y la meta información de una publicación específica, ya estará disponible en la memoria y no habrá necesidad de enviar una nueva Consulta al DB.

Esto permite que wordpress reduzca los gastos generales relacionados con el envío de solicitudes a la base de datos enviando solo una solicitud para obtener la información de todas las publicaciones en lugar de enviar una solicitud por cada publicación.

En este momento no puedo encontrar ningún ejemplo no trivial de cuándo no querrá que se actualice el caché, pero podría ser uno trivial si solo desea una lista de los títulos de todas las publicaciones. Para eso no necesitas término ni metadatos.

* caché: lo más importante aquí es el caché basado en memoria en el que WP almacena casi todo lo que obtiene de la base de datos, incluso sin tener ningún complemento de almacenamiento en caché de objetos activo. Obviamente, cuando tenga objetos en caché, la información también se almacenará allí.