1

SGP-RFC-010

Análisis de desempeño y modelo de escalabilidad para SGP

SGP-RFC-010

Localizacion:

http://subversion.analitica.com.co:8023/SGP/Docs/RFCs/SGP-RFC-010 Análisis de Desempeño y Modelo de Escalabilidad.docx

Este documento es producto de la experiencia de Analítica en pruebas de stress sobre el

software SGP. Estas pruebas se realizaron sobre un proceso de negocio típico:

“Cotización de pólizas de Seguros de Automóviles”. Es importante tener en cuenta que

cada proceso cuenta con características particulares y por esa razón este ejercicio sólo

se orienta a mostrar órdenes de magnitud y comportamientos típicos que pueden

presentarse. El ejercicio cuenta con los siguientes elementos:

1- Recomendaciones generales sobre infraestructura.

2- Ejercicio de simulación de usuarios concurrentes, usando una máquina base de

línea y un proceso típico de negocio.

3- Metodología de escalamiento.

4- Algunos patrones de escalamiento.

5- Conclusiones.

1. Consideraciones preliminares sobre gestores de procesos

1- La operación por procesos requiere principalmente recurso de CPU, debido a que

el sistema ejecuta, de forma permanente, transformaciones XML durante su labor.

Por su parte, el componente de memoria se mantiene sin cambios considerables

de capacidad.

2- El componente que afecta el desempeño es la ejecución de los procesos, no el

almacenamiento de los mismos. Por esta razón, las primeras variables a

considerar son el número de usuarios concurrentes y el tamaño del proceso a

ejecutar.

2

SGP-RFC-010

3- En este tipo de arquitecturas, el éxito de un proceso depende de la eficiencia en la

ejecución y de la interacción con otros sistemas. En estas variables pueden influir

procesos objeto de análisis como:

a. Tiempos de respuesta de las consultas a las distintas bases de datos,

incluyendo la del propio SGP. Estas pueden variar con el tiempo en razón

al número de registros que tengan, a la complejidad de sus consultas, y al

estado y configuración de sus índices, además de otras variables de

configuración.

b. Costos de procesamiento derivados de procesos de protocolo, validación,

autenticación y ejecución. Estos son externos a la operación del motor de

procesos, debido a que están sujetos a las condiciones de operación de

aplicativos externos.

Teniendo en cuenta las anteriores consideraciones, es claro entonces, que antes de

emprender un proceso de escalamiento y análisis de stress, para puesta en producción,

es muy importante asegurar las mejores condiciones de operación del sistema y sus

diferentes componentes.

Un indicativo de la existencia de problemas en la infraestructura se observa, con

frecuencia, por un comportamiento incoherente entre uso de CPU y tiempos de

respuesta por procesamiento. Esto puede provenir de diversos factores:

Incorrecta operación/configuración del software de antivirus.

Incorrecta operación/configuración del software de monitoreo.

Interconexión insuficiente de servidores (múltiples puntos intermedios).

Incorrecta configuración de servidores proxy y modelos de caché.

Incorrecta operación o creación de índices, en las bases de datos.

Utilización de drives incorrectos para conexión a bases de datos, redes o

discos duros.

Uso inapropiado de recursos para procesamiento (máquinas virtuales no

equivalentes a maquinas físicas, o utilización compartida de recursos).

Para evitar estos inconvenientes, tenga en cuenta las siguientes recomendaciones:

3

SGP-RFC-010

4- Es importante contar con interconexiones entre servidores de bases de datos y de

aplicaciones, bajo modelos de redes locales conectadas lo más cerca posible,

para disminuir el número de retransmisiones, y así garantizar un buen

desempeño.

5- Se debe revisar la operación de software de soporte y mantenimiento que opera

en forma simultánea con el software del aplicativo, así se evitan bloqueos y

generación de ‘cuellos de botella’ en la operación de este último. En especial se

debe verificar la operación del software de antivirus y monitoreo.

6- Es importante realizar las pruebas sobre equipos e infraestructura que cumplan

con los requerimientos del software del fabricante. De esta forma se evitan

resultados inesperados que derivan en pérdida de tiempo.

7- El software SGP corre en máquinas virtuales sin inconveniente. Lo importante es

igualar el poder de cómputo EFECTIVO de estas máquinas frente al de una física.

En este sentido, se debe tener en cuenta la pérdida de capacidad de cómputo

debida al uso de la capa de virtualización, y al hecho de compartir recursos físicos

(CPU, memoria, disco, red, etc.) con otros aplicativos/bases de datos, que operan

en las máquinas virtuales vecinas. Es importante entender que un procesador

virtual está concebido para priorizar el trabajo de una máquina virtual sobre las

otras, pero no equivale al poder de cómputo real del procesador físico.

8- Se debe garantizar la cercanía física de los servidores de base de datos y de las

aplicaciones, con el objetivo de mejorar de manera significativa el desempeño del

sistema, y además reducir los puntos de posible falla, disminuyendo los elementos

físicos involucrados en la interconexión.

9- Contar con un equipo físico (en lugar de uno virtual), especialmente configurado

