sgp-rfc-010 an lisis de desempe o y modelo de …...datos y de aplicaciones, bajo modelos de redes...

Análisis de desempeño y modelo de escalabilidad par a SGP

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 line, 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 p rocesos

1- La operación por procesos requiere principalmente recurso de CPU, debido a que el sistema ejecuta, de forma permanente, transformaciones XML durante su ejecución. 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, la primeras variables a considerar son el número de usuarios concurrentes, y el tamaño del proceso a ejecutar.

3- Es importante tener en cuenta que 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 a la del propio SGP. Estas pueden variar en 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:

1- Es muy 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.

2- Se debe revisar la operación de software de soporte y mantenimiento que opera en forma simultánea con el software del aplicativo, esto con el fin de evitar 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.

3- 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.

4- 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 maquina 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.

5- 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.

6- 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.

7- 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.

2. Estimativo de carga basado en la simulación de p rocesos 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

• Tiempo promedio de ejecución por actividad: 0.25 segundos




- Resultados Simulación # 2: • Número actividades ejecutadas: 2.560





- Resultados Simulación # 3:

• Actividades ejecutadas: 3.910





• 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


- 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 en forma muy importante. Esto ocurre por efecto de coincidencias de procesamiento que empiezan a agregarse súbitamente, y luego desaparecen de igual forma.

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 opere en equipos

independientes:

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.

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 preactivas entre los servidores de bases de datos y los servidores de aplicación, con el objetivo de 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 en 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

• 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.

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.

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 conoce 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, y además verificar la infraestructura de operación.

sgp-rfc-010 an lisis de desempe o y modelo de …...datos y de aplicaciones, bajo modelos de redes...

Documents