h1

Estimando usuarios concurrentes

06/04/2009

Wizdoc [Icon By Buuf]  Tips & Tricks.
Este mes de junio estará algo complicado en el trabajo. Primero, porque es el cierre de año fiscal (FY08-09) y ya que la empresa donde laboro se mueve de acuerdo a dicho calendario, deberemos cerrar tantos proyectos como sea posible para que entren en la cuota impuesta a nuestro equipo. Y segundo, porque nuestro jefe se pasa a la competencia y aunque no debería afectarnos mucho su partida, a su jefa le entró la idea – típica de cualquier patrón, creo yo – de que este muchacho nos esta dejando colgados con la chamba.

Pues bien, uno de los proyectos que debemos cerrar durante las próximas semanas es la "reingeniería" de una aplicación web que nuestro usuario ha tenido publicada por más de 3 años y que debido a la enorme cantidad de bugs que se introducen al agregar un cambio, ha llegado al punto en que es más barato construir una aplicación nueva que seguirle dando mantenimiento a la ya existente.

Estimando una plataforma

Un problema con el nos estamos enfrentando es el dimensionamiento de la plataforma de hardware. Esto porque el usuario casi no tiene estadísticas de uso y sólo sabe que para el próximo año, la cantidad de usuarios registrados en la aplicación rondará los tres millones. Así que, ¿qué combinación de hardware y software necesitamos?

Para implementar redundancia y alta disponibilidad sin que los costos por hardware se suban hasta el cielo, tenemos un template de arquitectura que podremos refinar conforme avancemos con el proceso de estimación:

Template de arquitectura multicapa

Los F5 realizan el balanceo de carga de las capas web y aplicativa, mientras que el failover se implementa por los web y application servers (utilizando el Sun Cluster para dicho fin). El Oracle RAC realiza lo propio sobre los nodos de la base de datos. El HADB o base de datos de alta disponibilidad proporciona la persistencia de las sesiones web, mientras el JMS (Java Message Service) facilita la persistencia de transacciones y mensajes asíncronos.

Ahora bien, muchos componentes de hardware poseen un estimado de transacciones por segundo o ancho de banda que soportan y otros tantos los recursos que consumen (CPUs, memoria, disco) de acuerdo a cierto nivel de carga. Todos estos números requieren de una estadística en común mediante la cual podremos calcular todo lo demás: el número de usuarios concurrentes.

• Por ejemplo, si tenemos un sistema cuyas páginas transmiten por la red unos 150 KB/s por página y tenemos 200 usuarios concurrentes, podremos obtener el estimado de ancho de banda de 150 KB/s x 8 bits por byte x 200 usuarios = 240,000 kilobits por segundo = 234.375 Mbps.

• De igual manera, muchas aplicaciones tienen "requerimientos del sistema" que incluyen memoria, disco duro y procesador dependiendo del número de usuarios: en el SPEC (Standard Performance Evaluation Corporation) se realizan benchmarks de desempeño de servidores de aplicaciones y se indican los resultados en número de transacciones por segundo (aunque en ese caso particular, la métrica estándar son las jAppServer Operations Per Second o JOPS).

• Por otro lado, si tenemos la oportunidad de realizar una prueba de concepto, podemos generar estrés sobre una "arquitectura base", con cierto número de usuarios concurrentes definido por nosotros. En base al uso de memoria, cpu, disco y tiempo de respuesta, podremos definir una "arquitectura base". Al obtener una mejor aproximación del número real de usuarios concurrentes que usarán la aplicación, podremos rediseñar nuestra arquitectura para no quedarnos cortos.

Calculando usuarios concurrentes

Normalmente, cuando hablamos de usuarios concurrentes, queremos decir cuántos usuarios están logueados en la aplicación durante un instante dado. Es decir, puede que una aplicación tenga N usuarios registrados, pero es muy poco probable que TODOS operen sobre la aplicación al mismo tiempo:

Grafica Gantt de uso

Usuarios logueados a lo largo del tiempo. Aunque el "sistema" tiene cinco usuarios registrados, todos ellos trabajan en diferentes horarios. En este caso, cuando t = 10, existen 3 usuarios operando de manera concurrente.

