Caché

Un caché es una colección de datos procesados que se mantiene a mano y se reutiliza para evitar costosas consultas repetidas en la base de datos. Totara 2.4 vio la implementación de MUC, la caché universal de Moodle. Este nuevo sistema permite que ciertas funciones de Totara (p. ej., búsqueda de cadenas) aprovechen los diferentes servicios de caché instalados (p. ej., archivos, ram, Memcached).

En futuras versiones de Totara, continuaremos expandiendo el número de funciones de Totara que utilizan MUC, lo que continuará mejorando el rendimiento, pero ya puedes comenzar a usarla para mejorar tu sitio.

Es posible que también desees consultar nuestra documentación de caché para desarrolladores para obtener asesoramiento sobre cómo optimizar el rendimiento con el almacenamiento en caché. 

Un enfoque general para las pruebas de rendimiento

Esta es la estrategia general que deberías seguir:

1. Crea un entorno de prueba que esté lo más cerca posible de tu instancia de producción real (p. ej., hardware, software, redes, etc.).
2. Asegúrate de eliminar tantas variables no controladas como puedas de este entorno (p. ej., otros servicios).
3. Utiliza una herramienta para colocar una carga realista, pero simulada y repetible en tu servidor (p. ej., jmeter o selenio).
4. Decida una forma de medir el rendimiento del servidor capturando datos (ram, carga, tiempo tomado, etc.).
5. Ejecuta tu carga y mide un resultado de rendimiento de referencia.
6. Cambia una variable a la vez y vuelve a ejecutar la carga para ver si el rendimiento mejora o empeora. Repita según sea necesario.
7. Cuando descubras ajustes que den como resultado una mejora constante del rendimiento, aplícalas a tu sitio de producción.

Configuración de caché en Totara

Desde Totara 2.4, Totara ha proporcionado un marco de plugin de caché para dar a los administradores la capacidad de controlar dónde Totara almacena los datos en caché. Para la mayoría de los sitios de Totara, la configuración predeterminada debe ser suficiente y no es necesario cambiar la configuración. Para sitios más grandes de Totara con múltiples servidores, los administradores pueden utilizar Memcached, MongoDB u otros sistemas para almacenar datos de caché. La pantalla del plugin de caché proporciona a los administradores la capacidad de configurar qué datos de caché se almacenan en dónde.

El almacenamiento en caché en Totara está controlado por lo que se conoce como caché universal Moodle, comúnmente conocido como MUC.

Este documento explica brevemente lo que es MUC antes de continuar con los detalles sobre los conceptos y las opciones de configuración que ofrece.

Conceptos básicos de caché en Totara

El almacenamiento en caché en Totara no es tan complejo como aparece por primera vez. Un poco de conocimiento de fondo ayudará mucho a comprender cómo funciona la configuración de caché.

Tipos de caché

Hay tres tipos básicos (a veces denominados modos) de cachés en Totara. Estos son:

Tipos de caché y sistemas de múltiples servidores

Si tienes un sistema con múltiples servidores web de interfaz de usuario, la caché de la aplicación debe ser compartida entre los servidores. En otras palabras, no puedes usar el almacenamiento local rápido para la caché de la aplicación, pero debes usar el almacenamiento compartido o alguna otra forma de caché compartida, como un Memcache compartido.

Lo mismo se aplica a la caché de sesiones a menos que utilices un mecanismo de sesiones adhesivas para garantizar que, dentro de una sesión, los usuarios siempre accedan al mismo servidor front-end.

Finales de caché

Los backends de caché son donde los datos realmente se almacenan. Estos incluyen elementos como el sistema de archivos, la sesión PHP, Memcached y la memoria.

Por defecto, solo el sistema de archivos, la sesión PHP y la memoria se utilizan dentro de Totara.

No se requiere que un sitio tenga acceso a ningún otro sistema como Memcached. En cambio, es algo que eres responsable de instalar y configurarte a ti mismo. 

