El presente artículo busca presentar a administradores y usuarios una serie de consideraciones a tener en cuenta al momento de utilizar OpenCMS en sitios de alto tráfico.

Este artículo aplica a situaciones donde la instalación de OpenCMS utiliza las extensiones corporativas de Alkacon OCEE con el módulo de Cluster activo con al menos 2 nodos.

1. Arquitectura

OpenCMS nos permite elegir entre diferentes arquitecturas posibles:

1. OCEE Módulo Cluster con base de datos única para Workplace y nodos

2. OCEE Módulo Cluster con base de datos local en cada nodo

3. OCEE Módulo Cluster + OCEE Replicator

4. OCEE Módulo de Cluster con 1 base de datos dedicada para Workplace y 1 base de datos dedicada para nodos (replicación MySQL)

La elección de la arquitectura es sin lugar a dudas uno de los factores de éxito clave. En otro artículo especialmente dedicado a este tema, detallaremos los pros y contras de cada escenario.

2. Modalidad para servir contenido

La forma mediante la cual OpenCMS entrega el contenido a los navegantes define una serie de factores a revisar según el escenario. En el artículo Opencms: Servidor contenido de forma estática, dinámica o mixta exploramos este tema.

3. Conectividad del Workplace

En situaciones de alto tráfico, los accesos de los navegantes pueden saturar los enlaces. Por tal motivo, es muy importante contar con un acceso dedicado al Workplace que nos permita tener acceso a las herramientas de administración.

Es altamente recomendable que los usuarios del sistema no compitan por el ancho de banda con los navegantes y que el Workplace no esté sirviendo páginas a navegantes.

Desde el punto de vista de seguridad, es ideal que el Workplace no se encuentre publicado en Internet.

4. Balanceo de Carga

Los módulos de OpenCMS poseen requerimientos especiales respecto del balanceo de carga. Es importante que el balanceador utilice sesiones persistentes (también llamadas sticky sessions). De esta forma, cuando un usuario está navegando el sitio, quedará asociado a un nodo en particular por el lapso de su sesión.

De otra forma, si un usuario recibiese páginas de diferentes miembros del cluster,  todos aquellos módulos que hacen uso del ingreso (login) del usuario pueden funcionar de forma anormal.

5. Frecuencia de Publicación

La publicación continua del contenido es el peor enemigo del alto tráfico. Cada vez que un usuario publica un nuevo contenido, los sistemas de cache deben regenerarse total o parcialmente, con la consecuente perdida de performance.

Cuando un sistema de administración de contenidos recibe publicaciones continuas, la efectividad de estos sistemas se reduce drásticamente. Esto aplica a cualquier publicación, ya sea modificación de contenidos existentes o la incorporación de nuevos contenidos al proyecto online.

Como buena práctica, es recomendable publicar contenidos a intervalos de 5 minutos o más.

6. Prepararse para la crisis

Existen 2 cuestiones esenciales que nos van a permitir administrar correctamente una crisis de tráfico:

TEMPLATES DE EMERGENCIA: tener un juego de templates alternativos para las páginas más visitadas que sean muy livianos. Es importante que estos templates sean lo más simple posibles, quitando todos los elementos gráficos que no sean indispensables.

DESHABILITAR FUNCIONALIDAD DINÁMICA: ingresos de usuarios registrados, encuestas, búsquedas, valoración, comentarios y otras funcionalidades dinámicas implican un esfuerzo extra.

Durante una situación de crisis, un posible camino de acción es deshabilitar estos servicios para reducir la cantidad de elementos a regenerarse en el cache y evitar la mayor cantidad posible de consultas a la base de datos.

7. Monitoreo Continuo

El último punto, y no menos importante que los anteriores, es conocer su infraestructura. Tener mecanismos de monitoreo activo de servicios, enlaces y servidores como NAGIOS va a permitir detectar fallas de forma temprana y corregirlas sin mayores dificultades para los navegantes.

Por otro lado, tener estadísticas de utilización de los recursos (procesador, memoria, acceso a discos, tráfico de red) como lo ofrecido por MUNIN nos va a permitir identificar rápidamente las posibles fuentes del problema.

