Drupal: Almacenamiento en Caché
Primary tabs
Hace mucho que no escribo algo en el blog, por eso para no perder la costumbre de escribir algo, les comparto una traducción del artículo "Caching in Drupal" originalmente publicado en el Blog de "The Agile Approach" por Chris Johnson, la traducción es mía, así que es posible que algunas cosas no las traduzca tan literal sino con pequeños ajustes.
Normalmente la caché es usada para aumentar el rendimiento de los sitios web basados en Drupal y hay muchos módulos y opciones para lograr un control granular fino de que ítem expiran. Sin embargo la configuración estándar de la caché dentro de las opciones de rendimiento con frecuencia son mal interpretadas y los diferentes sistemas de almacenamiento en caché tienen un comportamiento ligeramente diferente. Este es un desglose de que significan las configuraciones para la caché de páginas y como los dos motores de almacenamiento más comunes se comportan para eventos particulares.
Caché de páginas para usuarios anónimos
La primera configuración de caché dentro de las opciones de rendimiento es la caché de páginas para usuarios anónimos. Esta debe ser establecida para que las otras opciones de más abajo tengan efecto y le digan a Drupal que todo está listo para almacenar la versión renderizada de una página generada para un usuario no autenticado y poder servirla a otro. Las páginas son almacenadas con un ID de caché de la URL de la solicitud, técnicamente $base_root. request_uri(), de tal forma que una solicitud para http://example.com/page_one y http://example.com/page_one?rand=1 son consideradas dos solicitudes distintas y generadas separadamente incluso si el parámetro al final de la URL no tiene efecto en el renderizado de la página.
Una vez el caché de página está habilitado hay dos configuraciones a considerar: el Mínimo de permanencia en caché y el vencimiento de las páginas en caché.
El mínimo de permanencia en caché es a menudo mal interpretado como "las páginas serán regeneradas después de que este tiempo ha pasado". Lo que realmente significa es que las páginas no serán regeneradas hasta que al menos como mucho haya pasado este tiempo y un evento de limpieza de caché ocurrirá. Discutiremos los eventos de limpieza de caché después de cubrir el vencimiento de las páginas en caché.
El vencimiento de las páginas en caché es también mal interpretado algunas veces. Este valor controla que valor es enviado como max-age en la cabecera de Cache-Control y por lo tanto informa a los servidores proxy cuanto tiempo pueden servir la página sin preguntar a Drupal por una nueva copia. Esto no significa que la página será regenerada hasta después de este tiempo, esto solo significa que el servidor proxy debe revisar de nuevo en Drupal para ver si existe una nueva versión de la página después de este tiempo. Drupal solo regenerará una página después de que un evento de limpieza de caché ocurra.
Evento de limpieza de caché
He mencionado el evento de limpieza caché varias veces en este punto y pienso que es lo más importante a entender cuando se trabaja con el almacenamiento de páginas en caché de Drupal. Drupal solo regenerará una página cuando tiene una razón para sospechar que el resultado de la regeneración de la página será diferente que el resultado anterior. Las cosas que hacen que Drupal piense que el resultado de la regeneración puede ser diferente son que he llamado los eventos de limpieza de caché, principalmente porque ellos causan que la función cache_clear_all sea llamada. Lo que es considerado como un evento de limpieza de caché varía según el motor de almacenamiento de caché que esté siendo usado y también variará como interactúa con el mínimo de permanencia en caché.
Los dos motores de almacenamiento en caché más comunes son la base de datos y Memcached (La clase DrupalDatabaseCache y la clase MemCacheDrupal). A continuación se muestra una tabla que muestra su comportamiento durante los eventos típicos de limpieza de caché.
| Cache | Cron | Cache Clear All | EDICIÓN DE CONTENIDO |
|---|---|---|---|
| Base de datos | La caché de página será limpiada en el mínimo de permanencia en caché.. | La caché de página se limpia inmediatamente y se limpiará de nuevo en el mínimo de permanencia en caché. | La caché de página se limpiará en el mínimo de permanencia en caché. |
| Memcached | No es considerado como un evento de limpieza de caché | La caché de página tiene en cuenta todos los ítems generados antes de la hora actual menores al mínimo de permanencia en caché vencido (a fin de limpiarlos). Los items generados después no son considerados como vencidos hasta que el siguiente evento de limpieza de caché ocurra. | La caché de página tiene en cuenta todos los ítems generados antes de la hora actual menores al mínimo de permanencia en caché vencido (a fin de limpiarlos). Los items generados después no son considerados como vencidos hasta que el siguiente evento de limpieza de caché ocurra. |
El tratamiento de la ejecución del cron como un evento de limpieza de caché cuando se está usando la caché de la base de datos como almacenamiento de caché combinado con la frecuencia con la que se ejecuta el cron es lo que normalmente provoca que los usuarios familiarizados con Drupal piensen en el Mínimo de permanencia en caché como "Mis páginas serán regeneradas después de que este tiempo haya pasado". También es una fuente de frustración para los usuarios que desean mantener el contenido en caché hasta que el contenido esté editado.
Entendiendo el comportamiento de la caché de Drupal, su interacción con los servidores proxy como Varnish y como su motor de almacenamiento de caché reacciona en varias situaciones es todo lo crítico para asegurar que su contenido esta regenerado cuando es necesario y apropiadamente cacheado cuando no.
Tema: