La ingestión de datos es uno de los primeros grandes obstáculos para cualquier adoptante de FHIR, ya sea que esté comenzando desde cero, poniendo en marcha un nuevo entorno o migrando desde un servidor existente. Cuando la ingestión está mal diseñada, los equipos se encuentran con migraciones lentas, referencias rotas y sistemas que se degradan bajo carga.
Este artículo forma parte de una serie que estamos publicando sobre la ingestión de datos FHIR en Aidbox. Cada artículo aborda un aspecto específico del problema. En este nos centramos en la cola HTTP de Aidbox: cómo funciona y qué aspectos hay que tener en cuenta.
Aidbox puede tratarse como un servidor web asíncrono y no bloqueante construido en torno a una cola de solicitudes y un número fijo de hilos trabajadores (BOX_WEB_THREAD). Cada solicitud entrante se coloca primero en la cola y luego es recogida para su procesamiento.
Cuando la tasa de solicitudes entrantes supera el número de trabajadores disponibles, las solicitudes comienzan a acumularse en la cola. Como consecuencia, el servidor deja de responder en tiempo real y la latencia aumenta. Bajo una carga sostenida, algunas solicitudes pueden no procesarse a tiempo y acabarán fallando debido a los tiempos de espera del lado del cliente.
La presencia de elementos en la cola HTTP indica que el sistema está bajo presión y recibe más solicitudes concurrentes de las que puede gestionar de inmediato. Una cola cercana a cero corresponde normalmente a una latencia baja, mientras que una cola pequeña puede ser aceptable e incluso beneficiosa para una utilización eficiente de los recursos. Sin embargo, un crecimiento sostenido en la longitud de la cola o en el tiempo de espera es una señal clara de sobrecarga: significa que los trabajadores están continuamente ocupados y no pueden seguir el ritmo del tráfico entrante.
Para ilustrar estas dinámicas con métricas concretas, hemos desarrollado tres escenarios técnicos diferenciados. Analizando estos ejemplos, podemos identificar estrategias eficaces para evitar los errores más comunes y establecer un modelo de comunicación cliente-servidor de alto rendimiento. Al final del artículo encontrará todas las recomendaciones prácticas.
Todos los escenarios se basan en el mismo perfil de carga de trabajo para garantizar la comparabilidad:
- Conjunto de datos fijo de 1200 bundles (p. ej., 100 por lote)
- El tamaño y la estructura de los bundles se mantienen constantes en todas las pruebas
- El cliente envía solicitudes de forma continua hasta el límite de concurrencia configurado
Esto nos permite aislar el efecto de la concurrencia y el comportamiento de los tiempos de espera sobre la cola HTTP sin introducir variabilidad procedente de la propia carga de trabajo.
Escenario 1: Concurrencia Ilimitada + Tiempo de Espera Corto del Cliente
En esta configuración, Aidbox está configurado con 8 hilos trabajadores (BOX_WEB_THREAD) ejecutándose en una única CPU, mientras que el cliente genera hasta 64 solicitudes concurrentes con un tiempo de espera de 10 segundos. A primera vista puede parecer un flujo de carga razonable, pero en la práctica crea un patrón clásico de sobrecarga impulsado por una concurrencia y un comportamiento de tiempos de espera desajustados.
Dado que la tasa de entrada es superior a la tasa de procesamiento, la cola comienza a crecer. Esto repercute directamente en la latencia ≈ (tiempo en cola + tiempo de procesamiento): cada solicitud ahora tiene que esperar más en la cola antes de ser recogida por un trabajador. Con el tiempo, el tiempo de espera supera el umbral de tiempo de espera del cliente de 10 segundos.
En ese momento se produce el siguiente comportamiento: el cliente cierra la conexión y considera que la solicitud ha fallado, pero el servidor no cancela el trabajo. La solicitud permanece en la cola (o ya está siendo procesada) y continúa consumiendo recursos hasta su finalización. Desde la perspectiva del servidor, sigue realizando un trabajo útil, pero desde la perspectiva del cliente, ese trabajo ya no tiene relevancia.
A medida que se acumulan los tiempos de espera agotados, el cliente comienza a emitir reintentos, que generan aún más solicitudes. Estas nuevas solicitudes se añaden encima de la cola ya creciente, que aún contiene trabajo obsoleto de solicitudes que agotaron su tiempo de espera anteriormente. Esto crea un bucle de retroalimentación positiva: más carga conduce a más tiempos de espera agotados, lo que desencadena reintentos e incrementa aún más la carga.
Escenario 2: Alta Concurrencia + Sin Tiempos de Espera del Cliente
En esta configuración, la configuración del servidor permanece igual — 8 hilos trabajadores en una única CPU — mientras que el cliente continúa enviando hasta 64 solicitudes concurrentes. La diferencia clave es que el cliente no aplica ningún tiempo de espera, lo que significa que está dispuesto a esperar indefinidamente una respuesta.
Al igual que en el Escenario 1, la tasa de solicitudes entrantes supera la capacidad de procesamiento del servidor. Las solicitudes se colocan en la cola HTTP y los trabajadores las procesan a una tasa fija. Sin embargo, como el cliente no agota el tiempo de espera, no se abandonan solicitudes ni se generan reintentos.
Como resultado, el sistema alcanza un estado estable. La cola crece inicialmente pero acaba estabilizándose en un nivel aproximadamente igual a la diferencia entre la concurrencia entrante y los trabajadores disponibles (en este caso, alrededor de ~56 solicitudes en cola). En lugar de una cola desbocada, tenemos ahora un retraso constante.
Desde el exterior, esto parece mucho más saludable: no hay tiempos de espera agotados, no hay errores y no hay tormentas de reintentos. Sin embargo, esta estabilidad tiene un coste en latencia. Cada solicitud debe esperar en la cola antes de ser procesada, lo que incrementa significativamente el tiempo de respuesta de extremo a extremo.
Es importante destacar que el rendimiento (RPS) permanece sin cambios en comparación con el Escenario 1. El sistema sigue estando limitado por el número de hilos trabajadores y la capacidad de CPU. Lo único que cambió es cómo se gestiona el exceso de carga: en lugar de descartarse (mediante tiempos de espera agotados), se absorbe en latencia.
Esto significa que el sistema opera en saturación constante: todos los trabajadores están continuamente ocupados y la cola actúa como un búfer que suaviza la sobrecarga a costa de la capacidad de respuesta.
En esta configuración de estado estable, toda solicitud entrante se ve obligada a pasar por el retraso existente (aproximadamente ~50 solicitudes en cola) antes de poder ser procesada. La cola se convierte en una barrera de latencia para todo el tráfico.
Dado que la cola es compartida, todos los tipos de solicitudes, incluidas las críticas como las comprobaciones de estado o las operaciones orientadas al usuario, están sujetas al mismo retraso. Aunque las solicitudes no se descartan, su éxito depende de si pueden tolerar este tiempo de espera acumulado.
Esto crea un riesgo sutil pero importante: el sistema parece estable, pero cualquier aumento en la sensibilidad a la latencia (p. ej., introducir tiempos de espera o añadir más tráfico) puede empujarlo rápidamente hacia el modo de fallo.
Escenario 3: Concurrencia Ajustada a la Capacidad de los Trabajadores
En esta configuración, la concurrencia del cliente está alineada con la capacidad de procesamiento del servidor: 8 solicitudes concurrentes frente a 8 hilos trabajadores en una única CPU. A diferencia de los escenarios anteriores, el sistema ya no está sobrecargado: la tasa de solicitudes entrantes se ajusta estrechamente a lo que el servidor puede gestionar.
Gracias a esta alineación, los trabajadores recogen las solicitudes casi de inmediato tras su llegada. La cola HTTP permanece cercana a vacía y el retraso por encolamiento queda prácticamente eliminado. Cada solicitud fluye a través del sistema con un tiempo de espera mínimo, lo que resulta en una latencia baja y predecible.
Desde el punto de vista del rendimiento, el sistema opera en su límite natural: el RPS coincide con la capacidad de los trabajadores y no hay inflación artificial ni degradación causada por reintentos o retrasos acumulados. El sistema parece estable, eficiente y bien equilibrado.
Sin embargo, esta configuración presenta una limitación importante. Dado que todos los trabajadores están continuamente ocupados con el tráfico del cliente, no hay capacidad de reserva para absorber carga adicional. Cualquier solicitud externa, como comprobaciones de estado, tareas en segundo plano o tráfico generado por usuarios, competirá de inmediato por los mismos trabajadores y comenzará a encolarse.
En otras palabras, el sistema opera a plena utilización sin margen de reserva. Aunque esto minimiza la latencia en condiciones controladas, hace que el sistema sea frágil en entornos reales donde el tráfico rara vez es perfectamente predecible.
Esta configuración es cercana a la ideal en términos de eficiencia: el sistema procesa solicitudes con latencia mínima y sin acumulación en la cola. Sin embargo, opera justo en el límite de su capacidad.
Con todos los trabajadores continuamente ocupados, no existe prácticamente ningún margen para absorber carga adicional. Incluso un pequeño aumento de tráfico o la presencia de solicitudes auxiliares empujará de inmediato al sistema hacia el encolamiento y el aumento de latencia.
En otras palabras, el sistema está perfectamente equilibrado, pero con mucha precisión, sin dejar margen para la variabilidad o las condiciones del mundo real.
Patrón de Carga Recomendado
Este modelo está simplificado intencionadamente y no es una representación exacta de cómo se comporta el sistema en la práctica, pero resulta útil para desarrollar la intuición. En realidad, un único trabajador puede a veces gestionar más de una solicitud de forma concurrente, dependiendo de la disponibilidad de CPU y de la naturaleza (tamaño y complejidad) de la carga de trabajo.
Como regla general, conviene pensar en términos de alineación: el número de solicitudes concurrentes del cliente dirigidas a Aidbox debería mantenerse generalmente por debajo del número de hilos web configurados. Cuanto más tráfico auxiliar o secundario (comprobaciones de estado, tareas en segundo plano, integraciones) necesite gestionar el sistema, más margen debe dejarse, es decir, menos solicitudes concurrentes del lado del cliente en relación con los trabajadores disponibles.
En otras palabras, no todos los trabajadores deben estar «reservados» para una única fuente de tráfico; debe quedar disponible cierta capacidad para todo lo demás que el sistema necesite procesar.
Una configuración eficaz depende de una observabilidad robusta. Mediante la monitorización de métricas clave como el volumen de solicitudes, la profundidad de la cola, la latencia, el RPS y los tiempos de espera agotados, puede identificar el equilibrio óptimo para su carga de trabajo específica. Este enfoque basado en datos le permite ajustar con precisión el número de trabajadores de Aidbox y los recursos de CPU asignados a su entorno.
Exploraremos más aspectos de la escalabilidad de Aidbox y la gestión de la carga de trabajo en próximos artículos.
Cómo configurar esto en Aidbox
Si trabaja con ingestión FHIR de alto rendimiento, puede ajustar la configuración de los trabajadores en Aidbox. Sin embargo, el ajuste del rendimiento va mucho más allá de simplemente aumentar el número de trabajadores: le recomendamos consultar el artículo que explica cómo los trabajadores web y las conexiones de base de datos (db) contribuyen conjuntamente al rendimiento de Aidbox.
Ponga en marcha su propia instancia de Aidbox en segundos para continuar experimentando, o póngase en contacto con nosotros para hablar sobre esta configuración.
