🔥 FHIR TX Benchmark : Ronde 0

FHIR TX Benchmark — performance scores across terminology servers

Chez Health Samurai, la performance est au cœur de nos préoccupations.

Nous travaillons sur une série de benchmarks FHIR ouverts. Le premier que nous publions est le FHIR TX Benchmark : un benchmark de serveurs de terminologie comportant 20 cas de test, 5 serveurs, fonctionnant sur les mêmes données et le même matériel, en isolation.

Les serveurs de terminologie constituent souvent une composante critique de l'infrastructure d'un système et peuvent facilement devenir un goulot d'étranglement en matière de performance. Ils interviennent dans la validation, peuvent alimenter des éléments d'interface utilisateur, servir de moteur à la recherche et au filtrage, et sont de plus en plus intégrés dans des flux de travail alimentés par l'IA pour ancrer les agents dans la réalité.

Nous souhaitons que tout soit aussi transparent que possible : tous les scripts, tests, données, résultats et instructions sont disponibles sur GitHub. Un site Web en direct, généré à partir du dépôt, présente les résultats à l'adresse https://healthsamurai.github.io/tx-benchmark.

Sur la méthodologie et le biais

Health Samurai a conçu la version initiale de ce benchmark et notre propre serveur (Termbox, dont la sortie est prévue plus tard ce mois-ci) fait partie des cinq serveurs testés. Nous savons ce que cela peut laisser supposer. Notre réponse est la méthodologie elle-même : chaque test, chaque paramètre, chaque formule sont documentés et ouverts, les données sont reproductibles, et nous avons discuté avec les autres implémenteurs. À notre connaissance, aucun benchmark de ce genre n'existe pour les serveurs de terminologie FHIR. La méthodologie, la suite de tests et le système de notation sont ouverts à l'examen, et nous accueillons favorablement les suggestions, corrections et contributions de la communauté ainsi que des autres implémenteurs.

Méthodologie

La spécification du serveur de terminologie FHIR couvre plusieurs opérations, types de ressources, fonctionnalités avancées et cas d'utilisation. Cela représente un défi lorsqu'il s'agit de décider quoi tester et comment le tester. Les tests ont été sélectionnés pour leur pertinence en matière de performance ; par exemple, une recherche en texte intégral est importante pour les interfaces utilisateur et entraîne un coût d'implémentation très différent d'une simple recherche de code : nous disposons d'un test pour chacun.

La conformité n'était pas un objectif; nous disposons déjà d'une suite de tests de conformité complète dans l'IG Terminology Ecosystem.

Les capacités et les objectifs des serveurs varient : certains offrent un support partiel pour certaines opérations, d'autres sont conçus pour des cas d'utilisation spécifiques ou optimisés pour des terminologies particulières. Nous ne testons chaque serveur que sur les fonctionnalités qu'il prend en charge. La méthodologie complète est documentée sur la page de méthodologie.

Tests

Pour les tests, nous avons sélectionné certaines des principales opérations de terminologie : Lookup, Validate Code, Expand, Translate et Subsumes. Chaque test est identifié par un code court : les initiales de l'opération suivies d'un numéro de séquence : LK01 pour le premier test Lookup, EX02 pour le deuxième Expand, et ainsi de suite.

Nous avons souvent plusieurs tests pour la même opération. Cela nous permet de tester différents chemins pertinents pour la performance, différentes terminologies ou des fonctionnalités spécifiques d'une opération qui méritent leur propre test.

La liste complète des tests et leurs descriptions sont documentées sur la page des tests.

Données

Nous chargeons le même ensemble de données de terminologie dans chaque serveur (dans la mesure du possible). Les instructions et les exigences en matière de licences sont documentées dans le dépôt GitHub.

Les terminologies ont été sélectionnées en fonction de leur importance et de leur variété (structure, hiérarchie, propriétés, taille) ainsi que des différents types d'ensembles de valeurs. Les principales terminologies chargées pour cette ronde sont :