Cuando se mencionen back-ends de caché, piense en sistemas fuera de Totara que puedan usarse para almacenar datos, como el servidor MongoDB, el servidor Memcache y aplicaciones de servidor similares.

Almacenes de caché

Los almacenes de caché son un tipo de plugin dentro de Totara. Facilitan la conexión de Totara a los back-ends de caché analizados anteriormente.

Totara envía con los tres valores predeterminados mencionados anteriormente, así como Memcache, Memcached y MongoDB.

El código de estos se encuentra dentro de la memoria caché/tiendas en tu raíz del directorio de Totara.

Dentro de Totara, puedes configurar tantos almacenes de caché como tu arquitectura requiera. Por ejemplo, si tienes varios servidores Memcache, puedes crear una instancia de almacenamiento en caché para cada uno.

Totara por defecto contiene tres instancias de almacenamiento en caché que se utilizan cuando no se ha realizado ninguna otra configuración.

• Se crea una instancia de almacenamiento de archivos que se utiliza para todas las cachés de aplicaciones (los datos se almacenan en el directorio de datos del sitio)
• Se crea una instancia de almacenamiento de sesión que se utiliza para todas las cachés de sesión (los datos se almacenan en la sesión PHP, que por defecto se almacena en su base de datos)
• Se crea una instancia de almacenamiento de memoria estática que se utiliza para todos los tipos de caché de solicitudes (los datos existen en la memoria solo durante la vida útil de una solicitud)

Cómo funcionan las cachés en el código

Las cachés se crean en código y son utilizadas por el desarrollador para almacenar datos que ven la necesidad de almacenar en caché. 

El desarrollador no obtiene ninguna opinión sobre dónde se almacenan los datos en caché. Deben especificar la siguiente información al crear una caché para usar.

• El tipo de caché que requieren
• El área de código a la que pertenecerá esta caché (la API si la deseas)
• El nombre de la caché, algo que componen para describir en una palabra lo que la caché almacena

Hay varios requisitos y configuraciones opcionales que también pueden especificar. Sin embargo, lo más importante es que no pueden elegir qué backend de caché usar, solo pueden elegir el tipo de caché que desean entre los tres detallados anteriormente.

Cómo se une

Esto se describe mejor en relación con los roles desempeñados en una organización.

• El administrador del sistema instala los back-ends de caché que desea utilizar. Memcache, XCache, APC, etc. Totara no sabe sobre esto, están fuera del alcance de Totara y son puramente responsabilidad de su administrador de sistema.
• El administrador del sitio de Totara crea una instancia de almacenamiento en caché en Totara para cada back-end que utilizará el sitio. Puede haber una o más instancias de almacenamiento en caché para cada back-end. Algunos backends como Memcached tienen ajustes para crear espacios separados dentro de un backend.
• El desarrollador ha creado cachés en código y las está usando para almacenar datos. No saben nada sobre cómo usarás tus cachés, solo crean una caché y le dicen a Totara qué tipo es mejor para ello.
• El administrador del sitio de Totara crea una asignación entre una instancia de almacenamiento en caché y una caché. Esa asignación le indica a Totara que use el back-end que especifica para almacenar los datos que el desarrollador desea almacenar en caché.

Además de eso, puedes seguir avanzando.

• Puedes asignar muchas cachés a una sola instancia de almacenamiento en caché
• Puedes asignar varias instancias de almacenamiento en caché a una única caché con prioridad (principal ... final)
• Puedes asignar una instancia de almacenamiento en caché para que sea el almacenamiento por defecto utilizado para todas las cachés de un tipo específico que de otro modo no tienen asignaciones específicas

Si esta es la primera vez que lees sobre la MUC, esto probablemente suene bastante complejo, pero no te preocupes, se analizará con más detalle a medida que trabajemos en cómo configurar el almacenamiento en caché en Totara.

Conceptos avanzados

Estos conceptos son cosas que la mayoría de los sitios no necesitarán saber ni preocuparse por sí mismos.

