Warum Performance entscheidend ist
Performance wirkt sich direkt auf die Nutzererfahrung und die Betriebskosten aus. Endnutzer benötigen während ihrer Gesundheitsversorgung schnellen Zugriff auf Daten – jede Millisekunde Verzögerung summiert sich über Tausende täglicher Interaktionen und beeinflusst die klinische Effizienz sowie die Patientenergebnisse. Über die Nutzererfahrung hinaus bestimmt Performance die Infrastrukturkosten: Datenbankgröße, Backup-Umfang, Rechenressourcen und Wartungsaufwand skalieren alle mit dem Datenvolumen.
Bei der Wahl eines FHIR-Servers ist Performance einer der wichtigsten Faktoren. Jedes System, das auf FHIR aufbaut – EHR/PHR, CDR-Lösungen, Analyseplattformen – hat unterschiedliche Workload-Muster und erfordert unterschiedliche Performance-Eigenschaften. Für einen generischen FHIR-Server sind jedoch drei zentrale Workloads universell:
- CRUD – Erstellen, Lesen, Aktualisieren und Löschen einzelner Ressourcen
- Batch-Verarbeitung – Massenimport, Datenaustausch und Integrationsszenarien
- Suche – Abfragen von Ressourcen anhand verschiedener Parameter
FHIR-Batch-Verarbeitungs-APIs werden häufig für Datenaustausch und Integration eingesetzt – beispielsweise beim Migrieren von Daten aus Legacy-Systemen in einen FHIR-Server. CRUD- und Suchoperationen treiben OLTP-Workloads an: den Aufbau von EHR/PHR-Systemen, patientenorientierten Anwendungen und klinischen Entscheidungsunterstützungswerkzeugen.
Was wir benchmarken
Wir werden mehrere gängige Open-Source-FHIR-Server benchmarken und sie mit Aidbox vergleichen.
Für jeden Server messen wir:
- Durchsatz – Operationen pro Sekunde unter anhaltender Last
- Latenz – p99-Antwortzeiten
- Ressourcenverbrauch – CPU-, Arbeitsspeicher- und I/O-Auslastung
- Speicherplatzbedarf – wie viel Speicher jeder Server für denselben Datensatz benötigt
Wir haben die Testsuite so konzipiert, dass das Performance-Verhalten sowohl auf einer leeren Datenbank als auch nach einem erheblichen Datenvolumen erfasst wird. Dies ist entscheidend – viele Server liefern bei kleinen Datensätzen gute Ergebnisse, degradieren jedoch mit wachsendem Datenbestand.
Stufe 1: Leere Datenbank
Ausgehend von einer Neuinstallation:
- Basis-Performance der CRUD-Operationen messen
- 1.000 synthetische Patientendatensätze per Batch importieren (generiert mit Synthea)
- Performance verschiedener Suchoperationen auswerten
Damit wird die Basislinie etabliert – das Best-Case-Szenario für jeden Server.
Stufe 2: 100.000 Patienten laden
100.000 synthetische Patientendatensätze importieren und Folgendes messen:
- Gesamtdauer des Imports
- Datenbankgröße auf dem Datenträger
- Ressourcenverbrauch während des Imports
Dies simuliert ein realistisches mittelgroßes Deployment und zeigt, wie jeder Server mit anhaltend hohem Schreibdruck umgeht.
Stufe 3: Inkrementelle Lasttests
Mit bereits 100.000 Patienten in der Datenbank:
- CRUD-Operationen erneut ausführen – Vergleich mit der Basislinie der leeren Datenbank
- Zusätzliche 1.000 Patientendatensätze auf den bestehenden 100.000 importieren
- Suchoperationen erneut ausführen – messen, wie sich die Abfrage-Performance mit dem Datenvolumen verändert
Die Differenz zwischen Stufe 1 und Stufe 3 erzählt die eigentliche Geschichte: Wie gut hält die Performance stand, wenn die Datenmenge wächst?
Bleiben Sie auf dem Laufenden
Wir werden alle Benchmarks, Testskripte und Rohergebnisse in kommenden Beiträgen veröffentlichen. Folgen Sie uns auf LinkedIn, um keine Updates zu verpassen.
Haben Sie Fragen zur Performance von FHIR-Servern? Kontaktieren Sie uns – wir optimieren Aidbox seit über einem Jahrzehnt für groß angelegte Deployments.