SNOMED International - 20260201
SNOMED US Edition - 20260301
SNOMED UK Edition - 20260211
LOINC - 2.82
RxNorm - Mars 2026
Un ensemble de paquets FHIR incluant r4 core, THO, US Core, VSAC et d'autres

Liste complète sur la page des données.

Notation

Le benchmark produit un score composite qui permet de comparer les performances globales des serveurs en un coup d'œil. Vingt tests répartis sur six opérations génèrent beaucoup de chiffres, et le score composite les distille en une seule valeur comparable. Nous nous sommes fortement inspirés des TechEmpower Framework Benchmarks et avons basé nos algorithmes sur les leurs.

La notation est fondée sur le débit. Chaque test est exécuté à trois niveaux de concurrence : 1, 10 et 50 utilisateurs virtuels. Nous conservons le débit le plus élevé parmi les trois (si un serveur atteint son pic à 10 utilisateurs virtuels et se dégrade à une concurrence plus élevée, nous utilisons le meilleur résultat pour la notation).

Normalisation : Les débits sont normalisés par rapport à LK01. Un test de recherche sera toujours plus rapide qu'une expansion complexe ; les requêtes par seconde brutes feraient dominer les tests « faciles » sur tout le reste, ce qui ne serait ni juste ni utile.

Biais : Nous multiplions les résultats des tests par un coefficient de biais. Cela nous permet de moduler l'impact d'un test sur le score global en fonction de son importance. Par exemple, la performance d'une recherche sur SNOMED devrait avoir plus de poids que la recherche d'un CodeSystem pour un serveur de terminologie, car la première fait plus souvent partie d'un chemin critique. Les coefficients sont documentés et ouverts aux commentaires (comme tout le reste).

Imputation : L'absence de support n'équivaut pas à de mauvaises performances. Attribuer un zéro pour les tests non pris en charge est trop sévère ; accorder un laissez-passer pour un test difficile n'est pas juste non plus. Les serveurs reçoivent une valeur imputée dérivée d'un percentile des résultats des serveurs participants.

Score global : Le meilleur performant global obtient un score de 100. Le score de chaque autre serveur est exprimé en pourcentage de celui-ci, tant pour chaque test que dans le score composite global.

Matériel et environnement

Les tests de charge sont effectués avec k6, avec Prometheus et cAdvisor pour la collecte de métriques. Tous les serveurs fonctionnent dans des conteneurs Docker sur le même hôte que le générateur de charge, en utilisant uniquement la boucle locale — sans latence réseau.

La Ronde 0 a été exécutée sur un ordinateur portable : Apple M3 8 cœurs, 24 Go de RAM, Docker Desktop configuré avec 8 processeurs et 20 Go. Les rondes futures s'exécuteront sur une machine virtuelle dédiée dans l'infonuagique avec des ressources nettement plus importantes, et le processus sera entièrement automatisé.

Résultats de la Ronde 0

La Ronde 0 est la ronde initiale et celle actuellement publiée sur le site Web. Il s'agit d'un essai pilote (nous avons travaillé avec les implémenteurs pour nous assurer que les serveurs sont correctement configurés, et les résultats pourraient encore être mis à jour au fur et à mesure que nous intégrons les commentaires). Après la Ronde 1, le processus sera automatisé et exécuté selon un calendrier régulier avec les dernières versions de chaque serveur et une suite de tests améliorée à mesure que nous recueillerons les commentaires.

Cinq serveurs sont inclus dans cette ronde : FHIRsmith, Hades, Ontoserver, Snowstorm et Termbox. Tous les serveurs n'ont pas exécuté tous les tests; cela est reflété dans le panneau de la matrice de capacités.

#	Serveur	Score
1	termbox	100%
2	fhirsmith	38%
3	ontoserver	21%
4	snowstorm	7%
5	hades	6%

Les résultats complets, les détails par serveur, les requêtes par seconde brutes et les percentiles de latence sont disponibles sur le site Web.