¿Cuál es la utilidad de esto? Que en muchos casos se utiliza "un porcentaje" de los usuarios registrados como métrica de posibles usuarios concurrentes, pero esto carece de validez real y puede meternos en muchos problemas.

Ahora bien, con tan sólo navegar la aplicación, se puede obtener el promedio que le tomaría a un usuario realizar las funciones publicadas por ésta. Es decir, podríamos saber cuál es el tiempo L que un usuario está logueado de principio a fin. Así tendríamos un número mucho más aproximado al que estamos buscando:

C = Sumatoria(L1, L2, …, Ln) / T

Donde:

C = Número de usuarios concurrentes.
Ln = Tiempo de uso de la aplicación por el usuario n.
T = Intervalo de tiempo durante el cual estamos realizando la medición.

Usando el ejemplo de la gráfica de Gantt de más arriba, tenemos que:

L1 = 15
L2 = 12
L3 = 10
L4 = 10
L5 = 12

Y el tiempo de medición podría ser desde t = 0 hasta t = 25 (tiempo durante el cual la aplicación está disponible).

Aplicando formulazo:

C = (15 + 12 +10 + 10 + 12) / 25 = 2.36, redondeado ≈ 3

Por lo que en un tiempo determinado, tenemos 3 usuarios concurrentes para nuestra aplicación.

Alternativamente, podemos calcular el mismo número usando la fórmula

C = n L / T

Donde:

C = Número de usuarios concurrentes.
n = Número de usuarios totales.
L = Tiempo promedio de uso de la aplicación para todos los usuarios.
T = Intervalo de tiempo durante el cual estamos realizando la medición.

Y con el mismo ejemplo:

C = 5 x 11.8 (el promedio de tiempo de sesión de los usuarios) / 25 = 2.36, redondeado ≈ 3

Un ejemplo más elaborado

Supongamos que tenemos un sistema de nómina de la empresa Patito Labs (con aproximadamente 170,000 empleados) donde los usuarios pueden ver si ya les depositaron su quincena. Debido a disponibilidad de horario, conocimientos sobre computación y otras limitantes, se espera que sólo el 50% de los empleados utilice el sistema. Adicionalmente, se estima que el 70% de los usuarios registrados utilice el sistema durante la semana de pago. Debido a un estudio de usabilidad realizado por los mismos programadores, se sabe que el tiempo promedio por sesión es de unos cinco minutos. Restringiendo el periodo de uso del sistema a las horas en que está disponible (de 10 am a 6 pm, de lunes a viernes) podremos calcular el número promedio de usuarios concurrentes que ocupan el sistema:

n = 170,000 x 0.5 x 0.7 = 59,500 usuarios.
L = 5 minutos.
T = 5 días x 8 horas x 60 minutos = 2,400 minutos.

C = (59,500 x 5) / 2,400 = 123.95, redondeado ≈ 124

Así entonces, podremos asegurar que durante algún momento dado de esa semana, el promedio de usuarios concurrentes será de 124.

Picos de uso

Pero aquí tenemos otra dificultad: aunque nuestra arquitectura y los estimados de uso pueden ser suficientes para atender al promedio de usuarios, en el caso de plataformas de alta disponibilidad no queremos que se nos caiga todo cuando exista un pico. Por ejemplo, aunque los cajeros bancarios pueden ser usados en promedio por una persona cada diez minutos a lo largo del mes, seguramente tendrán un uso continuo en los días de quincena por lo que el sistema de cajeros debe estar diseñado con dicha carga en mente.

Aquí entran unos cuantos conceptos de probabilidad y estadística. La Distribución de Poisson es una función utilizada para modelar la probabilidad de que un evento o número de eventos ocurran a lo largo de un tiempo dado. Para no complicarnos la vida, con una función de Poisson podemos demostrar que la probabilidad de que un número de usuarios concurrentes sea menor que C + (3 x SQRT(C)) es de 99.87%. Es decir, el pico máximo de usuarios es tal que:

Cmax ≈ C + 3 √C, con una probabilidad de 99.87%

Utilizando el ejemplo más elaborado, podemos calcular el pico de acuerdo a las siguientes premisas: resulta que durante la semana de quincena, el 80% de los usuarios utiliza el sistema de nómina de Patito Labs en los horarios de 10:30 am a 13:30 pm, y de 3:30 pm a 5:30 pm (5 horas de "pico" en total). Esto porque la mayoría ingresa al sistema poco después de que éste entra en operación y en el periodo cercano a la hora de la salida. Así pues:

