Cumplimiento normativo

Histórico de cambios

Los cambios en la normativa vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución.

Introducción

La normativa que a continuación se detalla muestra la metodología a seguir para llevar a cabo las pruebas de carga del sistema sobre los diferentes aplicativos basados en la arquitectura de referencia publicada en UNIFICA en relación a tecnología Oracle Weblogic y Oracle Database.

En la metodología se muestra el flujo genérico que se debe seguir para planificar y ejecutar correctamente las pruebas de carga del sistema desde el inicio del desarrollo hasta su validación.

De esta forma, se indican el conjunto de pruebas fundamentales necesarias para garantizar el correcto funcionamiento y rendimiento previo a la entrada a producción de una nueva aplicación, así como una evolución de un producto existente que se haya podido ver afectado el rendimiento del sistema. Consta de los siguientes elementos:

1. Prerrequisitos: Los elementos y herramientas necesarias para poder implementar las pruebas.
2. Pruebas de comunicación: Comprobación del entorno objetivo para las pruebas por parte del lanzador.
3. Línea base: Establecimiento del conjunto inicial de datos necesario para la restauración del punto inicial en cada prueba.
4. Pruebas de capacidad: Determinan los parámetros de concurrencia para el resto de las pruebas.
5. Pruebas de rendimiento: Determinan el correcto funcionamiento del aplicativo con la carga en los distintos niveles de concurrencia definidos.
6. Pruebas de estrés: Se ejecuta la prueba con concurrencia incremental hasta el punto de saturación del aplicativo o aplicativos con respecto al entorno objetivo. Se mide también la recuperación del sistema.
7. Pruebas sostenidas: Comprueba el correcto funcionamiento y la ausencia de degradación del aplicativo durante un período de tiempo prolongado.
8. Pruebas sostenidas con tolerancia a fallos: Comprueba el impacto sobre el funcionamiento del aplicativo o aplicativos con operativas sobre determinados componentes del entorno: caída de una instancia de base de datos, caída de una instancia de Weblogic, etc.
9. Conclusiones: Conjunto de conclusiones obtenidas a partir de los resultados e interpretaciones de las pruebas realizadas.

Esta normativa se limita exclusivamente al proceso a seguir para la ejecución de pruebas de carga del sistema, no siendo responsabilidad de esta normativa el resto de flujos que intervienen en el proceso de creación de un nuevo software. Su propósito por tanto es que sirva de guía para el usuario que se encarga de gestionar o ejecutar las pruebas de carga del sistema, existiendo un documento adicional que hará de plantilla, siendo dicha plantilla el documento que realmente deberá entregar a la STIC los proveedores de los aplicativos con los resultados de las pruebas obtenidas

Actores

A continuación, se indican los actores partícipes en la metodología y su etiqueta que determina el liderazgo en cada proceso de la metodología:

Flujo de trabajo

Es importante tener muy en cuenta las pruebas de carga de nuestros sistemas de información desde una fase temprana del desarrollo, estando seguros de los requisitos de rendimiento necesarios para la aceptación del producto por parte del SAS, y reservando el espacio de tiempo oportuno para poder llevar a cabo correctamente el conjunto de pruebas del sistema.

La responsabilidad de la coordinación del proceso de pruebas será labor de la OCA actuando como intermediario entre el proveedor de desarrollo, Sistemas y las diferentes áreas técnicas y de gestión de la STIC. 

En el siguiente diagrama se puede ver una foto global del procedimiento a seguir para la planificación y ejecución de pruebas de sistemas sobre un sistema de información:

Las actividades descritas en este flujo son:

• Nuevo desarrollo: Es el disparador del proceso, se refiere al momento, al inicio de un desarrollo, en el que surge la necesidad de realizar una estimación de un nuevo desarrollo. Ya desde el principio es muy importante tener en cuenta las pruebas de carga del sistema.
• Definición de requisitos de rendimiento: Es responsabilidad del jefe de proyectos del sistema el acordar con los responsables funcionales así como con las distintas áreas técnicas de la STIC las necesidades y requerimientos de rendimiento que debe cumplir el sistema.
• Estimación del desarrollo y pruebas de carga: El proveedor es el responsable de realizar la estimación que vea oportuna para el desarrollo del producto, incluyendo en dicha estimación el tiempo necesario para realizar las pruebas de carga aquí descritas.
  • Estimación pruebas de alta disponibilidad: Sistemas realizará una estimación sobre el tiempo que necesita para hacer pruebas de alta disponibilidad. Esta planificación será añadida a la estimación global.
