Gestión Restaurante

Test de Prestaciones

Recursos utilizados:

• Intel(R) Core(TM) i7-5700HQ CPU @ 2.70GHz

• 8GB DDR3 1600MT/s Kingston MSI16D3LS1MNG/8G

• Ubuntu 18.04.3 LTS

Para la medición de las prestaciones de nuestro sistema se ha usado Taurus. Taurus es una herramienta open source que nos permite pasar tests con JMeter,Selenium y otras herramientas fácilmente. Para ello solo es necesario la creación de un fichero yml donde se encontrarán las instrucciones para la ejecución del test.

En nuestro caso usaremos JMeter como herramienta para pasar los tests a nuestros servicios. Los ficheros yml creados para los tests son los siguientes:

Prestaciones: testvacio.yml

Test: ./TestsConexion/test.yml

1. Estado inicial del Servicio Mesas

En la siguiente imagen podemos ver el resultado que el servicio mesas obtuvo al pasar el test que carga el servicio con peticiones de 10 usuarios durante 1 minuto con el servidor de Tomcat7 embebido que proporciona Spring:

A continuación veremos como el ancho banda del servidor Tomcat capa a 1.1MB mas o menos.

• Tomcat

Para intentar conseguir una mejora de las prestaciones cambiaremos el servidor predeterminado de Spring, Tomcat7 por otros y veremos la carga que soportan:

• Jetty

Podemos ver como Jetty da un mejor rendimiento con altas cargas de trabajo, pero le cuesta más arrancar al principio.

• Undertow

Como podemos ver Undertow tiene un buen rendimiento en el arranque, sin embargo se ralentiza con cargas altas de usuarios

• Reactor Netty

Reactor Netty tiene un alto rendimiento con cargas bajas de usuarios y un rendimiento alto con altas cargas. Sin embargo tarda algo más en llegar a su tope de ancho de banda.

Con estos resultados delante podríamos aventurarnos a decir que Reactor Netty es el mayor competidor de Tomcat en términos de velocidad y aguante de carga. Sin embargo estos resultados están en local y sin bases de datos. A continuación se procede a la realización de las mismas pruebas con el estado del proyecto actual.

2. Estado actual del proyecto

Para estas pruebas, los servicios han sido containerizados con Docker y se ha implementado la conexión con las base de datos, las cuales también se encuentran en un contenedor Docker. Además se ha establecido una conexión entre ellos mediante REST para poder simular con la máxima fidelidad, que podemos alcanzar actualmente, el proceso de trabajo que realizan entre ellos. El estado actual del proyecto se puede ver en la siguiente imagen:

El despliegue de las imágenes y, por tanto, pruebas de carga será realizado en local. Las pruebas se realizarán con 10, 20 y 30 usuarios respectivamente para cada servicio con cada servidor. Esto es debido a que la velocidad al usar las bases de datos se reduce. En un primer momento se usó una única base de datos para todos los servicio pero, para ajustarnos más a la arquitectura inicial del sistema y aumentar la velocidad de éste, actualmente se usa una por servicio.

• Tomcat
• Mesas
• Cocina
• Camarero
• Todos
• Resultados
  • Peticiones por segundo media 1286 Hits/s
  • Ancho de banda medio 225 KiB/s
  • Tiempo de respuesta medio 13 ms
  • Error medio 0%
• Jetty
• Mesas
• Cocina
• Camarero
• Todos
• Resultados
  • Peticiones por segundo media 1393 Hits/s
  • Ancho de banda medio 111 KiB/s
  • Tiempo de respuesta medio 13 ms
  • Error medio 0%
• Undertow
• Mesas
• Cocina
• Camarero
• Todos
• Resultados
  • Peticiones por segundo media 1493 Hits/s
  • Ancho de banda medio 229 KiB/s
  • Tiempo de respuesta medio 12 ms
  • Error medio 0%
• Reactor Netty
• Mesas
• Cocina
• Camarero
• Todos
• Resultados
  • Peticiones por segundo media 1428 Hits/s
  • Ancho de banda medio 119 KiB/s
  • Tiempo de respuesta medio 13 ms
  • Error medio 0%

Discusión

Como podemos ver al usar la base de datos, los servidores, son hasta 6 veces más lentos de media que en las versiones previas.

El servicio camarero es más rápido que los demás servicios debido a que este no necesita mandar peticiones a ningún otro servicio, es totalmente independiente. Por lo que es una buena muestra de la velocidad que tendría un servicio por sí solo en los diferentes servidores.

Al hacer el test de carga a todos los servicios a la vez se puede ver una clara disminución de la velocidad de respuesta del servidor tardando hast el doble por petición.

Finalmente atendiendo a los resultados obtenidos:

• Tomcat
  • Peticiones por segundo media 1286 Hits/s
  • Ancho de banda medio 225 KiB/s
  • Tiempo de respuesta medio 13 ms
  • Error medio 0%
• Jetty
  • Peticiones por segundo media 1393 Hits/s
  • Ancho de banda medio 111 KiB/s
  • Tiempo de respuesta medio 13 ms
  • Error medio 0%
• Undertow
  • Peticiones por segundo media 1493 Hits/s
  • Ancho de banda medio 229 KiB/s
  • Tiempo de respuesta medio 12 ms
  • Error medio 0%
• Reactor Netty
  • Peticiones por segundo media 1428 Hits/s
  • Ancho de banda medio 119 KiB/s
  • Tiempo de respuesta medio 13 ms
  • Error medio 0%

Podemos ver como. el tiempo de respuesta y la tasa de error que nos proporcionan todos los servidores es la misma.(Los decimales han sido omitidos). Por lo que para la elección del servidor se ha atendido a las peticiones por segundo aceptadas y a su rendimiento al hacer los test de carga de todo el sistema al conjunto. Teniendo esto en cuenta los principales competidores son Reactor Netty y Undertow. Sin embargo Undertow ha demostrado una mejor competencia a la hora del test de carga total, por lo que se ha elegido este finalmente.

Java, al ser un lenguaje compilado, proporciona una mayor velocidad que los lenguajes interpretados. Además los servidores embebidos que proporciona Spring Boot están configurados por defecto para sacar un buen partido del servidor. Por ejemplo en nuestra elección final, Undertow, está configurado para que use todos los procesadores que estén disponibles y use 8 workers threads por cada procesador. Además usará toda la memoria que esté disponible para la Java Virtual Machine.

Finalmente en cuanto a la base de datos, Mongo, como hemos comentado anteriormente, se desplegó 3 veces, para que haya una base de datos para cada servicio. Cosa que, consecuentemente, aceleró la respuesta de peticiones del sistema.

Test Finales

Para finalizar el testeo de los servicios. Se han realizado unas ultimas pruebas de estos sobre el servidor escogido, Undertow. En ellas se ha limitado el numero de peticiones post y delete que se le hacian a los servicios. Esto imita mejor un entorno de ejecución estandar donde las consultas sobre datos son mucho mas frecuentes que la inserción o borrado de estos. Los resultados obtenidos son los siguientes:

• Peticiones por segundo media 1425 Hits/s
• Ancho de banda medio 279 KiB/s
• Tiempo de respuesta medio 13 ms
• Error medio 0%

Con esto podemos concluir que el servidor efectivamente cumple los requisitos mínimos que se esperaban de el.

Volver al Index