Pruebas de Rendimiento. Concurrencia.

concurrencia. (De concurrente).
 1. f. Acción y efecto de concurrir.

 2. f. Conjunto de personas que asisten a un acto o reunión.

 3. f. Coincidencia, concurso simultáneo de varias circunstancias.

 4. f. Asistencia, participación.

(Diccionario de la Lengua Española. R.A.E)

1 Uso concurrente de una aplicación.

En el ámbito de las pruebas de rendimiento son muy comunes los términos "concurrencia" y "simultaneidad". Ambas se utilizan indistintamente para dar información sobre el uso o la demanda que en un momento determinado está soportando una aplicación. Sin embargo, el concepto aparece con ciertas ambigüedades ya que por concurrencia podemos referirnos indistintamente al número de usuarios o a la demanda de operaciones atendidas (con independencia del número de usuarios). Tampoco aclara el intervalo en el que se ha medido la simultaneidad (minuto, hora, día..)

Para que las prueba de rendimiento cumplan su objetivo, es necesario diseñarlas intentando reproducir los niveles de demanda que la aplicación tendrá en la realidad. El comportamiento de la aplicación, incluido el tiempo de respuesta que perciben los usuarios, dependerá de la concurrencia que exista en un momento determinado sobre la aplicación. Por ello debemos fijar unos criterios que permitan definir con exactitud que entendemos por "concurrencia" en las pruebas de rendimiento.

2 Tipos de Concurrencia

• Concurrencia a Nivel de Aplicación: Nos indica el número de usuarios que se encuentran en la aplicación en un instante dado.

• Concurrencia a Nivel de Proceso de Negocio: Es el número de Operaciones de Negocio de un determinado tipo que se realizan en un determinado periodo de tiempo.

• Concurrencia a Nivel de Transacción: Indica el número de operaciones que se realizan de manera simultanea (en el mismo instante).

3 El diseño de las pruebas de rendimiento.

La información que aporta la concurrencia a nivel de aplicación no es suficiente para el diseño realista de pruebas de carga o rendimiento. El número de usuarios que en un instante están conectados a la aplicación no implica directamente una mayor demanda de operaciones, ya que no implica que se encuentren operando todos. Por otro lado, las operaciones que realizan los usuarios no conllevan el mismo consumo de recursos en los servidores, ya que existen funcionalidades más pesadas o que penalizan de manera más alta el rendimiento

Para el diseño efectivo de una pruebas de rendimiento que nos permitan validar que la aplicación va a soportar la demanda esperada en producción es necesario partir de datos de concurrencia a nivel de operación o consumo en los recursos. Algunos datos que podemos utilizar son:

• Número de operaciones por intervalo (hora, minuto, segundo, etc...).
• Pico máximo de operaciones realizadas en un momento dado.
• Throughput: Bytes/segundo, Paginas/segundo, Hits/segundo
• Conexiones físicas en los diferentes elementos de la plataforma: Balanceadores, Servidores, Base de Datos,...

Respecto al intervalo temporal, debemos partir de datos que representen la demanda real, tomar el dato de operaciones medio en un día puede llevar a infravalorar la carga que realmente va a soportar una aplicación ya que esta no se encuentra distribuida uniformemente. Por esa razón conviene dar las medidas en intervalos temporales más pequeños y que consideren los picos de momentos puntuales: Operaciones/hora, Operaciones/Minuto, etc..

No obstante, aunque el grueso de las pruebas de rendimiento las diseñemos a partir de datos operacionales, si nos es posible, debemos planificar al menos una prueba que introduzca en la aplicación un número elevado de usuarios. Aunque estos usuarios trabajen a un nivel  bajo conviene comprobar que los diferentes elementos de la plataforma funcionan correctamente, ya que el mero hecho de establecer una sesión tras un login tiene asociado un consumo de memoria en los servidores.