• Planificación pruebas de carga: La OCA realizará la coordinación entre las diferentes partes (Sistemas y el Proveedor) de la realización de las pruebas de carga.
• Preparación de entornos: Sistemas es el responsable de asegurar que el entorno de pruebas necesario estará correctamente configurado de acuerdo a las especificaciones indicadas en el DGT del producto. Igualmente, Sistemas deberá asegurar la integridad del entorno durante toda la fase de pruebas de carga.
• Validación de requisitos previos: Tanto el proveedor como Sistemas deberá revisar el conjunto de requisitos previos explicados en el presente documento con el fin de asegurar el correcto estado del entorno y poder así iniciar los ciclos de pruebas del sistema.
• Ejecución de las pruebas de carga: Se refiere a la ejecución de forma ordenada de los diferentes tipos de pruebas de carga explicados en el presente documento.
• Análisis de resultados: El proveedor revisará y analizará los resultados de las pruebas de carga ejecutadas, transmitiendo a jefe de proyecto los resultados obtenidos de cara a decidir si continuar con el proceso de pruebas o abortar el ciclo. Es necesaria una explicación clara de lo que indica cada tabla / gráfica, tanto por parte del proveedor, como de CTI,  por lo que cada una de las tablas / gráficas, deberá venir customizada incluyendo una explicación de los datos que se están arrojando.
• Ejecución línea base del entorno: Sistemas ejecutará el procedimiento necesario para restaurar el entorno a su punto inicial y poder así iniciar un nuevo ciclo de pruebas.
• Revisión informe de resultados: La OCA revisará el informe de resultados de las pruebas de carga realizadas.
• ¿Se aceptan los resultados?: Se refiere a la aprobación por parte del jefe de proyecto de las pruebas ejecutadas hasta el momento, debiendo decidir entre continuar con las pruebas de carga, dar por finalizada la fase de pruebas, ya sea por haber llegado al último ciclo o por no tener resultados satisfactorios.
• Optimización de la estructura: Se refiere al proceso de ajustes y optimización por parte de Sistemas de la infraestructura ofrecida con el fin de solucionar posibles problemas de rendimiento o funcionamiento encontrados durante las pruebas de carga.
• Optimización del software: Se refiere al proceso de ajustes y optimización del software por parte del proveedor con el fin de solucionar posibles problemas de rendimiento o funcionamiento encontrados durante las pruebas de carga.

Plan de pruebas

Diseño

Uno de los aspectos más importante a la hora de plantear unas pruebas de carga del sistema es hacer un buen diseño de las pruebas a realizar, ya que estas deben ser representativas de la situación real del producto, esto es:

• Casos de Usos: Se deben identificar los casos de usos más representativos del sistema, aquellos usados con más frecuencia así como los casos de uso de nueva incorporación.
• Volumetría: Es imprescindible simular una volumetría semejante a la que se espera recibir en producción, ya que simular una carga muy diferente (ya sea por encima o por debajo) no será representativo del estrés real que sufrirá la aplicación, haciendo que las pruebas realizadas no sea representativas.
• Diseño de lanzadores de pruebas: En la medida de lo posible, se debe añadir en las herramientas de pruebas aquellos controles necesarios para validar que el resultado obtenido en cada petición es el esperado (Por ejemplo, aserciones en jMeter).
• Pruebas conectadas o desconectadas: Un aspecto clave a la hora de diseñar un buen plan de pruebas de carga del sistema es decidir qué situación es más representativa con respecto a la situación real que vamos a encontrarnos en producción. En general, puede tener más sentido hacer pruebas de carga desconectadas (Donde la aplicación testeada no se conectará con terceras aplicaciones o lo hará mediante simuladores), pero la STIC junto al proveedor deberá decidir si tiene más sentido hacer pruebas de carga conectadas (Por ejemplo, cuando se está probando una aplicación en la que la mayor parte de sus funcionalidades hacen uso de servicios ofrecidos por terceras aplicaciones).

Planificación

Como un aspecto fundamental a la hora de diseñar un plan de pruebas de carga del sistema, debemos tener en cuenta los distintos tipos de pruebas necesarios para llevar a cabo el ciclo de pruebas completo. Por ello, en la siguiente captura se muestra una plantilla a modo de ejemplo con los ítems que deben ser recogidos en la planificación de cualquier producto que vaya a realizar pruebas de carga.

Para iniciar el proceso de lanzamiento de pruebas de carga del sistema será necesario enviar correo electrónico a l-pruebasderendimiento.stic.sspa@juntadeandalucia.es con la siguiente información:

• Planificación detallada por tipo de prueba a realizar (se puede hacer referencia al apartado planificación del PPS). Debe incluir las pruebas de alta disponibilidad (sostenidas con tolerancia a fallos).
• Horario en el que se realizarán las pruebas, es importante indicar la franja horaria en la que se realizan la pruebas para poder contar con el soporte de Sistemas y sobre todo sí estas se realizan fuera de horario laboral (por ejemplo las cargas sostenidas se suelen hacer los fines de semana).
• Nº de máquinas lanzadoras (controladora + agentes) necesarias para la realización de las pruebas.
• Usuario DMSAS que realizará las pruebas, se utilizará para conceder el acceso a las máquinas.
• Software y versión necesario para realizar la pruebas.
• Aplicaciones afectadas por las pruebas de carga de sistemas, es necesario indicar las integraciones con aplicaciones que se realizan durante las pruebas. 
• PPS, adjuntar al correo el plan de pruebas de carga de sistemas actualizado.

El correo se debe enviar con al menos un mes de antelación a la fecha prevista de inicio de las pruebas.

Una vez la OCA reciba la solicitud de ejecución de pruebas de rendimiento y estudie su viabilidad, la misma OCA realizará petición CGES a CTI para la asignación de las máquinas lanzadoras a los proveedores para así ejercer el control de la asignación de éstas durante todo el periodo de pruebas. Esta asignación será por un periodo de tiempo determinado y de manera nominal (preferiblemente del usuario que vaya a realizar las pruebas) y será informado mediante correo electrónico al proveedor encargado de realizar las pruebas. (Calendario)

La solicitud CGES contendrá la siguiente información:

• Motivo de la reserva.
• Usuario DMSAS que realizará las pruebas.
• Fecha inicio y fecha fin de la reserva.
• Número de máquinas.
• Nombre de las maquinas a reservar.
• Software y versión necesario para realizar la pruebas.

A continuación se muestra un diagrama con el flujo a seguir de dicha petición CGES

Si por algún motivo justificado fuese necesaria una prórroga del tiempo establecido inicialmente en la petición CGES, el usuario encargado de realizar las pruebas y que tiene asignadas las máquinas lanzadoras deberá solicitar mediante un correo electrónico a "l-pruebasderendimiento.stic.sspa@juntadeandalucia.es" una ampliación de tiempo de asignación. Dicha solicitud de prórroga será tramitada por la OCA según el flujo anterior, informando al ejecutor de las pruebas sobre la resolución de la misma.

Una vez finalizado el periodo de asignación de las máquinas lanzadoras y tras conformación por parte del proveedor que las pruebas han finalizado, la OCA devolverá la petición CGES a CTI para que proceda a la des asignación de las mismas:

• Se quitan los permisos al usuario DMSAS.
• Se elimina su perfil y se desinstala el software solicitado.

Todas las máquinas se encuentran alojadas en el entorno de preproducción.

El usuario que realiza las pruebas no tendrá en ningún momento permisos de administración sobre las máquinas lanzadoras.

En caso de ser necesario el reinicio de las máquinas lanzadoras, el proveedor generará una petición CGES la cual será asignada a CTI para que la resuelva lo antes posible dicha petición y no produzca ninguna demora en la realización de las pruebas. Dicha petición CGES debe ser informada mediante correo electrónico a la lista l-pruebasderendimiento.stic.sspa@juntadeandalucia.es

Prerrequisitos

Los prerrequisitos son los elementos necesarios para una correcta ejecución de las pruebas. Es un proceso iterativo hasta que todos los actores acuerden los mismos y sean aceptados por la STIC.

Aunque no todo el conjunto de prerrequisitos dependen exclusivamente del proveedor, si será responsabilidad del proveedor las tareas de gestión necesarias para desbloquear los posibles impedimentos que pueda encontrarse al iniciar el proceso de pruebas del sistema.

En la siguiente tabla se muestra el conjunto de prerrequisitos que el proveedor deberá validar y marcar como revisado. En el caso de no poder validar algunos de los requisitos deberá contactar con el coordinador de las pruebas:

Validación de las comunicaciones

Las pruebas de comunicación son necesarias para que el PROVEEDOR pueda interactuar con el entorno y pueda probar las comunicaciones necesarias para las pruebas. Es un proceso iterativo hasta que el PROVEEDOR considere necesario.

Es importante no confundir con las comunicaciones entre aplicativos que los sistemas podrían realizar, estas pruebas se refieren SOLO a las pruebas que el proveedor necesita realizar para poder acceder a la herramienta y poder así hacer un seguimiento de las pruebas de carga realizadas.

La siguiente tabla muestra el listado de comprobaciones realizadas:

[Ejemplo. Reemplazar por tabla real]

 Línea base del entorno