para la aplicación, con el sistema operativo adecuado, y el software de

infraestructura requerido (base de datos y servidor web). Instalar un software

diferente al requerido por el aplicativo puede generar muchos puntos de

incertidumbre, a la hora de hacer pruebas.

10- Tener en cuenta que las versiones o actualizaciones (parches o módulos

específicos) de las aplicaciones de la plataforma de ejecución (SO, Web Server,

Aplication Server), pueden ocasionar grados de incompatibilidad, que afectan la

ejecución de la aplicación del usuario final. Es muy importante considerar este

punto al momento de definir políticas de actualización, con el fin de garantizar la

estabilidad y rendimiento de la plataforma del software.

4

SGP-RFC-010

2. Estimativo de carga basado en la simulación de procesos sobre una

infraestructura tipo

En esta sección se analiza el comportamiento del proceso típico de negocio “Cotización

de pólizas de seguros de automóviles”, sobre la plataforma mínima recomendada para

operar el SGP en producción. La idea es simular la carga de 25, 50 y 75 usuarios

simultáneos sobre el sistema, cotizando un número igual de pólizas de seguro. Si esta

carga fuera estable, se podrían cotizar en promedio 10 pólizas por minuto, para un total

de 4.800 pólizas diarias.

- Definición del proceso:

Proceso: Cotización de pólizas de seguros de automóviles

Número de actividades: 60

Número de interacciones típicas con la base de datos: 30

Interacciones con WebServices: 2

- Infraestructura:

Tipo de máquina: Estación de trabajo física

Procesador: 2.2Ghz, Dual Core

Memoria: 4GB Ram

Red: 1Gbit/s

Sistema Operativo: Windows Server 2005

Web Server: Apache 2.2

Application Server: PHP 5.2

Base de datos: MS-SQL Server 2005

- Condiciones de Simulación # 1:

Usuarios concurrentes: 25

Velocidad de ingreso al aplicativo: 1 usuario cada 2 segundos

- Resultados Simulación # 1:

Número actividades ejecutadas: 1.479

5

SGP-RFC-010

Tiempo promedio de ejecución por actividad: 0.25 segundos

- Condiciones de Simulación # 2:

Usuarios concurrentes: 50

Velocidad de ingreso al aplicativo: 1 usuario cada 2 segundos

- Resultados Simulación # 2:

Número actividades ejecutadas: 2.560

Tiempo promedio de ejecución por actividad: 0.73 segundos

- Condiciones de Simulación # 3:

Usuarios concurrentes: 75

Velocidad de ingreso al aplicativo: 1 usuario cada 2 segundos

6

SGP-RFC-010

- Resultados Simulación # 3:

Actividades ejecutadas: 3.910

Tiempo promedio de ejecución por actividad: 0.63 segundos

- Condiciones de Simulación # 4:

Usuarios concurrentes: 600

Velocidad de ingreso al aplicativo: 1 usuario cada 2 segundos

Tipo de máquina: 2 Servidores con un balanceador de carga

Procesador: 4 Procesadores 2.2Ghz, Quad Core

Memoria: 8GB Ram

Red: 1Gbit/s

Sistema Operativo: Windows Server 2005

Web Server: Apache 2.2

- Resultados Simulación No 4:

Actividades ejecutadas: 30.000

Tiempo promedio de ejecución por actividad: 0.2 segundos

7

SGP-RFC-010

- Análisis:

1- Se aprecia cómo se incrementa el tiempo en la ejecución de forma proporcional al

aumento de los usuarios que entran en el sistema. Pero este tiempo no se

incrementa en situaciones con más usuarios, pues cuando están entrando los

últimos, los primeros ya están terminando el proceso, de tal forma que la

concurrencia ‘alcanza su límite’ de acuerdo al tiempo que toma la ejecución del

proceso, sobre la infraestructura disponible.

2- Al principio, la mayoría de los resultados tienden a mostrar tiempos de ejecución

inferiores a un segundo, no obstante se pueden dar situaciones de picos súbitos

de procesamiento, los cuales pueden elevar el uso de CPU de forma importante.

Esto ocurre por efecto de coincidencias de procesamiento que empiezan a

agregarse súbitamente, y luego desaparecen de igual manera.

3- La capacidad teórica de 4.800 pólizas diarias, bajo una carga permanente de 75

usuarios concurrentes, puede generar efectos como los que se reportan en las

gráficas, lo cual requiere la adopción de arquitecturas un poco más robustas que

eliminen esos momentos de congestión del procesador, y garanticen un tiempo de

espera inferior a un segundo, por parte del usuario.

4- En la simulación #4, en la cual se cambia la máquina por dos con mayor poder, se

logra fácilmente aumentar el número de usuarios multiplicando el número de

procesadores y núcleos, garantizando así tiempos de respuesta óptimos.

Arquitectura Escalable:

Como se aprecia en el punto anterior, los picos de congestión ‘pasajera’ en el procesador

pueden afectar la experiencia de usuario, al aumentar la espera que generalmente es de

menos de un segundo, a 20 segundos. Por esta razón, es importante minimizar el