1. Modo Estático: habilitar la funcionalidad de ‘exportar estático’
2. Modo Dinámico: desde el servlet de OpenCms haciendo uso de Flexcache
3. Modo Mixto: combinación de ambas estrategias

Por naturaleza, el entorno de trabajo de Opencms es dinámico. Los archivos y carpetas son creados, lockeados, editados y deslockeados en el Workplace (Intranet). Sin embargo, una vez publicados los recursos, estos se vuelven estáticos. Los recursos disponibles en la Web permanecen inalterabes hasta un nuevo evento de publicación.

OpenCMS permite que cada recurso pueda ser configurado independientemente para funcionar en forma dinámica o estática según se evalúe conveniente.

Páginas en Modo Estático

En esta modalidad, la página es ‘renderizada’ a su forma final al momento de la publicación y luego es almacenada en el sistema de archivos. El contenido de las páginas se combina con el template elegido y el resultado se graba en un archivo HTML.

En el caso de contar con elementos JSP, estos se ejecutan por única vez y su resultado se ‘congela’ como HTML en el disco.

En esta modalidad de trabajo, no se corren parseos ni interpretaciones en tiempo de ejecución.

OpenCms brinda la posibilidad de configurar a nivel de recurso la exportación estática (true / false). De esta forma, podemos decirle a Opencms que al momento de entregar ese recurso lo haga de forma estática en un servidor Web determinado.

El contenido ya no es servido por el servlet HTTP de OpenCms sino que es servido por el web server creando una total independencia y desvinculación del motor de edición y publicación.

Ventajas del Modo Estático:

- Gran velocidad al servir páginas pre-generadas.

 Desventajas del Modo Estático:

- Incapacidad de trabajar con tempates JSP que requieran tomar información de contexto.

- Imposibilidad de personalizar contenido. 

Páginas en Modo Dinámico

El recurso es procesado por OpenCms en tiempo de ejecución. Al publicar se mueve la página desde el proyecto offline al proyecto online y cuando se realiza una nueva consulta a un servidor de frontera, OpenCms combina el contenido con el témplate y genera la página que le es enviada al usuario.

En este punto, los diferentes resultados posibles (variantes de cada JSP) son almacenados en la Flexcache de acuerdo a las directivas definidas por el administrador.

Ventajas del Modo Dinámico:

- Los templates con contenidos dinámicos JSP funcionan mucho mejor.

Desventajas del Modo Dinámico:

- Requiere ajustes de la configuración de Flexcache.

- Tiempo de generación del contenido del cache penaliza al primer visitante

- Requiere estricto control sobre la frecuencia de publicación  

Modalidad Mixta

A diferencia de otros Administradores de Contenidos, es natural para OpenCMS operar en un entorno mixto, donde algunos recursos son entregados de forma estática y otros de forma dinámica.

Las imágenes son normalmente definidas como estáticas para hacer uso de estrategias de CACHE a nivel del servidor web (apache mod proxy).

También es posible posible construir templates principalmente estáticos que incluyan bloques dinámicos incorporados en forma de IFRAMES. El contenido dinámico incorporado a los templates estáticos podrá ser consumido desde los propios servidores de OpenCms.

La mejor estrategia para servir contenidos dependerá mayormente de la arquitectura seleccionada, el tipo de contenido y la funcionalidad a resolver.

MYSQL se ha posicionado como una de las base de datos preferidas para los clientes que utilizan OpenCMS, incluso en situaciones de alto tráfico.  No obstante, en portales medianos a grandes, donde el efecto del OCEE Accelerator comienza a disminuir por la cantidad de contenidos generados diariamente y la frecuencia de publicación es medida en minutos, debemos implementar medidas para prevenir segundos o minutos de NO SERVICIO.

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.

A continuación, compartimos las 11 razones que nos llevaron a elegir OpenCMS para la construcción de portales de alto tráfico como www.perfil.com, www.lacapital.com.ar y www.diariouno.net.ar.

1. Comunidad / Soporte

Opencms cuenta con una importante comunidad de desarrollo, más de 120 proveedores de soluciones a nivel mundial y más de 5.000 casos de implementación en el mundo entre los cuales se encuentran: FOX Australia, Dreamworks Animation, 3M, Renault y Bayer.