Solo debes comenzar a buscar aquí si buscas maximizar el rendimiento en sitios grandes que se ejecutan sobre servicios clúster con back-ends de caché compartidos o en arquitecturas multisitio de nuevo donde la información se comparte entre sitios.

Bloqueando

La idea del bloqueo no es nada nuevo, es el proceso de controlar el acceso para evitar problemas de concurrencia.

MUC tiene un segundo tipo de plugin, un plugin de bloqueo de caché que se utiliza cuando las cachés lo requieren. Hasta la fecha, no se han requerido cachés. Una caché por naturaleza es volátil y cualquier información que sea absolutamente crítica para la misión debería ser un almacenamiento de datos más permanente, probablemente la base de datos.

Sin embargo, hay un sistema de bloqueo que las definiciones de caché pueden requerir dentro de sus opciones y que se aplicará cuando se interactúe con una instancia de almacenamiento en caché.

Compartiendo

Cada bit de datos que se almacena dentro de una caché tiene una clave única calculada asociada a ella.

Por defecto, parte de esa clave es el identificador del sitio que hace que cualquier contenido almacenado en la caché sea específico del sitio que lo almacenó. Para la mayoría de los sitios, esto es exactamente lo que quieres.

Sin embargo, en algunas situaciones, es beneficioso permitir que múltiples sitios, o de alguna manera sitios vinculados, compartan datos en caché.

Por supuesto, no todas las cachés se pueden compartir; sin embargo, algunas ciertamente lo pueden hacer y al compartir, puedes reducir aún más la carga y aumentar el rendimiento al maximizar el uso de recursos.

Esta es una característica avanzada; si eliges configurar el uso compartido, hazlo con cuidado.

Para hacer uso del uso compartido, primero debes configurar instancias idénticas de almacenamiento en caché en los sitios en los que deseas compartir información y, luego, en cada sitio, establecer el uso compartido para la caché en el mismo valor.

Las opciones de configuración disponibles son las siguientes:

• Sitios con el mismo ID de sitio: este es el valor por defecto, permite que los sitios con el mismo ID de sitio compartan información en caché. Es el más restrictivo, pero funcionará para todas las cachés. Todas las demás opciones conllevan un elemento de riesgo, ya que debes asegurarte de que la información en la caché sea aplicable a todos los sitios que tendrán acceso a ella.
• Sitios que funcionan con la misma versión. Todos los sitios que acceden al back-end que tienen la misma versión de Totara pueden compartir la información que esta caché ha almacenado en el almacén de caché.
• Clave personalizada Para esto, ingresa manualmente una clave para compartir. Luego, debes ingresar exactamente la misma clave en los otros sitios en los que deseas compartir información.
• Todos. Los datos almacenados en caché son accesibles para todos los demás sitios que acceden a los datos. Esta opción pone la pelota completamente en el tribunal del administrador de Totara.

Por ejemplo, si tuvieras varios sitios de Totara en la misma versión que se ejecutaban en un servidor con APC instalado, podrías decidir asignar el caché de idioma al almacén de APC y configurar el uso compartido para todos los sitios que ejecutan la misma versión.

El caché de idiomas para los sitios en la misma versión es seguro para compartir en muchas situaciones, se utiliza en prácticamente todas las páginas y APC es extremadamente rápido. Estos tres puntos pueden resultar en un pequeño aumento del rendimiento para tus sitios.

Es importante considerar con el caché de idiomas que al compartirlo entre sitios, también se compartirán las personalizaciones de idiomas.

Ajustes de configuración

La configuración de caché proporciona enlaces a todas las acciones que puede realizar para configurar el almacenamiento en caché para los requisitos de su sitio.

Acceso a la pantalla de configuración de caché

Solo los usuarios con la capacidad site:config pueden acceder a la pantalla de configuración de caché. Por defecto, esto es solo para administradores.

