Comment nous avons réduit jusqu'à 41 % l'attente des requêtes courtes
Une requête courte passait jusqu'à 41 % de son attente à ouvrir une connexion vers le fournisseur. Notre plateforme garde maintenant ces connexions ouvertes.
Chaque requête que vous envoyez à CArouter est transmise à un fournisseur qui sert le modèle demandé. Jusqu'à cette semaine, notre plateforme ouvrait une nouvelle connexion vers ce fournisseur à chaque requête.
Elle garde maintenant ses connexions vers les fournisseurs ouvertes d'une requête à l'autre. En production, une requête courte obtient sa réponse jusqu'à 41 % plus vite.
En bref
- Ce que voit un client. Le temps médian de réponse d'une requête courte est passé de 597 à 352 ms chez un partenaire en Europe, et de 752 à 663 ms sur nos propres serveurs.
- Ce que nous avons changé. Notre plateforme garde ses connexions vers les fournisseurs ouvertes et les réutilise. Sur une connexion déjà ouverte, une requête demande un seul aller-retour vers le fournisseur au lieu de trois.
- Ce qui a aussi changé. Une requête dispose d'un nombre fixe de tentatives. Un fournisseur complet n'en consomme plus.
- Ce que ça coûte. Après une période calme, la première requête ouvre encore une connexion.
Trois allers-retours pour une seule requête
Une requête voyage vers le fournisseur sur une connexion chiffrée. En ouvrir une demande deux échanges avant que le fournisseur lise le premier mot de la requête : le premier ouvre la connexion, le second prouve l'identité du fournisseur et met le chiffrement en place.
La requête elle-même est le troisième échange. Chacun est un aller-retour entre notre plateforme et le fournisseur, et un aller-retour au-dessus de l'Atlantique prend environ un dixième de seconde.
Une longue réponse masque ce coût, parce que son écriture prend de nombreuses secondes. Une requête courte le montre en entier. Les agents en envoient par centaines : choisir un outil, classer un message, répondre par oui ou par non.
Ce qu'une nouvelle connexion ajoute
Nous l'avons mesuré depuis notre plateforme, en production, avec une requête qui demande à un fournisseur sa liste de modèles. Aucun modèle ne travaille sur cette requête : le chiffre est celui du trajet seul.
Une nouvelle connexion ajoutait de 240 à 300 ms à une requête sur nos propres serveurs, environ 80 ms chez un partenaire canadien, et de 420 à 750 ms chez nos partenaires en Europe.
Chaque requête payait ce temps, et chaque nouvelle tentative chez un autre fournisseur aussi.
Ce qui a changé dans notre plateforme
Notre plateforme ouvre maintenant une connexion vers un fournisseur une seule fois, puis y envoie les requêtes suivantes. Chaque requête en cours a sa propre connexion : aucune n'attend qu'une autre se termine.
Une connexion reste ouverte un court moment après sa dernière requête. Pendant ce temps, la plateforme vérifie que le chemin vers le fournisseur répond toujours, et elle ferme la connexion dont le chemin est coupé.
Une requête qui trouve sa connexion déjà fermée est renvoyée une fois, sur une nouvelle connexion, tant que le fournisseur n'a rien répondu. Toute autre panne suit le basculement que vous connaissez déjà : le fournisseur suivant qui sert le même modèle.
Ce que nous avons mesuré en production
Nous avons comparé la veille du changement et le lendemain, aux mêmes heures, pour les requêtes dont la réponse tient en 16 tokens ou moins. Le chiffre est le temps médian entre l'envoi de la requête au fournisseur et la réception de sa réponse complète.
Chez un partenaire en Europe, la médiane est passée de 597 à 352 ms, soit 41 % de moins. Sur nos propres serveurs, elle est passée de 752 à 663 ms, soit 12 % de moins.
Sur nos propres serveurs, la médiane a moins bougé que la mesure de connexion le laisse attendre. La charge d'un moteur varie d'un jour à l'autre, et cet écart peut peser autant sur la médiane qu'une connexion.
Un fournisseur complet ne consomme plus de tentative
Quand un fournisseur tombe en panne, notre plateforme envoie la requête au fournisseur suivant qui sert le même modèle, avant que le premier octet vous parvienne. Une requête dispose d'un nombre fixe de ces tentatives.
Chaque point d'accès d'un fournisseur a aussi une limite de requêtes traitées en même temps. Jusqu'à cette semaine, un point d'accès complet consommait une tentative, alors que rien ne lui avait été envoyé. Dans une minute chargée, une requête pouvait épuiser ses tentatives sur des points d'accès complets et être refusée pendant qu'un autre avait de la place.
Une tentative est maintenant une requête réellement envoyée. Les points d'accès complets sont passés sans rien coûter, et la requête va au premier point d'accès qui a de la place.
Les règles de routage sont les mêmes
- Une connexion gardée ouverte a passé à son ouverture la même vérification de certificat qu'une nouvelle, et elle sert ce fournisseur seulement.
- Une offre servie au Canada par un fournisseur de propriété canadienne est toujours essayée en premier. Une requête franchit une frontière seulement pour une clé API qui autorise les fournisseurs étrangers.
- Le passage d'un point d'accès complet au suivant respecte le même ordre. Une clé qui garde ses requêtes au Canada est refusée quand tous les points d'accès canadiens sont complets, exactement comme avant.
- Un point d'accès ajouté par un client lui-même reçoit une nouvelle connexion à chaque requête, parce que son adresse est vérifiée avant chacune.
Ce que nous avons vérifié avant la production
Nous avons d'abord testé le changement auprès des vrais fournisseurs, depuis un environnement séparé, avec environ 80 petites requêtes.
Un flux complet, un appelant qui raccroche au milieu d'un flux, plusieurs requêtes à la fois, et des réponses d'une minute sans rien d'envoyé entre-temps : tout s'est comporté comme avant. Chaque flux a été facturé une fois et a rendu sa place chez le fournisseur.
Ce que ça coûte
Après une période calme, la première requête ouvre une nouvelle connexion et paie les trois allers-retours.
Le gain est un nombre fixe de millisecondes par requête. Une longue réponse gagne les mêmes millisecondes, une petite part des nombreuses secondes que prend son écriture.
Pour une requête courte, c'est sur le trajet vers le fournisseur qu'un routeur gagne du temps.
Comparer les modèles et les fournisseurs disponibles. Consulter les règles techniques de routage.