En este proceso se recogen las tareas necesarias para poder reproducir el entorno original antes de cualquier prueba de carga. El responsable de ejecutar las tareas de este proceso es Sistemas, pero será responsabilidad del PROVEEDOR el definir los pasos que necesita ejecutar para la restauración del entorno.

Las tareas son las siguientes:

[En caso de necesitar tareas adicionales, estas deben ser indicadas aquí

Ejemplo: Si la prueba va a generar cambios en otras aplicaciones, se debe hacer backup de esa otra aplicación para poder restaurarla en caso de ser necesario.]

Métricas

Uno de los primeros pasos a realizar a la hora de abordar un conjunto de pruebas de carga de un sistema es identificar correctamente el conjunto de pruebas y métricas, de forma que sea lo suficientemente representativas para reflejar fielmente el funcionamiento del sistema ante una elevada carga de usuarios.

Para ello, se proponen dos conjuntos de posibles métricas a realizar dependiendo del tipo de prueba a realizar, definiendo en función del caso un conjunto de métricas básicas a medir.

Las métricas básicas se refieren al conjunto de métricas dirigidas a medir los tiempos de respuestas y buen funcionamiento del sistema. Estas métricas deben ser medidas en las diferentes tipos de pruebas que se proponen en el presente documento, debiéndose incluir en el informe final generado los resultados obtenidos en las mediciones de cada una de las pruebas.

