--- { "title": "Health Samurai Lab: Game of Pools", "description": "Realizamos pruebas de carga con la configuración de pools de Aidbox. 80 configuraciones muestran cómo los hilos web y los pools de base de datos afectan al rendimiento y la latencia.", "date": "2026-02-09", "author": "Marat Surmashev", "reading-time": "10 minutes", "tags": [ "Health Samurai Lab", "Database", "Infrastructure" ] } --- > For the complete documentation index, see [llms.txt](https://www.health-samurai.io/llms.txt). > Use it to discover all available pages before guessing URLs. --- 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](https://github.com/Aidbox/examples/tree/main/samurai-lab/game-of-pools). ## 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: ```javascript 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: ```javascript 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 ![Chart 1](image-1.svg) ![Chart 2](image-2.svg) #### Configuración con 4 CPU ![Chart 1](image-3.svg) ![Chart 2](image-4.svg) #### Configuración con 6 CPU ![Chart 1](image-5.svg) ![Chart 2](image-6.svg) #### Configuración con 8 CPU ![Chart 1](image-7.svg) ![Chart 2](image-8.svg) ### 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](/blog/aidbox-horizontal-vs-vertical-scaling)**: 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: | Núcleos CPU | Caso de uso | Hilos WEB | Tamaño del pool de BD | | --- | --- | --- | --- | | 2 | Equilibrado (Recomendado) | 3 | 6 | | 2 | Latencia baja | 2 | 4 | | 2 | Alto rendimiento | 4 | 8 | | 4 | Equilibrado (Recomendado) | 6 | 12 | | 4 | Latencia baja | 4 | 8 | | 4 | Alto rendimiento | 8 | 16 | | 6 | Equilibrado (Recomendado) | 9 | 18 | | 6 | Latencia baja | 6 | 12 | | 6 | Alto rendimiento | 12 | 24 | | 8 | Equilibrado (Recomendado) | 12 | 24 | | 8 | Latencia baja | 8 | 16 | | 8 | Alto rendimiento | 16 | 32 | 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](https://www.health-samurai.io/contacts?utm_source=blog&utm_medium=article&utm_campaign=game-of-pools). 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](/blog/first-steps-to-get-your-fhir-based-solution-ready-for-production).