Prochaines étapes

La Ronde 1 arrive bientôt — exécutée sur une machine virtuelle dédiée dans l'infonuagique, automatisée, et avec de meilleures configurations fondées sur les commentaires de cette ronde. Par la suite, nous prévoyons de publier les résultats sur une base trimestrielle.

Nous envisageons ceci comme un projet communautaire. Health Samurai en est le responsable actuel, mais l'objectif est que ce projet soit gouverné et alimenté par la communauté FHIR au sens large — implémenteurs, utilisateurs et toute personne ayant un intérêt dans la performance des serveurs de terminologie.

Si vous souhaitez vous impliquer : suggérez de nouveaux tests, signalez une mauvaise configuration, proposez un serveur à inclure, ou ouvrez simplement un problème sur GitHub. Tous les commentaires sont les bienvenus.

Questions fréquentes anticipées

Nous nous attendons à ce que vous ayez de nombreuses questions. En voici quelques-unes que nous anticipons. N'hésitez pas à nous contacter si vous avez une question que nous n'abordons pas ici ou si vous souhaitez simplement nous dire que nous faisons fausse route.

« Le serveur X est mal configuré — cela explique les résultats. »: C'est tout à fait possible. Nous avons fait de notre mieux pour configurer chaque serveur correctement, mais nous ne sommes pas des experts pour tous. Si vous savez comment améliorer une configuration, veuillez ouvrir une demande de tirage ou signaler un problème et nous mettrons les résultats à jour.
« Pourquoi le serveur X n'est-il pas inclus? »: Il est possible que nous n'en soyons pas informés. Ouvrez un problème ou une demande de tirage avec les instructions de configuration et nous travaillerons à l'inclure dans une ronde future.
« Pourquoi ces tests? Pourquoi ne pas tester l'opération X? »: Les tests ont été sélectionnés pour leur pertinence en matière de performance. Si vous pensez qu'une opération ou un cas d'utilisation important est manquant, la suite de tests est destinée à évoluer — nous en avons déjà quelques-uns en tête pour la Ronde 1. Veuillez nous aider en ouvrant un problème.
« Health Samurai a créé ce benchmark et Termbox performe bien. N'est-ce pas un conflit d'intérêts? »: Nous avons abordé ce point au début de l'article. En résumé : la méthodologie, les données et la notation sont entièrement ouvertes et reproductibles. Il convient également de noter que Termbox a été conçu spécifiquement en mettant l'accent sur la performance — nous nous attendions à ce qu'il obtienne de bons résultats. Si vous trouvez une faille dans la méthodologie, veuillez ouvrir un problème.
« Les coefficients de biais et le percentile d'imputation pourraient être ajustés pour favoriser certains serveurs. »: Ce sont des décisions de jugement, et nous les avons documentées explicitement pour cette raison. Si vous n'êtes pas d'accord avec les pondérations, ouvrez un problème — nous sommes ouverts à les ajuster en fonction des commentaires de la communauté.
« Vous avez exécuté cela sur un ordinateur portable? »: Oui. La Ronde 0 est un essai pilote sur un Apple M3. Les chiffres changeront sur un matériel plus puissant, mais nous nous attendons à ce que les classements relatifs restent largement cohérents. Les rondes futures s'exécuteront sur une machine virtuelle dédiée dans l'infonuagique.
« Qu'en est-il de la mise en cache? La plupart des déploiements en production placent un cache devant le serveur. »: C'est vrai, et cela change considérablement la donne. Mais nous mesurons les performances du serveur, pas de l'architecture de déploiement. Les déploiements en production sont plus complexes, et nous en sommes conscients — mais c'est une autre chose à mesurer.
« Qu'en est-il du regroupement en grappe ou de la mise à l'échelle horizontale? »: Ce benchmark ne teste que les performances sur un nœud unique. La mise à l'échelle horizontale est une dimension valide, mais dépend fortement de l'architecture de déploiement, pas seulement du serveur lui-même.