Health Samurai Lab : Jeu de pools

Comme la plupart des applications web, Aidbox est composé d'une file d'attente de requêtes web entrantes, d'un pool de travailleurs web qui traitent les requêtes, et d'un pool de connexions à la base de données. Ces deux pools — les travailleurs web et les connexions à la base de données (BD) — jouent un rôle majeur dans les performances d'Aidbox. Ensemble, ils déterminent l'efficacité avec laquelle les ressources du serveur sont utilisées.

Aidbox vous permet de configurer la taille de ces pools grâce aux paramètres BOX_WEB_THREAD et BOX_DB_POOL_MAXIMUM_POOL_SIZE. Cela soulève la question suivante : quels sont les paramètres optimaux à spécifier pour mon installation en particulier ? Le bon sens suggère que le nombre de fils web devrait être proportionnel aux cœurs de processeur disponibles sur votre serveur, tandis que la taille du pool de connexions à la base de données devrait être suffisamment grande pour servir tous les travailleurs web actifs, plus une petite réserve pour les tâches d'arrière-plan. Sur cette base, la recommandation de Health Samurai était BOX_WEB_THREAD = 2 × CPU_COUNT et BOX_DB_POOL_MAXIMUM_POOL_SIZE = 2 × BOX_WEB_THREAD. Cette recommandation est généralement logique et s'aligne avec la compréhension du fonctionnement de la pile web. Elle a été confirmée par notre expérience dans la maintenance d'Aidbox. Cependant, elle n'avait jusqu'ici pas été validée par des tests de charge systématiques sous charge soutenue.

Environnement de test

Pour isoler les performances d'Aidbox, nous avons effectué tous les tests localement sur un serveur dédié, en utilisant une base de données locale et un réseau local avec des disques NVMe rapides afin de minimiser la surcharge réseau et les entrées/sorties. Nous avons utilisé l'utilitaire K6 pour exécuter les tests.

Les tests ont effectué des opérations CRUD sur neuf types de ressources différents. Nous avons ainsi mesuré le débit et la latence.

L'environnement de test complet, les scripts et les résultats sont disponibles dans le dépôt.

Scénarios de test

Quelques mots maintenant sur la façon dont nous avons testé Aidbox. Puisque nous souhaitions tester différentes configurations de limites de processeur (2, 4, 6, 8), il aurait été peu pratique de définir les tailles de pool à l'avance pour chaque limite de processeur. Nous avons plutôt utilisé des multiplicateurs :

CPU_LIMITS = [2, 4, 6, 8]
WEB_THREAD_MULTIPLIERS = [1, 1.5, 2, 2.5, 3]
DB_POOL_MULTIPLIERS = [1.5, 2, 2.5, 3]

Qu'est-ce que cela signifie ? Lors des tests, nous avons itéré sur toutes les combinaisons possibles de ces paramètres. Par exemple, pour 6 cœurs de processeur avec un multiplicateur web de 2 et un multiplicateur de base de données de 2,5, on obtient la configuration suivante :

services:
  aidbox:
    deploy:
      resources:
        limits:
          cpus: '6'                            # 6 CPU limit
    environment:
      BOX_INSTANCE_NAME: cpu_6__web_12__db_30
      BOX_WEB_THREAD: '12'                     # 6 * 2 (web multiplier)
      BOX_DB_POOL_MAXIMUM_POOL_SIZE: '30'      # 6 * 2 * 2.5 (web and db multiplier)

Au total, nous avons exécuté 80 tests couvrant toutes les configurations possibles. Avant chaque test, nous avons effectué un échauffement, suivi d'un test de stress de 5 minutes sur des opérations CRUD.

Une observation très importante issue des tests est que la taille du pool de base de données doit être supérieure au nombre de travailleurs web, car en cours de fonctionnement Aidbox réserve plusieurs connexions pour les tâches d'arrière-plan, ce qui peut entraîner des erreurs lors de tentatives d'obtention d'une connexion à la base de données pendant le traitement d'une requête.

Résultats des tests

Après près de huit heures de tests, nous pouvons examiner les résultats. Voici les graphiques d'analyse détaillée des performances pour chaque configuration de processeur :

Configuration 2 CPU

Configuration 4 CPU

Configuration 6 CPU

Configuration 8 CPU

Principales observations tirées des graphiques

Les graphiques démontrent clairement :

• Débit (RPS) : Le débit maximal est atteint avec un multiplicateur de fils web = 1,5x et un multiplicateur de pool BD = 2-2,5x
• Latence P99 : La latence minimale est observée avec un multiplicateur de fils web = 1x et un multiplicateur de pool BD = 1,5-2x
• Mise à l'échelle : Mise à l'échelle des performances quasi linéaire avec l'augmentation du nombre de cœurs de processeur
• Compromis : Relation inverse claire entre le débit et la latence lors de l'augmentation de la taille des fils WEB

Résumé

Les résultats des tests confirment nos recommandations antérieures et notre compréhension générale du comportement d'Aidbox sous charge. Nous avons simplement obtenu une confirmation pratique en chiffres.

En résumé, la recommandation générale pour BOX_DB_POOL_MAXIMUM_POOL_SIZE est 2 × BOX_WEB_THREAD. Augmenter la taille du pool de base de données n'apporte aucun gain de performance, et dans certains cas entraîne une dégradation. Cette dégradation n'est pas significative et se situe dans la marge d'erreur de mesure, mais elle était tout de même traçable. Sur nos tableaux de bord détaillés, avec une taille de pool BD accrue, nous avons observé une activité de collecte de mémoire (GC) plus fréquente, ce qui peut indiquer une surcharge supplémentaire liée à la gestion d'un grand pool de connexions à la base de données.

La recommandation générale pour BOX_WEB_THREAD est 1,5 × CPU_COUNT. Cela offre le meilleur équilibre entre débit et latence et convient parfaitement à la plupart des projets.

Pour les projets de type DSE, DSP, portail patient et similaires, où il y a de nombreuses opérations OLTP courtes et rapides, où la réactivité du système et une latence minimale sont plus importantes pour une meilleure expérience utilisateur, il est préférable de régler BOX_WEB_THREAD à 1 × CPU_COUNT.

Pour les systèmes de type CDR où il y a de nombreuses requêtes de recherche et analytiques longues et complexes, de nombreuses importations en lot, et où la majeure partie du travail incombe à la base de données, il est préférable de régler BOX_WEB_THREAD à 2 × CPU_COUNT.

Voici un tableau récapitulatif avec les paramètres recommandés :

Ce sont des paramètres recommandés à titre général, basés sur des tests synthétiques, et ne tiennent pas compte de divers aspects du fonctionnement de l'ensemble du système, tels que les importations, la maintenance de la base de données, etc. Dans tous les cas, pour sélectionner les paramètres optimaux spécifiques à votre système, il est préférable d'effectuer des tests similaires dans votre propre environnement. Vous pouvez utiliser ces chiffres comme point de départ à partir duquel commencer à affiner votre système. Si vous avez besoin d'aide pour optimiser Aidbox selon votre charge de travail ou votre infrastructure, communiquez avec nous.

Une observation intéressante que nous avons faite aujourd'hui est la mise à l'échelle des performances quasi linéaire avec l'augmentation du nombre de cœurs de processeur. Nous testerons cela dans notre prochain billet de blogue.

Marat Surmashev, VP Ingénierie

Voir aussi : Préparer FHIR pour la production.