Tests de Rendimiento del Gestor Documental

En Athento nos preocupa que nuestros clientes disfruten de una Experiencia de Usuario -UE- excepcional con la Gestión Documental. Un factor fundamental es la velocidad de respuesta de la aplicación. Somos conscientes de éso, por eso disponemos de herramientas y procedimientos que nos permiten medir el rendimiento. Dedicamos tiempo a definir métricas, lanzar tests automatizados, y verificar empíricamente, después de cada puesta en producción y durante las fases de desarrollo de forma interna, que la experiencia de usuario sigue siendo excepcional.

¿Qué Medir?

Existen una serie de operaciones que, independientemente del uso particular que cada cliente le de al Gestor Documental, son clave y hay que controlar:

• Navegación - Tiempo en abrir un documento
• Subida de documentos - Tiempo que tarda el Gestor Documental en subir un documento

Estas métricas se aplican a distintos entornos simulados, con distintos niveles de estrés y concurrencia. La definición de los distintos Escenarios es clave para poder establecer un balanceo correcto entre las expectativas del usuario y el entorno en el que se encuentra su Gestor Documental.


En las pruebas, obtenemos las siguientes métricas:

• Transacciones por segundo
• "Throughput transaction" vs usuarios concurrentes
• Peticiones por segundo (hits/s)
• Tiempos de respuesta vs usuarios concurrentes

Remarcamos "Tiempos de respuesta" porque si bien el resto de métricas nos dan una información muy útil para controlar la salud del sistema, es sin duda el tiempo de respuesta (que no es independiente de los otros valores) el que marca la experiencia de usuario. Somos conscientes de ello.

Nota: Los threads son un aspecto de configuración, razón por la que condicionamos las métricas al valor configurado.

¿Cómo medir el tiempo de respuesta?

A continuación, describimos dos pruebas automatizadas que nosotros usualmente utilizamos para medir los tiempos de respuesta de nuestras instancias y las de nuestros clientes.


Podemos realizar estas pruebas con JMetter, estableciendo parámetros en nuestras pruebas, por ejemplo:

• Número de documentos en el repositorio (este valor lo establecemos en el momento de la implantación, siendo variable cuando está en producción): 800.000 documentos.
• Número de usuarios simultáneos: 30, 40 y 50
• Ramp-up time (segundos): 60, 90 y 120
• Bucle (iteraciones): 10, 30, 50
• La representación de cada escenario es: Users/Rampup/Iterations (por ejemplo 30/60/10)

De cualquier manera, estos parámetros deberán estar en concordancia con las necesidades de nuestra compañía o características actuales de la instancia.

Para controlar las variables de las que hablabamos en el punto anterior definimos dos pruebas:

Prueba de Navegación básica

Se realizan los siguientes pasos:

1. Login
2. Navegación por Workspace y Carpeta hasta un tercer nivel 
3. Abrir un documento dentro de una Carpeta 
4. Navegamos por 4 TABS en el Documento: Sumario, Relaciones, Comentarios, Histórico.
5. Logout 

La realización de este test la podemos complementar con el uso de  Ghost Inspector. Este test en Ghost Inspector, nos va a permitir además, controlar que la aplicación se mantiene funcional a nivel de navegación y dispoibilidad de forma continua.

Además, tmbién nos da información sobre el tiempo que se toma el test:

Prueba de Creación de un documento (a través de la API) 

El test realiza los siguientes pasos:

1. Se comprueba si existe un determinado Workspace y si no existe, se crea (sólo ocurre la primera vez)
2. Se crea una Carpeta dentro del Workspace 
3. Creamos 10 documentos secuencialmente dentro de la Carpeta, a los que secuencialmente adjuntamos un fichero. 
4. Buscamos y obtenemos cada uno de los 10 documentos.

Este tipo de pruebas las podemos complementar mediante herramientas como Runscope.

¿Qué resultados son aceptables?

Debemos prestar atención a los siguientes datos:

• Tiempo medio de acceso a un documento durante la ejecución de los tests.
• Tiempo medio de escritura de un documento durante la ejecución de los tests.
• Número de usuarios concurrentes (máximo) en el que estos valores son válidos.

En el caso de los test de navegación, si tenemos usuarios entrando y navegando en el software, estos van a ser el mejor termómetro, y nos van a decir si las velocidades de la aplicación son aceptables o no. Por supuesto, tenemos que anticiparnos a esto. Podemos medir la duración media de los test.

Los test de utilización de la API también nos van a permitir saber qué tal va el rendimiento. En una instancia con 12 millones de documentos, podemos tener por ejemplo, un tiempo medio de creación de documento de 1031ms.