Posee módulos libres y comerciales provistos por terceras partes y por el desarrollador del producto (Alkacon Software GmbH).

El soporte comercial de OpenCMS se brinda tanto por la empresa desarrolladora de la solución (Alkacon Software) como a través de su red de proveedores de soluciones.

2. Gestión de Contenido

La solución permite la utilización de múltiples tipos de contenido o definir tipos propios a través de un modelo de propiedades y atributos extensible. Los contenidos son persistidos en un sistema de archivos virtual (VFS) y pueden ser entregados a los navegantes de forma estática o dinámica. Nuestra firma ha extendido OpenCMS para incorporar soporte a tipos de contenido como: Video Flash, Audio Flash, PDF, Noticias, Carteleras, etc.

El modelo de carga es muy sencillo, pudiendo optar por múltiples editores, tipos de contenido estructurados o carga programática. La opción por defecto es un editor avanzado (FCKEditor). El editor de contenido puede ser actualizado de forma independiente al resto de la plataforma permitiendo un correcto desempeño con navegadores modernos.

OpenCMS posee soporte nativo de versionado automático, permitiendo ver un historial completo de lo ocurrido con un elemento dentro del sistema. Esto es sumamente importante en un entorno de redacción donde debe llevarse cierto nivel de control sobre la evolución de una nota. Además, posee soporte de “bloqueo” de contenido para permitir la colaboración entre diferentes usuarios (símil check-in / check-out).

3. Templates

La construcción de templates dentro de la herramienta de CMS es una de las barreras de entrada más fuertes que presentan muchas soluciones existentes en el mercado actual.

La generación de templates a medida en OpenCMS puede realizarse utilizando cualquier herramienta de diseño web HTML para su posterior integración en páginas java (JSP), las cuales pueden ser construidas tomando como base el templates nativo TEMPLATEONE.

La construcción de estos templates requiere conocimientos básicos de Java, HTML / CSS y sólidos conocimientos de JSP, XML / XSD para interactuar con funcionalidad dinámica construida por el usuario alrededor de OpenCMS.

4. Gestión de Imágenes

La solución cuenta con un módulo nativo de gestión de imágenes que permite subir archivos individuales, archivos ZIP para la carga de múltiples elementos, ajuste de tamaño automático, y estatificación configurable a nivel de elemento o carpetas. De esta forma puede servir el contenido visual haciendo uso del cache nativo del servidor Web.
Los usuarios pueden organizar sus imágenes a nivel de Galerías temáticas o por fecha.

Para aquellos casos donde la gestión de activos visuales es un requerimiento es posible realizar la integración con sistema de imágenes como CUMULUS. OpenCMS posee uno de los casos más importantes de referencia: THE ROYAL LIBRARY.

5. Rendimiento, Disponibilidad y Escalabilidad

La problemática de los sitios de alto tráfico suele estar íntimamente vinculada con la reducción del impacto en múltiples servidores Web consultando el motor de base de datos. En este punto es importante definir una estrategia para servir el contenido a los usuarios: dinámica o estático. Afortunadamente OpenCMS puede trabajar con ambas y expone mecanismos de cache diferenciados para cada caso.

OpenCMS presenta diferentes niveles de cache orientados a solucionar ese problema en forma eficiente:
1. FlexCache: realiza el cache de las diferentes JSP y sus variantes
2. OCEE Accelerator (DB): es un sistema de cache que tiene por objetivo reducir la cantidad de consultas a la base de datos (VFS).
3. Static Export (servir estáticamente) + Modproxy: realiza el cacheo del contenido que fue definido como estático a nivel del servidor Web Apache.

La FlexCache posee directivas avanzadas para la gestión de diferentes tipos de contenido. En la versión 6.x se recrea en cada publicación mientras que en versión 7.x la limpieza del cache se realiza a nivel de ítem. Por su parte el OCEE Cache de base de datos persiste a través de las múltiples publicaciones y sólo es renovado cuando el sistema se reinicia o los elementos expiran.

