Health Samurai Lab: Game of Pools

Como la mayoría de las aplicaciones web, Aidbox consta de una cola de solicitudes web entrantes, un pool de trabajadores web que procesan las solicitudes y un pool de conexiones a la base de datos. Estos dos pools —trabajadores web y conexiones a la base de datos (db)— desempeñan un papel fundamental en el rendimiento de Aidbox. Juntos, determinan la eficiencia con la que se utilizan los recursos del servidor.

Aidbox permite configurar el tamaño de estos pools mediante los parámetros BOX_WEB_THREAD y BOX_DB_POOL_MAXIMUM_POOL_SIZE. Esto plantea la siguiente pregunta: ¿cuáles son los parámetros óptimos para mi instalación particular? El sentido común sugiere que el número de hilos web debe escalar con los núcleos de CPU disponibles en el servidor, mientras que el tamaño del pool de conexiones a la base de datos debe ser suficientemente grande para atender a todos los trabajadores web activos más una pequeña reserva para las tareas en segundo plano. Partiendo de esto, la recomendación de Health Samurai era BOX_WEB_THREAD = 2 × CPU_COUNT y BOX_DB_POOL_MAXIMUM_POOL_SIZE = 2 × BOX_WEB_THREAD. Esta recomendación es generalmente lógica y se alinea con la comprensión del funcionamiento de la pila web. Fue confirmada por nuestra experiencia en el mantenimiento de Aidbox. Sin embargo, hasta ahora no había sido validada mediante pruebas de carga sistemáticas bajo una carga sostenida.

Entorno de pruebas

Para aislar el rendimiento de Aidbox, ejecutamos todas las pruebas de forma local en un servidor dedicado, utilizando una base de datos local y una red local con discos NVMe rápidos para minimizar la sobrecarga de red y de E/S. Utilizamos la utilidad K6 para ejecutar las pruebas.

Las pruebas realizaron operaciones CRUD sobre nueve tipos de recursos distintos. Como resultado, medimos el rendimiento y la latencia.

El entorno de pruebas completo, los scripts y los resultados están disponibles en el repositorio.

Escenarios de prueba

Ahora unas palabras sobre cómo probamos Aidbox. Dado que queríamos probar diferentes configuraciones de límites de CPU (2, 4, 6, 8), resultaría poco práctico definir de antemano los tamaños de los pools para cada límite de CPU. En su lugar, utilizaremos multiplicadores:

CPU_LIMITS = [2, 4, 6, 8]
WEB_THREAD_MULTIPLIERS = [1, 1.5, 2, 2.5, 3]
DB_POOL_MULTIPLIERS = [1.5, 2, 2.5, 3]

¿Qué significa esto? Durante las pruebas, iteramos por todas las combinaciones posibles de estos parámetros. Por ejemplo, para 6 núcleos de CPU con un multiplicador web de 2 y un multiplicador de base de datos de 2,5, la configuración resultante es la siguiente:

services:
  aidbox:
    deploy:
      resources:
        limits:
          cpus: '6'                            # 6 CPU limit
    environment:
      BOX_INSTANCE_NAME: cpu_6__web_12__db_30
      BOX_WEB_THREAD: '12'                     # 6 * 2 (web multiplier)
      BOX_DB_POOL_MAXIMUM_POOL_SIZE: '30'      # 6 * 2 * 2.5 (web and db multiplier)

En total, ejecutamos 80 pruebas con todas las combinaciones de configuraciones posibles. Antes de cada prueba, realizamos un calentamiento, seguido de una prueba de estrés de 5 minutos sobre operaciones CRUD.

Una observación muy importante de las pruebas es que el tamaño del pool de base de datos debe ser mayor que el número de trabajadores web, porque durante el funcionamiento Aidbox reserva varias conexiones para tareas en segundo plano, lo que puede provocar errores al intentar obtener una conexión a la base de datos mientras se procesa una solicitud.

Resultados de las pruebas

Tras casi ocho horas de pruebas, podemos analizar los resultados. A continuación se muestran los gráficos detallados de análisis de rendimiento para cada configuración de CPU:

Configuración con 2 CPU

Configuración con 4 CPU

Configuración con 6 CPU

Configuración con 8 CPU

Observaciones clave de los gráficos

Los gráficos demuestran claramente:

• Rendimiento (RPS): El rendimiento máximo se obtiene con un multiplicador de hilos web = 1,5x y un multiplicador del pool de base de datos = 2-2,5x
• Latencia P99: La latencia mínima se observa con un multiplicador de hilos web = 1x y un multiplicador del pool de base de datos = 1,5-2x
• Escalado: Escalado de rendimiento prácticamente lineal al aumentar el número de núcleos de CPU
• Compromisos: Relación inversa clara entre rendimiento y latencia al aumentar el tamaño de los hilos WEB

Resumen

Los resultados de las pruebas muestran que nuestras recomendaciones anteriores y la comprensión general de cómo se comporta Aidbox bajo carga son correctas. Simplemente hemos obtenido una confirmación práctica en cifras.

En resumen, la recomendación general para BOX_DB_POOL_MAXIMUM_POOL_SIZE es 2 × BOX_WEB_THREAD. Aumentar el tamaño del pool de base de datos no proporciona ninguna ganancia de rendimiento y, en algunos casos, conduce a su degradación. Esta degradación no es significativa y se encuentra dentro del margen de error de medición, pero aun así resultó apreciable. En nuestros paneles detallados, con un tamaño de pool de base de datos aumentado, observamos una actividad GC más frecuente, lo que puede indicar una sobrecarga adicional por la gestión de un pool de conexiones a la base de datos de gran tamaño.

La recomendación general para BOX_WEB_THREAD es 1,5 × CPU_COUNT. Esto proporciona el mejor equilibrio entre rendimiento y latencia y es ideal para la mayoría de los proyectos.

Para proyectos como EHR, PHR, portales de pacientes y similares, donde hay muchas operaciones OLTP cortas y rápidas, y donde la capacidad de respuesta del sistema y la latencia mínima son más importantes para una mejor experiencia del usuario final, es preferible establecer BOX_WEB_THREAD en 1 × CPU_COUNT.

Para sistemas de tipo CDR donde hay muchas consultas de búsqueda y analíticas largas y complejas, muchas importaciones masivas y la mayor parte del trabajo recae sobre la base de datos, es preferible establecer BOX_WEB_THREAD en 2 × CPU_COUNT.

A continuación se muestra una tabla resumen con los parámetros recomendados:

Estos son parámetros recomendados de carácter general basados en pruebas sintéticas y no tienen en cuenta diversos aspectos del funcionamiento del sistema en su conjunto, como las importaciones, el mantenimiento de la base de datos, etc. En cualquier caso, para seleccionar los parámetros óptimos específicamente para su sistema, es preferible realizar pruebas similares en su propio entorno. Puede utilizar estas cifras como punto de partida desde el cual comenzar el ajuste fino de su sistema. Si necesita ayuda para ajustar Aidbox a su carga de trabajo o infraestructura, póngase en contacto con nosotros.

Una observación interesante que hemos encontrado hoy es el escalado de rendimiento prácticamente lineal al aumentar el número de núcleos de CPU. Pues bien, lo analizaremos en la próxima entrada del blog.

Marat Surmashev, VP de Ingeniería

Véase también: Preparando FHIR para producción.