número de picos de congestión en el sistema, con la implementación de las siguientes

estrategias:

1- Operación del sistema bajo un modelo de tres capas que actúe en equipos

independientes:

8

SGP-RFC-010

a. Capa de presentación, generada y operada en los equipos de los

clientes.

b. Capa de negocio, operada en forma independiente por servidores de

aplicación paralelos.

c. Proxy en reversa, orientado a repartir la carga de usuarios entre los

distintos servidores de aplicación.

d. Capa de persistencia, operada en servidores de base de datos en

cluster.

2- Formateo y validación de información en la capa de presentación, por medio

del uso intensivo de hojas de estilo, diccionario de datos y validaciones de

javascript. Todas estas cargadas una sola vez en la memoria caché del equipo

del cliente, para ser usadas múltiples veces.

3- Mantenimiento de hilos de conexión disponibles entre el cliente y los servidores

de aplicación, lo cual minimiza procesos de handshaking entre servidor de

aplicaciones y usuario.

4- Caché de páginas y gráficos en el proxy en reversa, para minimizar los ciclos

de operación de los servidores de aplicación.

9

SGP-RFC-010

5- Código precompilado en caché de los servidores de las aplicaciones, con el fin

de evitar los retrasos generados por el tiempo de interpretación de código.

6- Integración nativa a nivel de compilación de módulos entre el web server

(Apache) y el “Aplication Server” (PHP). En orden a minimizar los tiempos de

comunicación entre estos dos componentes.

7- Manejo de conexiones pre activas entre los servidores de bases de datos y los

servidores de aplicación, para minimizar el handshaking entre estos sistemas.

8- Operación bajo modelos de motores de bases de datos cluster, y/o esquemas

de bases de datos distribuidos en múltiples servidores.

3. Metodología de escalamiento:

Las características de cada solución informática por procesos son diferentes: los

procesos, el comportamiento de los usuarios, la infraestructura, las sedes físicas, e

inclusive las unidades de negocio. Por esta razón NO se puede hablar de unas reglas

estrictas de escalabilidad, sin embargo, sí es posible considerar algunos puntos de

partida basados en la experiencia:

1- Asuma como modelo inicial de trabajo el uso de un procesador físico dual core de

2.2 Ghz, 4MBytes RAM, por cada 25-50 usuarios concurrentes, corriendo un

proceso de 50-80 actividades en promedio. Escale linealmente el número de

procesadores o servidores físicos, de acuerdo al número máximo de usuarios

concurrentes y tamaño de proceso concurrente promedio.

2- Para operaciones de alta disponibilidad se recomienda iniciar con dos servidores

de aplicaciones, un sistema de balanceo de carga y un servidor de base de datos.

3- Las siguientes fases se pueden dar en términos de manejo de servidores externos

para soportar parte de los procesos, los cuales a su vez pueden estar

configurados bajo el modelo mencionado en el punto 2.

4. Patrones de Escalamiento

El primer punto a tener en cuenta son los factores que pueden intervenir en la elección

de una configuración:

Seguridad

10

SGP-RFC-010

Confiabilidad

Disponibilidad

Compatibilidad

Arquitectura empresarial

Ahora, consideremos las distintas configuraciones de escalamiento de las soluciones

basadas en SGP, partiendo de los siguientes elementos:

Manejador Base de Datos del SGP (BD-SGP)

Manejador Base de Datos del Aplicativo (BD-App)

Servidor de Aplicaciones del SGP (SA-SGP)

Servidor de Aplicaciones del Aplicativo (SA-App)

Servidor Proxy para balanceo de Carga (PROXY)

Estos componentes pueden estar distribuidos en uno, dos o más servidores bajo

múltiples configuraciones, las cuales se pueden apreciar en el siguiente gráfico.

11

SGP-RFC-010

Lo realmente importante, es lograr que el modelo permita total flexibilidad y adaptabilidad

a los requerimientos, con un mínimo costo de configuración. De esta forma se garantiza

pasar de una topología a otra, sin generar mayores traumatismos.

12

SGP-RFC-010

5. Conclusiones

1- Antes de iniciar el proceso de escalamiento se debe asegurar una infraestructura

estable y confiable; muchos problemas y retrasos se deben a fallas en sistemas y

a políticas inexactas de infraestructura.

2- Cada proceso es diferente, por ello es difícil e incierto trazar modelos y

requerimientos de expansión cuando no se conocen a fondo las métricas de

ejecución del proceso. Por ahora, nuestra herramienta más confiable es la

simulación de procesos y su comparación con otros procesos ya implantados.

3- La ejecución de procesos genera efectos de congestión súbita que pueden causar

retrasos en la ejecución de los procesos, y por lo tanto sensación de lentitud en el

usuario. Por esta razón, siempre se deben tener en cuenta estas congestiones al

momento de estimar la carga.

4- Resulta muy útil hacer análisis de simulación con los procesos seleccionados, con

el fin de obtener métricas de ejecución que permitan identificar las configuraciones

topologías más adecuadas, además de verificar la infraestructura de operación.