El momento crucial para la base de datos en una implementación de un administrador de contenidos (CMS) es al momento de servir los contenidos dinámicamente. En este punto, dos mecanismos actúan en OpenCMS para minimizar la carga de la base de datos:

1. OCEE Accelerator: posee en cache los elementos más utilizados del sistema de archivos virtual (VFS) para evitar sucesivas consultas a la base de datos.
2. Flexcache: contiene las principales páginas (JSP) y sus variantes a entregar a los navegantes.

Aún con estos elementos en acción, al momento de reconstituir la Flexcache luego de una publicación, habrá un uso intensivo de la base de datos y hay que lograr que la respuesta de la misma sea eficiente. De lo contrario, vamos a tener navegantes esperando que la Flexcache se genere para luego recibir el contenido.

El proceso de ‘tuning’ de MYSQL requiere de un monitoreo continuo y un previo análisis del entorno y aplicativo sobre el cual se está trabajando para obtener los mejores resultados. Espero que estos elementos sirvan de punto de partida para una mejor comprensión del tema.

A continuación, algunas recomendaciones básicas para mejorar el rendimiento del motor de base de datos MYSQL.

ELECCIÓN DEL FORMATO DE TABLA: MYISAM / INNODB

El formato de tabla dependerá mayormente del tipo de datos a almacenar y las consultas que vamos a realizar en ellos. Para el caso particular del modelo de datos de OpenCMS, INNODB es la opción que ha demostrado mejores resultados a nivel de rendimiento en función de nuestra experiencia.

La característica principal de INNODB es que soporta transacciones de tipo ACID y bloqueo de registros e integridad referencial.

INDICES DE LA BASE DE DATOS

A lo largo de diferentes proyectos utilizan tecnología OpenCMS hemos detectado que la instalación por defecto deja lugar para mejores con relación a los índices. A partir de un buen conocimiento del modelo de datos de OpenCMS pueden crearse índices adicionales para mejorar el rendimiento de la base de datos.

TAMAÑO DEL BUFFER

La lectura del contenido de una base de datos EN MEMORIA es ampliamente superior a la lectura del contenido de una base de datos en DISCO. En la medida que podamos tener la mayor porción posible de base de datos en la memoria de nuestro equipo, mejor será el tiempo de respuesta.

Para lograr esto, debemos prestar especial atención KEY_BUFFER_SIZE para el caso de tablas MYISAM e INNODB_BUFFER_SIZE para INNODB. La memoria total que podemos asignar al buffer está alrededor del 70% al 80% de la memoria total del equipo en el caso de servidores de base de datos dedicados.

CACHE DE CONSULTAS (QUERY CACHE)

MYSQL utiliza un cache que almacena el texto de una consulta SELECT junto con el resultado. En el caso de recibir una consulta idéntica posteriormente, el servidor devuelve el resultado desde la caché de consultas en lugar de parsear y ejecutar la consulta nuevamente.

Lo recomendable es comenzar con un QUERY CACHE de tamaño por defecto (16mb) e ir subiendo el tamaño del mismo a medida que la efectividad del cache sube y la cantidad de bloques disponibles baja.

CACHE DE CONEXIONES (THREAD)

Cada conexión que realizan los servidores Web a la base de datos implica la creación de un nuevo ‘thread’. En vez de terminar el hilo una vez cerrada la conexión, el hilo puede mantenerse en el servidor para ser utilizado por la próxima conexión y hacer el proceso más eficiente. Esto es configurable a partir del THREAD_CACHE_SIZE

TABLAS ABIERTAS / TEMPORALES

Por cada tabla que tenemos en MYSQL podemos pensar en un equivalente a un archivo abierto. La cantidad de tablas abiertas están afectadas por los valores TABLE_CACHE, MAX_CONNECTIONS y MAX_TMP_TABLES.

Una configuración inadecuada de estas variables puede llevar a superior límites impuestos por el sistema operativo generando una importante degradación del rendimiento.

Respecto de las tablas temporales, es importante monitorear el estado de la cantidad de tablas temporales generadas en DISCO y tratar de modificar la configuración o el formato de las mismas para lograr que esas tablas sean persistidas en memoria.

LIMPIEZA DE TABLAS HISTÓRICA

Por cada publicación realizada en OpenCMS se guarda un registro de la operación en la tabla del historial. Con el tiempo, esta tabla puede crecer considerablemente afectando nuestra habilidad para resguardo la base y haciendo que el tamaño de la misma afecte negativamente a los componentes de CACHE. Por lo tanto, es recomendable realizar una depuración de CMS_PUBLISH_HISTORY de acuerdo a procedimientos probados y seguros.