Réveiller les bases de données sans connexions mortes
Les applications publiées sur Mythex, ainsi que leurs bases de données, passent en veille quand personne ne les utilise. Au réveil, une application pouvait retenir sa première requête pendant 10 à 12 secondes, parce qu'elle essayait de réutiliser des connexions à la base de données qui étaient mortes pendant que tout dormait. Nous donnons désormais aux applications Spring Boot des paramètres de base de données compatibles avec la mise en veille, et nous demandons à l'agent de construire les applications de toute pile de la même manière. Sur la plateforme d'hébergement, la première requête après un réveil est passée de 12,7 secondes à 2,3 secondes.
Pourquoi les applications et les bases de données se mettent en veille
Une application Mythex publiée tourne sur une machine qui se suspend après quelques minutes d'inactivité, et sa base de données est un Postgres sans serveur qui s'endort après cinq minutes d'inactivité et se réveille à la requête suivante. C'est ce qui maintient une application calme à bas coût : vous payez ce que la base de données a réellement utilisé, et une application en veille ne consomme rien en calcul. Nous avons écrit sur la facturation de cet aspect dans facturer les bases de données selon leur usage réel.
Le piège, c'est que les deux se mettent en veille séparément, et qu'ils ne sont pas d'accord sur ce qu'est une connexion.
Le symptôme : une première visite lente
La plupart des applications serveur gardent un pool de connexions : quelques connexions à la base de données ouvertes et prêtes, pour que chaque requête n'ait pas à payer le coût d'en ouvrir une nouvelle. C'est la bonne conception pour une application toujours active.
Voici ce qui se passe avec la mise en veille :
- L'application tourne, avec quelques connexions inactives dans son pool.
- Personne ne la visite. La machine de l'application se suspend — figée, avec son pool intact.
- La base de données s'endort et ferme son côté de chaque connexion.
- Un visiteur arrive. L'application se réveille exactement comme elle était, en gardant des connexions que la base de données ne connaît plus.
- Le pool remet l'une de ces connexions. Il doit découvrir qu'elle est morte — en la testant et en attendant — avant d'y renoncer.
Dans une application Spring Boot, la validation de ces connexions mortes bloquait la première requête pendant environ 10 secondes avant qu'elle n'échoue avec « Connection is not available ». Pour le visiteur, le site semblait simplement bloqué, puis affichait peut-être une erreur.
Pourquoi les applications Spring étaient les plus touchées
Spring Boot est un framework Java populaire, qui utilise par défaut un pool de connexions appelé HikariCP. Spring peut configurer ce pool à partir de paramètres, y compris le nombre de connexions inactives à conserver.
Mais Mythex fournit à chaque application sa base de données sous forme d'une seule variable DATABASE_URL au format postgresql://user:pass@host/db. Spring ne sait pas lire directement ce format. Les applications Spring construites sur Mythex créaient donc leur propre pool dans le code, en analysant cette URL — et un pool construit à la main ignore tous les paramètres spring.datasource.* de Spring. Même si quelqu'un connaissait les bons réglages du pool, ils n'avaient aucun effet.
La correction, partie 1 : des paramètres que Spring peut utiliser
Quand un projet dispose d'une base de données, il reçoit désormais aussi des variables d'environnement que Spring lit nativement :
SPRING_DATASOURCE_URL,SPRING_DATASOURCE_USERNAMEetSPRING_DATASOURCE_PASSWORD, convertis depuisDATABASE_URL(avec SSL requis sauf si l'URL l'indique autrement).- Des paramètres de pool qui survivent à la mise en veille :
| Paramètre | Valeur | Pourquoi |
|---|---|---|
| Nombre minimum de connexions inactives | 0 | Ne rien garder ouvert entre les requêtes, donc rien ne peut périmer |
| Délai d'inactivité | 30 secondes | Fermer rapidement les connexions inutilisées |
| Durée de vie maximale | 2 minutes | Retirer chaque connexion avant qu'elle ne vieillisse |
| Délai de connexion | 5 secondes | Ne pas bloquer longtemps une requête si la base tarde à répondre |
Sans connexion inactive conservée, une application réveillée ouvre une seule connexion neuve au lieu de traverser un lot de connexions mortes.
Quand ces variables sont présentes, Spring configure le pool lui-même, et les paramètres s'appliquent. Ce que le projet a déjà défini prime toujours ; nous ne complétons que ce qui manque. Les applications non Spring ignorent ces variables.
Le détail qui a failli ne rien faire
Spring associe les variables d'environnement à ses paramètres selon une règle facile à mal appliquer. Le paramètre minimum-idle doit s'écrire SPRING_DATASOURCE_HIKARI_MINIMUMIDLE — tirets supprimés, mots accolés. L'écrire SPRING_DATASOURCE_HIKARI_MINIMUM_IDLE, qui semble plus naturel, correspond à un paramètre différent et inexistant (minimum.idle) et est ignoré sans bruit.
C'est le genre d'erreur qui passe toutes les relectures et ne fait rien en production. Un test vérifie donc à la fois que les valeurs sont définies et qu'aucune variable n'utilise la forme avec tirets bas.
La correction, partie 2 : toutes les autres piles
Spring n'est pas le seul framework à disposer d'un pool, et nous ne pouvons pas préconfigurer chaque bibliothèque dans chaque langage. L'agent Mythex — l'IA qui écrit votre application — reçoit donc désormais une instruction permanente pour toute pile : les applications publiées et leurs bases de données se mettent en veille quand elles sont inactives, donc une connexion gardée ouverte peut être morte à la requête suivante. Il doit :
- ne garder aucune connexion inactive ouverte, ou vérifier chacune avant utilisation,
- réessayer une fois en cas d'erreur de connexion, et
- utiliser les paramètres de base de données que la plateforme fournit dans l'environnement, plutôt que de construire son propre pool en analysant
DATABASE_URL.
Ce dernier point boucle la boucle avec la partie 1 : une application construite sur les paramètres fournis reçoit automatiquement la configuration compatible avec la mise en veille.
Le résultat
Mesuré sur la plateforme d'hébergement où nous faisons tourner les applications publiées, la première requête après un réveil est passée de 12,7 secondes à 2,3 secondes.
Ce que nous en avons retenu
- Chaque couche qui s'endort doit s'accorder sur ce qui survit. Une application figée et une base de données endormie ont fait chacune un choix raisonnable. Ensemble, l'application se réveillait avec un état qui n'était plus vrai.
- Les valeurs par défaut conçues pour des serveurs toujours actifs ne conviennent pas aux applications qui descendent à zéro. Garder les connexions au chaud est une bonne idée tant que tout ce qui les entoure ne refroidit pas.
- Donnez aux frameworks leurs données dans leur propre format. Une URL unique était simple pour nous, mais elle obligeait chaque application Spring à fabriquer à la main un pool qui ignorait sa propre configuration.
- Testez qu'un paramètre est orthographié comme le framework le lit. Une valeur correcte sous le mauvais nom ne fait rien, sans prévenir.
Si vous découvrez le fonctionnement des bases de données sur Mythex, consultez la documentation sur les bases de données et notre article explicatif sur ce qu'est Postgres.