Una vez iniciada la sesión, la pantalla de configuración se puede encontrar en el menú de acceso rápido > Plugins > Caching > Configuration.

Almacenes de caché instalados

Esto te muestra una lista de plugins de almacenamiento en caché que has instalado.

Para cada plugin, puedes ver rápidamente si está listo para ser utilizado (se han cumplido todos los requisitos de PHP), cuántas instancias de almacén ya existen en este sitio, los tipos de caché para los que se puede utilizar este almacén, qué funciones admite (avanzado) y cualquier acción que puedas realizar en relación con este almacén.

 La caché de sesión y la caché de solicitud estática no admiten tener varias instancias.

Aquí obtendrás una lista de las instancias de almacenamiento en caché en este sitio.

Definiciones de caché conocidas

La idea de una definición de caché aún no se ha analizado aquí. Es algo controlado por el desarrollador. Cuando crean una caché, pueden hacerlo de dos maneras, la primera es creando una definición de caché.

Esto es esencialmente contarle a Totara sobre el caché que han creado. La segunda forma es crear una caché ad hoc. Siempre se alienta a los desarrolladores a utilizar el primer método. Solo las cachés con una definición pueden ser mapeadas y configuradas adicionalmente por el administrador. Las cachés ad hoc solo utilizarán la configuración predeterminada. 

Por lo general, las cachés Adhoc solo se permiten en situaciones en las que la caché es pequeña y configurarla más allá de los valores por defecto no proporcionaría ningún beneficio a los administradores.

Para cada caché que se muestra aquí, obtienes la siguiente información:

También encontrarás en la parte inferior de esta tabla un enlace titulado Reescanear definiciones. Hacer clic en este enlace hará que Totara se apague y verifique todos los componentes principales y los plugins instalados que buscan cambios en las definiciones de caché.

Esto sucede de forma predeterminada durante una actualización y si se encuentra una nueva definición de caché. Sin embargo, si buscas un caché que no está allí, puede valer la pena intentarlo.

También es útil para los desarrolladores, ya que les permite aplicar cambios rápidamente cuando trabajan con cachés. Es útil cuando se ajustan las definiciones de caché para encontrar lo que funciona mejor.

Resumen de instancias de bloqueos de caché.

Como se mencionó anteriormente, el bloqueo de caché es un concepto avanzado en MUC.

La tabla aquí muestra la información sobre los mecanismos de bloqueo configurados disponibles para MUC. Por defecto, solo hay un mecanismo de bloqueo disponible, el bloqueo de archivos. Actualmente, no hay cachés que hagan uso de esto. 

Almacenes usados cuando no hay mapeo presente

Esta tabla muestra rápidamente qué instancias de almacenamiento en caché se utilizarán para los tipos de caché si no hay asignaciones específicas implementadas.

Para simplificar esto, esto muestra los almacenes de caché por defecto para cada tipo.

En la parte inferior, verás que hay un enlace Editar asignaciones que te lleva a una página donde puedes configurar esto.

Caché de archivos

Al crear una caché de archivo, de hecho, solo hay un parámetro requerido: el nombre de la tienda. El nombre del almacén se utiliza para identificar la instancia del almacén de archivos en la interfaz de configuración y debe ser único para el sitio. Puede ser cualquier cosa que desees, pero te recomendamos que lo hagas algo que describa tu uso previsto del almacén de archivos.

Se pueden especificar las siguientes propiedades, personalizando dónde se ubicará la caché de archivos y cómo funciona.

El almacenamiento de caché de archivos es el almacenamiento por defecto utilizado para cachés de aplicaciones y, por defecto, el directorio de datos del sitio se utiliza para la caché. El acceso a los archivos puede ser un recurso gravador en tiempos de mayor carga y las siguientes son algunas ideas sobre la configuración de almacenes de archivos alternativos para mejorar el rendimiento.

