Solon Server Threads : optimisation automatique des pools de threads sans configuration
Il était 2 heures du matin, et le chat d'astreinte vibrait d'alertes : le service de commandes semblait sain sur tous les tableaux de bord, pourtant le débit stagnait à environ 800 requêtes par seconde tandis que les temps de réponse P99 dépassaient quatre secondes. Le coupable ? Un pool de threads dimensionné par intuition six mois plus tôt lors d'un déploiement nocturne. Désormais, Solon propose une approche sans configuration : tous les paramètres des pools de threads sont réglés sur zéro par défaut, déclenchant un ajustement automatique en fonction des cœurs CPU de la machine au moment de l'exécution. Plus d'actes héroïques en pleine nuit, plus de valeurs par défaut manuellement calibrées qui deviennent obsolètes avec le temps.
Les cinq paramètres gérés automatiquement
Solon expose cinq points de configuration dans app.yml, tous initialisés à zéro — ce qui signifie « automatique ». Vous pouvez les laisser inchangés pendant des mois :
server.http.coreThreads– nombre minimal de threads (0 = automatique)server.http.maxThreads– nombre maximal de threads (0 = automatique)server.http.idleTimeout– délai d'inactivité des threads en millisecondes (0 = automatique)server.http.ioBound– la charge de travail est-elle liée aux E/S ? (valeur par défaut : true)solon.threads.virtual.enabled– activer les threads virtuels (valeur par défaut : false)
L'absence de valeur par défaut figée pour coreThreads ou maxThreads est frappante. Zéro signifie « déduis-en la valeur à partir du matériel », éliminant ainsi le piège courant qui consiste à copier des seuils de réglage adaptés à un serveur 32 cœurs, mais inadaptés à votre conteneur 2 cœurs.
Charge CPU vs charge E/S : un seul paramètre détermine l'algorithme
L'auto-réglage n'a besoin que d'une seule information : votre charge de travail est-elle liée au CPU ou aux E/S ?
- Charge liée au CPU – le traitement s'effectue entièrement dans le CPU et la mémoire ; des threads supplémentaires n'apportent rien et ajoutent des frais de commutation de contexte.
- Charge liée aux E/S – les opérations impliquent le réseau ou le disque ; chaque requête peut prendre plusieurs secondes, bloquant les threads en attendant.
En définissant server.http.ioBound: true (valeur par défaut), l'outil de réglage multiplie coreThreads par 2 et maxThreads par 32 sur une machine typique à 2 cœurs et 4 Go de RAM. En le basculant à false, la même machine obtient coreThreads × 2 et maxThreads × 8, maintenant le pool léger lorsque le CPU est le goulot d'étranglement.
Calculer soi-même en deux minutes
Avant de modifier un paramètre par défaut automatique, évaluez son impact :
- Plafond de débit : si une requête prend 0,1 s, un thread peut traiter environ 10 requêtes par seconde ; 100 threads ≈ 1000 QPS.
- Coût mémoire : chaque thread consomme au moins 1 à 2 Mo ; 100 threads ≈ 200 Mo même au repos.
L'auto-réglage gère ces compromis automatiquement, transformant ce qui était autrefois un casse-tête nocturne en problème résolu.
Pourquoi c'est important
Les pools de threads manuellement ajustés sont fragiles ; ils vieillissent avec chaque changement de code, redimensionnement de conteneur ou pic de trafic. L'auto-réglage sans configuration de Solon supprime cette fragilité en déduisant les paramètres à partir du matériel réel et du type de charge. Les équipes peuvent cesser de lutter contre l'épuisement des pools de threads et se concentrer sur les fonctionnalités. Pour les opérateurs gérant des charges mixtes sur de petits conteneurs et de grosses machines virtuelles, c'est une révolution discrète en matière de simplicité opérationnelle.
Source : DEV Community. Synthèse éditoriale assistée par IA — TechnoExpress.