A diferencia de otras soluciones de CMS, la escalabilidad en OpenCMS es provista a nivel de la aplicación OpenCMS Alkacon OCEE Cluster que permite tener un servidor designado como Workplace (Intranet) y múltiples servidores de frontera encargados de servir el contenido a los navegantes. Este modelo posibilita una escalabilidad ilimitada y alta disponibilidad a través de diferentes esquemas de implementación que detallaremos en otro artículo.
A nivel de base de datos OpenCMS ofrece las opciones de mercado más reconocidas: MySQL, Microsoft SQL Server, PostgreSQL y Oracle.

6. Seguridad

Los aspectos centrales de la seguridad son:
1. Proteger el acceso a los contenidos en preparación (externo)
2. Administrar eficientemente el acceso de usuarios (interno)

A nivel externo, el servidor de Workplace (también llamado Intranet de publicación) puede existir sin necesidad de estar publicado en Internet. Es recomendable además que este equipo disponga de conectividad independiente (entre el servidor y los usuarios que acceden a él) para no competir por ancho de banda con los servidores públicos retrasando la publicación de nuevo contenido en situaciones de picos de alto tráfico.

A nivel interno, la seguridad se basa en modelo por listas de acceso (ACL) en el Virtual File System a nivel de elemento. Asimismo se brinda soporte para la gestión de soporte para grupos, roles y usuarios. OpenCMS posee una extensión comercial OCEE LDAP para la integración con Servicios de Directorio.

OpenCMS permite además tener un alto nivel de auditoría sobre las acciones de los usuarios en el sistema mediante un “historial de proyecto’”a nivel de recurso.

7. Localización

OpenCMS tiene soporte multi-idioma. Ofrece de forma nativa las localizaciones para inglés y alemán. La comunidad ha desarrollado localizaciones para español e italiano.

8. Motor de Búsquedas

La solución integra el producto Lucene Search Engine. A partir de una extensión de OpenCMS, nuestra firma brinda soporte de búsquedas avanzadas. Permite también la construcción de múltiples fuentes de indexación permitiendo tener un modelo de búsqueda especializado por cada índice.

Los índices de búsqueda pueden asociarse con tipos de contenido, recursos y proyectos. La indexación se realiza por atributos de los elementos como por ejemplo título, palabra clave, meta tag, categorías, fecha de creación, fecha de publicación, edición, tipo de publicación, etc.

9. Funcionalidad Interactiva

La funcionalidad interactiva puede ser construida fácilmente como contenido estructurado o como módulo que extienden a OpenCMS. Actualmente, se encuentran disponibles módulos para:

• Registración y Autenticación de Usuarios Web
• Valoración de Contenido
• Comentarios y Reporte de Abuso
• Suscripción y Administración de Newsletter
• Opiniones (símil Foro)
• Recomendación de contenido
• Múltiples tipos de Rankings para los navegantes
• RSS para sindicar contenido
• Gestor de Encuestas
• Etc (http://www.tfsla.com/productos_opencms_modulos.php)

10. API de Integración y Extensión

OpenCMS expone abiertamente todo su código (excluyendo las extensiones comerciales) permitiendo a los usuarios tener una versión personalizada del CMS y extender el mismo. El acceso a la funcionalidad básica puede realizarse a través de la Core Build API.

El conocimiento disponible sobre el desarrollo se encuentra muy bien documentado y disponible en www.opencms.org, Online Javadoc y el repositorio CVS.

11. Separación de Entornos

La separación tradicional de entornos incluye desarrollo, pruebas y producción. En OpenCMS es posible alcanzar esta separación de diferentes formas:

La primera, consiste en tener un servidor de desarrollo con las extensiones OCEE instaladas en modo desarrollo lo cual nos permite trabajar en un entorno prácticamente idéntico al productivo. Una vez terminado el desarrollo, el módulo completo puede ser exportado e importado en el nuevo servidor.

La segunda forma implica la utilización del OCEE Replicator para enviar la información del servidor de desarrollo al servidor de producción de forma automática.

La tercera forma, aunque la menos recomendada pero apta para situaciones particulares, considera el despliegue de OpenCMS en diferentes servidores (N) y el consumo de 2 o más bases de datos. A idéntico sistema de archivos de los servidores, la única diferencia posible es el contenido del sistema de archivos virtual (VFS). El VFS vive dentro de una base de datos que puede replicarse de forma manual o automática y lograr que otro servidor, consumiendo esta base “esclava”, obtenga la misma funcionalidad que la primera.