• Comprueba si hay un sistema de archivos más rápido disponible para usar en tu servidor. Quizás tengas una SSD instalada, pero no la estás usando para el directorio de datos de tu sitio porque el espacio es una ventaja. Deberías considerar crear un directorio o una partición pequeña en tu SSD y crear un almacén de archivos para usarlo en lugar de tu directorio de datos de Totara.
    
• Si no tienes un disco más rápido disponible para usar, tienes mucho espacio libre. Algo que puede valer la pena hacer una toma sería crear una pequeña partición en la unidad que has instalado que utiliza un sistema de archivos orientado al rendimiento. Muchas instalaciones de Linux en estos días, por ejemplo, usan EXT4, un sistema de archivos agradable pero que tiene gastos generales debido a los tipos de registro.
    
• Crear una partición y usar un sistema de archivos que ha sido optimizado para el rendimiento puede darte ese pequeño impulso que estás buscando. Recuerda que las cachés están diseñadas para ser volátiles y elegir un sistema de archivos para una caché es una decisión diferente de elegir un sistema de archivos para tu servidor.
    
• Por último, si estás listo para ir a largos y tienes una gran cantidad de memoria en tu servidor, podrías considerar la posibilidad de crear un ramdisk/tmpfs y señalar un almacén de archivos. Puramente basado en la memoria, es volátil exactamente como lo es la caché, y el rendimiento del sistema de archivos no va a ser mucho mejor que esto.

Lo que sea que elijas, recuerda probarlo repetidamente. Asegúrate de tomar la decisión.

Memcached

Antes de poder agregar una instancia de Memcache Store, primero debe tener un servidor Memcached al que pueda acceder y tener la extensión Memcache PHP instalada y habilitada en su servidor web.

Al igual que el almacén de archivos, debes proporcionar el nombre del almacén. Se utiliza para identificar la instancia de almacenamiento en la interfaz de configuración y debe ser única para el sitio.

Para una tienda Memcache, también debes ingresar el servidor Memcache o los servidores de los que deseas que se utilice. Los servidores deben añadirse uno por línea y cada línea puede contener de una a tres propiedades separadas por dos puntos.

• La URL o la dirección IP del servidor (obligatorio).
• El puerto en el que el servidor está escuchando (opcional).
• El peso para dar a este servidor (opcional).

Por ejemplo, si tenía dos instancias Memcached ejecutándose en su servidor, una configurada para el puerto predeterminado y otra configurada para 11212, usaría lo siguiente:

127.0.0.1

127.0.0.1:11212

Opcionalmente, también puedes especificar un prefijo clave para usar. Lo que ingreses aquí tendrá el prefijo de todas las claves antes de acceder al servidor y se puede usar para particionar eficazmente el espacio Memcache de una manera reconocible. Esto puede ser útil si tienes una herramienta de gestión para tu servidor Memcached que usas para inspeccionar lo que está almacenado allí.

Memcached

Al igual que la tienda Memcache, primero debe tener un servidor Memcached al que pueda acceder y tener la extensión PHP Memcached instalada y habilitada en su servidor.

Además, al igual que la tienda Memcache, hay dos parámetros requeridos para configurar una tienda Memcached, el nombre de la tienda y el servidor. También hay varios parámetros opcionales que puedes configurar al crear una tienda Memcached.

127.0.0.1

127.0.0.1:11212

MongoDB

MongoDB es una base de datos NoSQL orientada a documentos de código abierto. Consulta su sitio web www.mongodb.org para obtener más información.

Redis

Redis es un almacén de estructura de datos en memoria de código abierto que se puede utilizar para almacenar en caché o como base de datos. Puedes encontrar más información en el sitio web de Redis. 

Uso del serializador igbinario 

El serializador igbinario almacena estructuras de datos en forma binaria compacta y los ahorros pueden ser significativos para almacenar datos serializados.

El serializador igbinario no es parte de una distribución PHP estándar, pero se puede instalar opcionalmente. Puedes obtenerlo desde GitHub o PECL.

Almacenamiento en caché Redis

