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.