Por qué importa el rendimiento
El rendimiento afecta directamente tanto a la experiencia del usuario como a los costes operativos. Los usuarios finales necesitan acceso rápido a los datos durante su proceso asistencial: cada milisegundo de retraso se acumula a lo largo de miles de interacciones diarias, afectando a la eficiencia clínica y a los resultados de los pacientes. Más allá de la experiencia de usuario, el rendimiento determina los costes de infraestructura: el tamaño de la base de datos y las copias de seguridad, los recursos de cómputo y la carga de mantenimiento escalan con el volumen de datos.
A la hora de elegir un servidor FHIR, el rendimiento es uno de los factores más importantes. Cada sistema construido sobre FHIR — soluciones EHR/PHR, CDR, plataformas de análisis — tiene patrones de carga distintos y requiere características de rendimiento diferentes. Sin embargo, para un servidor FHIR de propósito general, tres tipos de carga de trabajo son universales:
- CRUD — crear, leer, actualizar y eliminar recursos individuales
- Procesamiento por lotes — importación masiva, intercambio de datos y escenarios de integración
- Búsqueda — consulta de recursos mediante diversos parámetros
Las API de procesamiento por lotes de FHIR se utilizan habitualmente en el intercambio de datos e integración; por ejemplo, para migrar datos de sistemas heredados a un servidor FHIR. Las operaciones CRUD y de búsqueda impulsan las cargas de trabajo OLTP: construcción de sistemas EHR/PHR, aplicaciones orientadas al paciente y herramientas de apoyo a la decisión clínica.
Qué estamos evaluando
Evaluaremos varios servidores FHIR de código abierto populares y los compararemos con Aidbox.
Para cada servidor, mediremos:
- Rendimiento — operaciones por segundo bajo carga sostenida
- Latencia — tiempos de respuesta p99
- Consumo de recursos — utilización de CPU, memoria y E/S
- Uso de disco — cuánto almacenamiento necesita cada servidor para el mismo conjunto de datos
Hemos diseñado el conjunto de pruebas para capturar cómo se comporta el rendimiento tanto en una base de datos vacía como tras un volumen de datos significativo. Esto es crítico: muchos servidores funcionan bien con conjuntos de datos pequeños, pero se degradan a medida que los datos crecen.
Fase 1: Base de datos vacía
Partiendo de una instalación limpia:
- Medir el rendimiento de referencia de las operaciones CRUD
- Importar por lotes 1.000 registros sintéticos de pacientes (generados con Synthea)
- Evaluar el rendimiento de distintas operaciones de búsqueda
Esto establece la línea base: el escenario óptimo para cada servidor.
Fase 2: Cargar 100 000 pacientes
Importar 100.000 registros sintéticos de pacientes y medir:
- Duración total de la importación
- Tamaño de la base de datos en disco
- Consumo de recursos durante la importación
Esto simula un despliegue de tamaño medio realista y revela cómo gestiona cada servidor una presión de escritura sostenida.
Fase 3: Pruebas de carga incremental
Con 100 000 pacientes ya en la base de datos:
- Volver a ejecutar las operaciones CRUD y comparar con la línea base de la base de datos vacía
- Importar 1.000 registros adicionales de pacientes sobre los 100 000 existentes
- Volver a ejecutar las operaciones de búsqueda y medir cómo varía el rendimiento de las consultas con el volumen de datos
La diferencia entre la Fase 1 y la Fase 3 cuenta la historia real: ¿cómo se mantiene el rendimiento a medida que crecen los datos?
Próximas publicaciones
Publicaremos todos los benchmarks, los scripts de prueba y los resultados sin procesar en próximas entradas. Síganos en LinkedIn para no perderse las actualizaciones.
¿Tiene preguntas sobre el rendimiento de los servidores FHIR? Contáctenos — llevamos más de una década optimizando Aidbox para despliegues a gran escala.