Cuando se instala igbinary, puedes elegir el serializador al configurar el almacén de caché de Redis. Se predetermina al serializador PHP estándar, pero se puede cambiar a igbinario.

Almacenamiento de caché estático

El almacén de caché estático utiliza automáticamente el serializador igbinario cuando está instalado. No hay una opción de configuración o ajuste para activarla o desactivarla.

Controlador de sesión Redis

Si igbinary está instalado y $CFG->session_redis_serializer_use_igbinary está configurado como verdadero, el controlador de sesión Redis utiliza igbinary para serializar los datos.

Instancias de tienda única frente a múltiples

Si se asigna una instancia de almacén única a la caché, ocurre lo siguiente:

• Al obtener datos de la caché, Totara le pide a la caché que obtenga los datos. 
• El caché intenta obtenerlo de la tienda. 
• Si la tienda lo tiene, se lo entrega a la caché, y la caché se lo entrega a Totara para que pueda usar los datos. 
• Si la tienda no tiene un error, Totara tendrá que generar los datos y lo más probable es que los envíe a la caché.
• Al almacenar datos en la memoria caché, Totara le pedirá a la memoria caché que almacene algunos datos, y la memoria caché se los entregará a la memoria caché.

Si se asignan varias instancias de almacenamiento a la caché, ocurre lo siguiente:

• Obtener datos de un almacén Totara le pide a la caché que obtenga los datos.
• El caché intenta obtenerlo de la primera tienda. 
• Si la primera tienda lo tiene, devuelve los datos a la caché y la caché lo devuelve a Totara. 
• Si la primera tienda no tiene los datos, intenta obtener los datos de la segunda tienda. 
• Si la segunda tienda la tiene, la devuelve a la primera tienda que la almacena antes de devolverla a la caché. 
• Si no es así, se utiliza la siguiente tienda. 
• Esto continúa hasta que se encuentren los datos o hasta que no haya más almacenes para verificar.
• Al almacenar datos en la caché, Totara le pedirá a la caché que almacene algunos datos, la caché los entregará a cada almacén de caché asignado para su almacenamiento.

La principal ventaja de asignar múltiples almacenes es que puedes introducir redundancia de caché. Por supuesto, esto introduce una sobrecarga, por lo que solo debe usarse cuando realmente se requiera. El siguiente es un ejemplo de cuando el mapeo de múltiples tiendas puede proporcionar una ventaja.

Escenarios

Problema: Tienes un servidor web que tiene un sitio de Totara y otros sitios. También tienes un servidor Memcache que es utilizado por varios sitios, incluido Totara. Memcache tiene un tamaño de caché limitado, que cuando está lleno y se le solicita que almacene más información libera espacio al eliminar las entradas de caché menos utilizadas. Quieres usar Memcache para tu sitio de Totara porque es rápido; sin embargo, sabes que puede introducir más errores de caché porque es un servidor Memcache muy utilizado.

Solución: para desplazarte por esto, asignas dos tiendas a las cachés que deseas usar Memcache. Tú conviertes a Memcache en el almacén principal y conviertes al almacén de archivos por defecto en el almacén de caché final.

Explicación: Al hacer esto, has creado redundancia cuando se solicita algo. Totara primero intenta obtenerla de Memcache (la tienda más rápida) y si no está allí, procede a verificar la caché de archivos.

Solo un par de puntos de interés más:

• Si se asignan varias cachés, se introducirán más cachés; mientras más cachés se asignen, más sobrecargas habrá.
• Considera los almacenes de caché a los que estás mapeando, si los datos permanecen allí una vez establecidos, no hay ningún otro almacén de mapa de puntos después de él. Esta técnica es principalmente valiosa en situaciones en las que no se garantiza que los datos permanezcan después de ser establecidos.
• Siempre pruebe su configuración. Habilita la visualización de la información de rendimiento y luego observa qué tiendas se utilizan al interactuar con Totara de manera tal que se active la caché.