IMPORTANTE: Es especialmente importante destacar la necesidad de diseñar indicadores de negocio específicos de cada aplicación y que serán de utilidad para conocer el buen funcionamiento del sistema y la validez de las pruebas (Por ejemplo, si estamos probando un sistema en el que sabemos que en producción se crean 1000 episodios por hora, y nuestro indicativo de "Episodios creados por hora" nos da un resultado de 100 episodios, sabemos que los resultados no son correctos, puesto que no está simulando una situación real.

Métricas básicas: API de Servicios

Las pruebas de carga del sistema orientadas a testear herramientas que principalmente ofrecen servicios web mediante API (Como por ejemplo es Maco, Estructura o BDU) deben ir dirigidas a testear cada servicio web que se ofrece.

Este tipo de servicios se caracterizan por ser rápidos, ágiles y concretos, dedicándose a un conjunto reducido de funcionalidades específicas y obteniendo tiempos de respuesta reducidos, por lo que las exigencias en cuanto a requisitos de respuesta son mayores que el caso de aplicaciones web.

Para este tipo de aplicaciones se propone medir las siguientes métricas básicas:

Para REST:

Para Soap:

(*): Es importante tener en cuenta que los valores marcados en la presente tabla como valores objetivos se refiere al conjunto de peticiones REST o Soap de operaciones sobre datos "típicas". Si la aplicación a testear cuenta con alguna funcionalidad específica de la que se espere un tiempo de respuesta mayor, debe indicarse en la siguiente tabla, aportando en cada caso una justificación de porqué se espera un tiempo de respuesta mayor al indicado como referencia en este documento:

Métricas básicas: Aplicaciones Web

Las aplicaciones web se suelen caracterizar por contar con una división entre la capa visual y otras capas que gestionan el negocio de la aplicación. Los frameworks de desarrollo web ofrecen un conjunto de funcionalidades (gestión de la sesión, páginas cacheadas en servidor, etc.) que hacen que los tiempos de respuestas en peticiones web suelan ser superiores a las aplicaciones que ofrecen API de servicios.

En el caso de aplicaciones web, las peticiones al servidor suelen dar como resultado respuestas de mayor tamaño que las API de servicios, puesto que en la misma respuesta se debe ofrecer toda la información necesaria para representar visualmente el contenido (HTML).

Para este tipo de aplicaciones se propone medir las siguientes métricas básicas:

(*): Es importante tener en cuenta que los valores marcados en la presente tabla como valores objetivos se refiere al conjunto de peticiones de navegación típicas de cualquier aplicación web. Si la aplicación a testear cuenta con alguna funcionalidad específica de la que se espere un tiempo de respuesta mayor, debe indicarse en la siguiente tabla, aportando en cada caso una justificación de porqué se espera un tiempo de respuesta mayor al indicado como referencia en este documento:

Métricas detalladas

Este conjunto de métricas van destinadas a profundizar en el comportamiento del sistema desde un punto de vista de sistemas, donde se pretende analizar que los diferentes componentes internos que forman parte de la arquitectura del sistema (Servidor, bases de datos, conexiones, etc.) funcionan correctamente.

El resultado de las mediciones obtenidas debe analizarse en las diferentes pruebas, debiéndose incluir en este informe las anomalías que se encuentren en dicho análisis. Igualmente, el proveedor podrá incluir en cualquiera de las pruebas el resultado de una o varias de estas métricas si lo considera necesario para comprender el informe generado.

Las métricas establecidas para esta prueba son:

Pruebas de capacidad

Se trata de la ejecución de casos de uso conjuntos y con concurrencia escalable de usuarios y con incremento paulatino de forma iterativa en un escenario de duración determinada a petición del PROVEEDOR.

El objetivo de estas pruebas es buscar los parámetros de configuración adecuados para los lanzadores de pruebas (jMeter), realizándose una carga progresiva sobre los sistemas a probar en busca del punto de carga máximo sin degradar el servicio, es decir, sin dejar de cumplir los requisitos del sistema. En caso de no existir estos requisitos, y tratándose de productos que ya están en producción, se debe simular una carga de transacciones que sea un 25% superior a la carga habitual recibida en horario de trabajo. Para los productos que no estén en producción también se establecerá el 25% superior a la estimación inicial realizada por el proveedor.

Debido a que los niveles de concurrencia encontrados en estas pruebas serán la base para las siguientes pruebas, una vez encontrado el punto máximo de carga sobre un sistema, es necesario ejecutar el plan de pruebas una segunda vez para confirmar que los datos observados son correctos.

La iteración del proceso dependerá de la autorización de la STIC, los problemas encontrados que necesiten algún ajuste, o que el PROVEEDOR no haya encontrado aún los niveles de concurrencia.

Resultados obtenidos

[El presente apartado se muestra únicamente a modo de ejemplo, debiendo ser cumplimentado al COMPLETO por el PROVEEDOR con los resultados, tanto de métricas básicas como de métricas detalladas, obtenidos en sus pruebas de carga.]

La aplicación X tiene como requisito el tener que soportar una carga máxima de 200 usuarios concurrentes, por ello se ha configurado la herramienta lanzadora para generar 100 hilos por cada uno de los 2 casos de usos programados para ser lanzado.

Es necesaria una explicación clara de lo que indica cada tabla / gráfica, tanto por parte del proveedor, como de CTI,  por lo que cada una de las tablas / gráficas, deberá venir customizada incluyendo una explicación de los datos que se están arrojando.

Tras la ejecución de la lanzadera durante 30 minutos, se ha obtenido un resultado estable de tiempos de respuestas que puede visualizarse en las siguientes gráficas (ordenada por tiempo medio de respuesta de mayor a menor):

Tras el lanzamiento de estas pruebas se realizan las siguientes comprobaciones:

• No se observan errores en el log de la aplicación

• El funcionamiento de la base de datos ha sido correcto, no detectándose cargas elevadas en CPU y Memoria.

• En los servidores de aplicaciones no se detectan cargas significativas.

Dados los datos obtenidos, se dan por válidas las pruebas de capacidad, pudiendo afrontar las siguientes pruebas definidas en el presente documento.

Pruebas de rendimiento

Se trata de la ejecución de casos de uso conjuntos y con concurrencia de hilos determinada por el PROVEEDOR de forma iterativa en un escenario de duración determinada por las pruebas de capacidad. El objetivo es observar el comportamiento del producto con diferentes niveles de concurrencia. Las pruebas de rendimiento son fundamentales.

La iteración del proceso dependerá de la autorización de la STIC y los problemas encontrados que necesiten algún ajuste y/u optimización del aplicativo o aplicativos.

Previo acuerdo con el PROVEEDOR y autorización de la STIC, los niveles de concurrencia recomendables serían los obtenidos por la prueba de capacidad. Lo habitual es que la prueba consista en tres iteraciones: una con el nivel de concurrencia máximo, otra con el nivel de concurrencia óptimo y una última con un nivel bajo.

En la siguiente tabla puede verse el conjunto de pruebas a realizar:

Resultados obtenidos

[El presente apartado se muestra únicamente a modo de ejemplo, debiendo ser cumplimentado al COMPLETO por el PROVEEDOR con los resultados, tanto de métricas básicas como de métricas detalladas, obtenidos en sus pruebas de carga.]

Es necesaria una explicación clara de lo que indica cada tabla / gráfica, tanto por parte del proveedor, como de CTI,  por lo que cada una de las tablas / gráficas, deberá venir customizada incluyendo una explicación de los datos que se están arrojando.

Partiendo de los niveles de concurrencia definidos en las pruebas de capacidad (200 hilos concurrentes), se definen las siguientes pruebas de rendimiento a realizar:

Obteniendo los siguientes resultados:

Concurrencia alta (160 hilos):

Concurrencia media (120 hilos):

Concurrencia baja (80 hilos):

Se aprecia una bajada importante de los tiempos de respuesta entre la concurrencia alta y la concurrencia media, lo cual nos hace ver que la concurrencia alta definida en las pruebas de capacidad está muy cerca del límite de los servidores actuales. Se recomienda asignar mayor cantidad de RAM a los servidores de weblogic, ya que el gráfico de carga muestra que se llegan a picos del 100%.

Pruebas de estrés

Se trata de la ejecución de casos de uso conjuntos y con concurrencia de hilos determinada por el PROVEEDOR y con máximos y mínimos locales determinados por el PROVEEDOR de forma iterativa en un escenario de duración determinada por el PROVEEDOR. La finalidad de estas pruebas es determinar la capacidad de recuperación del entorno frente a un período de carga superior a la máxima admitida.

La iteración del proceso dependerá de la autorización de la STIC y los problemas encontrados que necesiten algún ajuste y/u optimización del aplicativo o aplicativos.

Las pruebas deben ejecutarse de forma incremental, de forma que cada una de las pruebas que se muestran a continuación se deben lanzar sobre la anterior (Por ejemplo, se lanza el proceso inicial y se inicia la monitorización. A los 10 minutos se incrementa la carga, a los 20 se vuelve a incrementar, etc.):

Desde un punto de vista teórico, al sobrepasar el límite admitido por el servidor, algunas peticiones deberían comenzar a fallar, obteniendo respuestas erróneas durante el periodo de carga superior al máximo obtenido. El objetivo de estas pruebas es observar cómo, después de haber estado durante un periodo de tiempo por encima del límite, la aplicación vuelve a su estado normal y las nuevas peticiones enviadas siguen funcionando correctamente.

Por ello, como resultado de este proceso se debe observar los resultados obtenidos ANTES y DESPUÉS de la ejecución de estas pruebas, para lo cual existen varias alternativas:

• Incremento paulatino: Programar en la aplicación lanzadora un número elevado de hilos a lanzar y hacer que el incremento se realice durante un periodo de subida muy largo
  • Por ejemplo, si el límite de nuestra máquina está en 200 hilos, se puede programar una prueba que lance 300 hilos y que tenga un periodo de subida de 30 minutos.
• Programar diferentes lanzaderas: Programar una lanzadera inicial que ejecute el 80% de la capacidad máxima y posteriormente se van lanzando otras lanzaderas en las que cada una de ellas van aumentando la carga en un 20%. De esta forma se pueden ir parando manualmente cuando se vea necesario para volver a la carga inicial.

Resultados obtenidos

[El presente apartado se muestra únicamente a modo de ejemplo, debiendo ser cumplimentado al COMPLETO por el PROVEEDOR con los resultados, tanto de métricas básicas como de métricas detalladas, obtenidos en sus pruebas de carga.]

Es necesaria una explicación clara de lo que indica cada tabla / gráfica, tanto por parte del proveedor, como de CTI,  por lo que cada una de las tablas / gráficas, deberá venir customizada incluyendo una explicación de los datos que se están arrojando.

Para la realización de estas pruebas se ha partido de la concurrencia definida en las pruebas de capacidad, realizándose las siguientes pruebas:

[(*): A modo de ejemplo se ha lanzado el test durante solo 10 minutos. Se recomienda que en un caso real se ejecute al menos 1 hora y se vayan realizando incrementos de concurrencia cada 10 o 20 minutos]

Ejecutadas las pruebas, se observa que a partir del primer incremento los tiempos de respuesta ya se elevan a valores no admisibles.

Esto nos lleva a pensar que, como se había mencionado anteriormente, la máquina ya estaba cerca de su límite máximo.

En la siguiente gráfica se muestra como se deterioran las peticiones con cada incremento de concurrencia:

En este caso concreto, el problema se debe a una limitación de la máquina en la que está desplegada Weblogic, ya que se está quedando sin memoria con demasiada facilidad:

Pruebas sostenidas

Se trata de la ejecución de casos de uso conjuntos y con concurrencia de usuarios determinada por el PROVEEDOR, normalmente medio/bajo, de forma iterativa en un escenario de larga duración determinada por el PROVEEDOR. Estas pruebas determinan la degradación del servicio y el ciclo de vida de las instancias de WebLogic y las instancias de bases de datos.

La iteración del proceso dependerá de la autorización de la STIC y los problemas encontrados que necesiten algún ajuste y/u optimización del aplicativo o aplicativos.

A modo general, se propone lanzar estas pruebas con un 40% del nivel de concurrencia máximo determinado en las pruebas de capacidad durante al menos 48 horas (Siendo el PROVEEDOR quien determine el periodo exacto que ve más apropiado)

Resultados obtenidos

[El presente apartado se muestra únicamente a modo de ejemplo, debiendo ser cumplimentado al COMPLETO por el PROVEEDOR con los resultados, tanto de métricas básicas como de métricas detalladas, obtenidos en sus pruebas de carga.]

Es necesaria una explicación clara de lo que indica cada tabla / gráfica, tanto por parte del proveedor, como de CTI,  por lo que cada una de las tablas / gráficas, deberá venir customizada incluyendo una explicación de los datos que se están arrojando.

Tras ejecutar todos los casos de pruebas durante 48 horas con un nivel de concurrencia definido durante las pruebas de capacidad (200 hilos) se obtienen los siguientes resultados:

Prueba ejecutada entre el 26/12/2017 08:00 y el 28/12/2017 08:00

Pruebas sostenidas con tolerancia a fallos

Se trata de pruebas sostenidas pero dirigidas por Sistemas y con soporte del PROVEEDOR en el lanzamiento. La idea subyacente es la de realizar operativas sobre las instancias de WebLogic e instancias de bases de datos correspondiente al entorno objetivo, ya sean administrativas o no, y estudiar el comportamiento de los casos de uso e indicadores de negocio.

La duración de la prueba estará acotada por lo acordado con la STIC y el tiempo disponible al tratarse de las pruebas realizadas en último lugar.

La iteración del proceso dependerá de la autorización de la STIC y los problemas encontrados que necesiten algún ajuste y/u optimización del aplicativo o aplicativos.

El diseño de las pruebas se muestra en la siguiente tabla:

Conclusiones

En el presente apartado se hace un resumen de los resultados obtenidos y sus interpretaciones. Aunque la cumplimentación de este apartado es responsabilidad del PROVEEDOR, los datos aquí expuestos deben ser acordados con los diferentes grupos de la STIC dependiendo del caso (Sistemas, Arquitectura, Interoperabilidad, etc.).

En estas conclusiones se deben aportar al menos los siguientes datos, teniendo en cuenta que se refieren en cada momento a la infraestructura actual existente:

[A partir de este punto la información mostrada es únicamente a modo de ejemplo, debiendo ser cumplimentado al completo por el PROVEEDOR con los resultados obtenidos durante sus pruebas]

Dados los resultados de las pruebas realizadas, podemos aportar la siguiente información:

• Capacidad máxima: Una vez analizadas las pruebas de estrés, a partir de 300 usuarios concurrentes por nodo los tiempos de respuestas son demasiado elevados (1,8 segundos). Por lo que se considera que 300 es el máximo de usuarios por nodos que soporta la aplicación.
• Margen actual: Dado que 200 usuarios (Pruebas de capacidad) ya supera aproximadamente un 25% el número de usuarios en picos de trabajo, aún hay un margen de 100 usuarios por nodo.
• Nodos recomendados: Dado que la previsión es contar con 500 usuarios concurrentes en momentos de máximo trabajo, creemos que la arquitectura actual (3 nodos) es suficiente.

Adicionalmente, se desea destacar las siguientes conclusiones extraídas de los resultados obtenidos:

• Memoria RAM: La memoria actualmente asignada a Weblogic (1GB) puede considerarse demasiado justa para el sistema. Se recomienda aumentar la memoria asignada a 1.5GB.
• Lentitud de peticiones: Se detecta un tiempo medio de respuesta de más de 2 segundos en la acción de logar. Se analizará para futuras versiones cómo optimizar este proceso para reducir el tiempo de respuesta.

Finalmente, con la información recogida a lo largo del proceso de pruebas de carga del sistema, junto a la experiencia del proveedor como conocedor del producto a nivel técnico, el PROVEEDOR establece que las pruebas han sido:

  El documento debe finalizar con las conclusiones globales por parte del proveedor o de CTI, respectivamente, indicando si del resultado de las pruebas realizadas se desprende que la aplicación es apta o no para su puesta en producción.

Anexos

Anexo I: Casos de Uso

El conjunto de casos de usos debe ser acordado entre el proveedor y la STIC a través de los responsables funcionales de la aplicación.

A continuación se muestra un ejemplo de los casos de uso a probar:

Anexo II: Plantilla PPS

Siguiendo la estrategia de migración a Confluence adoptada por la STIC, se ha creado una plantilla en dicha herramienta con el fin de abandonar el documento que se utilizaba hasta ahora.

El informe se ubicará en el espacio del proyecto correspondiente, en el apartado "versiones", dentro de la versión sobre la que se hayan ejecutado las pruebas.

Una vez situados en el lugar en el que queremos generar el informe, sólo tenemos que crearlo utilizando la plantilla llamada "Plan de pruebas de carga del sistema".

Si surgiese alguna cuestión al respecto, la Oficina de Calidad está siempre dispuesta a resolver cualquier duda que surja.

Anexo III: Lista de revisión de documentación

A continuación se presentan los puntos de revisión que se aplicarán al documento PPS entregado:

Anexo IV: Hot Deployment

Requisitos y recomendaciones para afrontar con garantías un hot deployment:

1. Aplicación del workaround relativo a los conflictos de clases. Nos hemos encontrado 3 tipos de conflictos en los entornos del SAS:

• Duplicidad en clases aportadas en el desplegable del proveedor y el software base de WebLogic. En el war/ear/jar tenemos las clases que tiene Weblogic en el software base existe con una versión distinta. En este caso podemos tratarlo con informes de conflicto de clases desde WebLogic (informes CAT).
• Duplicidad en clases aportadas en el desplegable. En el mismo war/ear/jar hay clases duplicadas  con distintas versiones. El informe CAT no detecta estos casos, luego tendrá que realizarse mediante una herramienta de auditoría de código. En este caso hemos acordado que el aplicativo esté Mavenizado y compruebe que no haya "clases" en las librerías duplicadas (ojo, librerías con distinto nombre pueden tener clases repetidas con distintas versiones, luego no es sólo comprobar que haya librerías con distinto nombre).
• Duplicidad en clases aportadas por librerías copiadas manualmente en el rutas accesibles (CLASSPATH) como si fuera software base (por ejemplo $DOMAIN/lib). Este caso tampoco es comprobable con el informe CAT. Se ha acordado que el aplicativo candidato a despliegue caliente no puede tener más allá del software base de weblogic en el directorio de Middlware. Cualquier clase distinta al software base debe estar en el war/ear/jar e indicada la preferencia para weblogic en el descriptor de despliegue weblogic.xml.

2. No se deben incluir a nivel de máquina virtual de java parametrización que pueda provocar un comportamiento irregular del servidor de WebLogic. Por ejemplo, en el caso del "nodo mudo" se indica un parser a nivel de JVM distinto al utilizado por defecto en weblogic, cuando se debe utilizar como recursos dentro de los paquetes EAR. El ejemplo está documentado por Oracle en el siguiente enlace: https://docs.oracle.com/cd/E23943_01/web.1111/e13724/appscope.htm#XMLPG224 para WebLogic 10.3.6. En él se ejemplifica el cómo cambiar el Parser desde el EAR y no a nivel de JVM.

3. El cambio a desplegar debe ser pilotable en BBDD y otros elementos compartidos como JMS, JTA, EJB, etc¿ Es decir, si el desplegable conlleva un cambio en base de datos y hay que parar para ese cambio, no se puede desplegar en caliente. Si el aplicativo necesita un reinicio un timeout excesivo en JTA, parar JMS, cambio en paramétricas en base de datos, etc¿ Puede ser contraproducente el despliegue en caliente y que dos versiones estén simultáneamente en ejecución.

4. Redimensionamiento de los pooles de java relacionados con la carga de clases: PermGen en java 7 y MetaSpace en java 8. 
En Java 8 se suele indicar un máximo, aunque sea memoria nativa, suele estar restringido el máximo al igual que con Java 7 y el PermGen. Se debe, al menos, tener el doble para que no estamos ante excepciones de tipo OutOfMemory en los despliegues en caliente.

Todos estos requisitos son añadidos a las recomendaciones indicadas por Oracle en la documentación oficial:

https://docs.oracle.com/cd/E13222_01/wls/docs100/deployment/redeploy.html (apartado "Requirements and Restrictions for Production Redeployment")

Los requisitos aquí indicados son los mínimos, pero evidentemente hay que probarlo por cada plataforma y de forma exhaustiva ya que el modo de programación es ajeno a sistemas. 

 Para porder comprobar que se ha realizado correctamente el despliegue en caliente, proponemos realizar la una prueba de una versión (la ya desplegada) a otra (la que queremos desplegar en caliente) con una carga sostenida, lo que significa tener preparado dos versiones (versión A y B) con cambios en uno o varios casos de uso que se estén probando en dicha carga:

1. Despliegue versión A con versionado y reinicio/limpieza de entorno.
2. Lanzamiento de prueba sostenida.
3. Redespliegue online de versión B en la mitad de la prueba sostenida con un retire timeout de 5 minutos (el tiempo de expiración de sesión se consensuará entre las partes interesadas).
4. Espera a final de prueba sostenida de al menos 48 horas.