T = 5 días x 5 horas x 60 minutos = 1,500 minutos de horas pico en la semana de mayor uso.
n = 59,500 usuarios x 0.8 = 47,600 usuarios durante las horas pico.
L = 5 minutos.

C = n L / T = (47,600 x 5) / 1,500 = 158.66, redondeado ≈ 159

Y el pico máximo de uso es de:

Cmax ≈ 159 + ( 3 x SQRT(159) ) = 196.83, redondeado ≈ 197

Por lo que con una confianza de 99.87%, podemos asegurar que el sistema deberá soportar un uso de 197 usuarios concurrentes en horas pico.

Nota: puede parecer extraña la diferencia entre los promedios del primer ejemplo y éste, pero los dos son correctos: El primero es un promedio durante toda la semana de quincena, y el segundo es un promedio durante las 5 horas pico de cada día de dicha semana.

Conclusiones

La cifra de usuarios concurrentes puede aproximarse de acuerdo al tiempo de sesión y número de usuarios totales. Si queremos mejores aproximaciones y ser más certeros para no volarnos la barda, tendremos que investigar a mayor detalle información como "horas pico" y "porcentaje de usuarios activos vs. usuarios registrados". De acuerdo al librito Software Estimation, de Steve McConnell, siempre será mejor primero contabilizar las cifras que buscamos; si esto no es posible, tendremos que calcularlas y si de plano el cliente no es de ayuda y nosotros tampoco tenemos de donde basarnos, tendremos que juzgar, aunque esto último es más bien una forma elegante de decir "me saqué este número de la manga".

6 comentarios

  1. Buen artículo, me dió la guía para estimar. Saludos !


  2. Estimados amigos, muchisimas gracias por este excelente artículo, solo quisiera hacer una pregunta. Porque utilizan en la formula
    C + (3 x SQRT(C))
    el numero ” 3 ”

    Me imagino que es una sugerencia pero quisiera saber en que se basaron para su calculo, gracias!


    • El 3 es el valor de la desviación estándar (sigma) esperado. Con la distribución de Poisson calcularemos la probabilidad para encontrar un elemento cualquiera a más o menos N desviaciones estándar del promedio:

      • con s = 1 existe un 68.26% de probabilidad de que un elemento cualquiera se encontrará a más menos una desviación estándar del promedio.
      • con s = 2 la probabilidad aumenta al 95.449%
      • con s = 3 la probabilidad es de 99.87%

      Puesto que queremos tener una confianza del 99.87%, estamos usando una desviación estándar de 3 sobre los elementos encontrados en la distribución. Incluso podrías usar otros valores como 1.5 o 2.2, pero por simplicidad es mejor utilizar una desviación estándar con valores enteros.


  3. EStimado autor, cual es la referencia bibliográfica de conde salen estos postulados?


    • Esta información estaba contenida en unos manuales de Sun Microsystems de hace ya algunos años. En la actualidad puedes encontrar el contenido en su correspondiente versión para Oracle, en esta dirección. Está bastante masajeado debido a la idiosincracia de Oracle (ellos no comparten información de este tipo), pero para una primera aproximación, está decente.

      Sin embargo, la teoría detrás de esto puedes encontrarla en el libro Probability and Statistics for Computer Scientists (Second Edition), de Michael Baron.


  4. Disculpen pero “n” no es un numero de usuarios sino el numero de sesiones en la aplicación de donde el calculo que hace el articulo es 170.000 empleados*50% de los que se esperan usen el sistema* 70% de probabilidad que lo usen en la semana pico.=47.600 sesiones. así que la formula es la Concurrencia = numero de sesiones*el tiempo de sesión/Tiempo de Jornada. Ejemplo en un sistema de CRM entran 5.000 reclamaciones Jornada y las tareas sobre el sistema (sesiones) ocupan 20 minutos en promedio y la jornada es de 8 Hrs o 480 Min,

    n(numero de sesiones)=# de reclamaciones= 5.000 Jornada

    Donde C= 5.000 sesiones*20Min/sesión/usuario Div 480 Min/Jornada=208 concurrentes

    El articulo original explica el concepto pero confunde con ejemplo.



Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: