Warum Performance wichtig ist
Performance wirkt sich direkt auf die Benutzererfahrung und die Betriebskosten aus. Endnutzer benötigen schnellen Zugriff auf Daten während ihrer Behandlung – jede Millisekunde Verzögerung summiert sich über Tausende täglicher Interaktionen und beeinflusst die klinische Effizienz sowie die Patientenergebnisse. Über die Benutzererfahrung hinaus bestimmt Performance auch die Infrastrukturkosten: Datenbankgröße, Backup-Größe, 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 aufgebaut ist – EHR/PHR, CDR-Lösungen, Analyseplattformen – hat unterschiedliche Workload-Muster und erfordert unterschiedliche Performance-Eigenschaften. Für einen generischen FHIR-Server sind jedoch drei grundlegende 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 beim Datenaustausch und bei der Integration eingesetzt – beispielsweise bei der Migration von Daten aus Legacy-Systemen in einen FHIR-Server. CRUD- und Suchoperationen unterstützen OLTP-Workloads: den Aufbau von EHR/PHR-Systemen, patientenorientierten Anwendungen und klinischen Entscheidungsunterstützungstools.
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-, Speicher- und I/O-Auslastung
- Festplattennutzung — wie viel Speicherplatz jeder Server für denselben Datensatz benötigt
Wir haben die Testsuite so konzipiert, dass sie das Performance-Verhalten sowohl auf einer leeren Datenbank als auch nach einem erheblichen Datenvolumen erfasst. Dies ist entscheidend – viele Server arbeiten bei kleinen Datensätzen gut, verschlechtern sich jedoch mit wachsenden Daten.
Stufe 1: Leere Datenbank
Ausgehend von einer Neuinstallation:
- Baseline der CRUD-Operationsperformance messen
- 1.000 synthetische Patientendatensätze im Batch importieren (generiert mit Synthea)
- Performance verschiedener Suchoperationen auswerten
Dies ermittelt die Baseline – das bestmögliche Szenario für jeden Server.
Stufe 2: 100.000 Patienten laden
100.000 synthetische Patientendatensätze importieren und messen:
- Gesamte Importdauer
- Datenbankgröße auf dem Datenträger
- Ressourcenverbrauch während des Imports
Dies simuliert eine realistische mittelgroße Bereitstellung und zeigt, wie jeder Server mit anhaltendem Schreibdruck umgeht.
Stufe 3: Inkrementeller Lasttest
Mit bereits 100.000 Patienten in der Datenbank:
- CRUD-Operationen erneut ausführen – mit der Baseline der leeren Datenbank vergleichen
- Weitere 1.000 Patientendatensätze zusätzlich zu den bestehenden 100.000 importieren
- Suchoperationen erneut ausführen – messen, wie sich die Abfrageperformance mit dem Datenvolumen verändert
Das Delta zwischen Stufe 1 und Stufe 3 zeigt die eigentliche Aussage: Wie gut hält die Performance mit wachsenden Daten stand?
Bleiben Sie informiert
Wir werden alle Benchmarks, Testskripte und Rohergebnisse in kommenden Beiträgen veröffentlichen. Folgen Sie uns auf LinkedIn, damit Sie keine Updates verpassen.
Haben Sie Fragen zur Performance von FHIR-Servern? Kontaktieren Sie uns – wir optimieren Aidbox seit über einem Jahrzehnt für groß angelegte Bereitstellungen.
