Pauses GC Go dans un bidder RTB : mark assist, échéances et la décision Rust

Un bidder qui perd des enchères sur timeout alors que sa moyenne paraît saine est décrit par le mauvais chiffre. L'échéance appartient à l'ad exchange et couvre le réseau dans les deux sens. Un collecteur est une propriété du processus : sa pause est donc imputée à toutes les connexions à la fois, et un pic sur une seule connexion demande une autre explication.

Réécrire en Rust ou régler le runtime, c'est un choix entre deux réponses à une question que personne n'a posée : quelle part de l'échéance est dépensée, et à quoi. Ce qui suit sépare le budget du collecteur, le collecteur du scheduler, et la réécriture du composant qui la mérite.

L'échéance appartient à l'ad exchange, et elle couvre l'aller-retour

La spécification OpenRTB définit tmax comme le temps maximum en millisecondes que l'ad exchange accorde pour recevoir les bids, latence Internet incluse, et précise que cette valeur prime sur toute recommandation antérieure. Le budget est un aller-retour qui arrive à l'intérieur de chaque requête.

Le seuil sur lequel vous êtes jugé n'est pas celui de votre dashboard. La documentation Authorized Buyers de Google exige que 85 percent des réponses arrivent dans l'échéance, telle qu'elle est mesurée au trading location, et bride les bidders qui n'y parviennent pas. Entre son horloge et la vôtre se trouve tout ce qui n'est pas du calcul :

• L'aller-retour jusqu'à l'ad exchange, qui relève de la géographie et du peering avant de relever de l'ingénierie
• L'établissement de connexion quand le keepalive expire, car un nouveau handshake TLS à l'intérieur d'un budget d'enchère est une enchère perdue
• Le temps passé dans la file d'acceptation avant que votre handler ne voie la requête, et qui grandit précisément quand vous êtes le plus chargé
• La désérialisation, à un coût fixé par la part de la requête que vous transformez en objets, pas par sa taille

L'échéance interne se place donc sous le tmax, de ce que votre propre histogramme dit qu'une réponse coûte sur cette connexion, re-dérivée par ad exchange plutôt que fixée une fois pour toute la flotte. Une échéance n'est pas un plan de capacité : le travail annulé à l'échéance a déjà dépensé son CPU.

En surcharge, cela revient à payer le prix fort pour des réponses que personne ne compte : la réparation manquante est le contrôle d'admission. Lisez tmax, comparez-le au délai de file que vous mesurez, et répondez no-bid quand l'arithmétique ne tombe pas juste. Un no-bid rapide compte dans les 85 percent ; un bid tardif, non.

Un seul collecteur sert toutes les connexions : une connexion isolée est donc une autre panne

Un garbage collector est une propriété du processus : un cycle déclenché sur n'importe quelle connexion est donc facturé à toutes les connexions. Celle qui rate en premier est celle qui a le tmax le plus serré et la requête la plus lourde. Écartez ce qui produit la même image sans collecteur :

• Trop peu de connexions depuis un même ad exchange, puisque HTTP/1.1 porte une requête à la fois : le QPS par connexion multiplié par le temps de handler, proche de un, place la file d'attente sur la connexion
• Une seule connexion HTTP/2, où un paquet perdu bloque tous les streams qui la partagent - le head-of-line blocking que la RFC 9114 cite en 2022 comme la raison d'être de HTTP/3
• L'expiration du keepalive, un réglage par défaut plus souvent qu'une faute : http.Server.IdleTimeout retombe sur ReadTimeout quand il vaut zéro, tandis que Google demande un idle timeout de 2.5-minute et que nginx ferme à 75 seconds
• Un lookup de features synchrone que seuls certains ad exchanges déclenchent, où la queue de latence appartient à un store distant, pas à vous

Aucun des quatre ne se répare par un réglage du collecteur, et la décomposition dispose d'instruments. Un profil CPU sépare les factures du collecteur par symbole, runtime.gcAssistAlloc pour les charges du handler et runtime.gcBgMarkWorker pour le marquage en arrière-plan. Le temps stop-the-world est /sched/pauses/total/gc:seconds, l'attente en état runnable est /sched/latencies:seconds, et la file d'acceptation se lit hors du processus via ListenOverflows.

Le mark assist est la facture que paie votre bid request

Le collecteur Go est concurrent, et le guide officiel est explicite : la durée des pauses ne croît pas avec la taille du heap, donc les transitions stop-the-world sont brèves. Ce sont les assists qui comptent : les goroutines assistent le collecteur quand l'allocation est rapide, parce que le marquage en arrière-plan reçoit un quart fixe des processeurs et que le manque est imputé à celui qui alloue.

Le débit fait de cela un seuil plutôt qu'une pente. Le taux d'allocation, c'est le QPS multiplié par les octets par bid request, face à une part d'arrière-plan fixe : du code qui n'assiste jamais à un cinquième de votre trafic peut donc assister sur presque chaque requête à 100K QPS.

Le coût du marquage est proportionnel au graphe de pointeurs vivants, pas aux déchets, et un bidder détient exactement la mauvaise forme pour cela : index de campagnes, segments d'audience, caches de fréquence. Discord a publié le même constat en 2020, avec un collecteur qui parcourait tout un cache LRU pour décider si la mémoire était libre. Cinq mécanismes se cachent derrière une seule expression :

• Transitions stop-the-world : un pic identique sur toutes les connexions au même instant, rarement assez long pour perdre une enchère à lui seul
• Mark assist : aucune pause dans la trace, seulement du temps de handler qui a augmenté - lisez-le dans la part d'assist du CPU GC
• Coût du marquage : un CPU GC qui monte quand le heap vivant grossit alors que l'allocation n'a pas bougé, que des tableaux plats font baisser et que moins de déchets ne fait pas baisser
• Contention du scheduler : une requête qui reste runnable sans s'exécuter, ce que montre la métrique de latence du scheduler et que la métrique de pause ne montrera pas
• Le cycle forcé : un pic sur une période d'environ deux minutes sur une instance calme, qui pointe vers le plancher de collecte plutôt que vers votre trafic

Lisez cela comme cinq factures distinctes. Exactement une se règle par un réglage du collecteur, et aucune en changeant de langage avant d'avoir mesuré la décomposition.

Une boucle fermée efface la preuve dont vous aviez besoin

Gil Tene a nommé cette défaillance coordinated omission : le système de mesure se coordonne avec le système testé d'une manière qui évite de mesurer les valeurs extrêmes, parce qu'une boucle fermée attend une réponse et cesse d'émettre pendant un blocage. ScyllaDB a publié en 2021 une comparaison où une charge de travail rapportait un p99 de 249 microseconds en boucle fermée et de 665 ms sous charge ouverte avec correction, soit un facteur d'écart d'environ 2,700.

• Une charge en boucle ouverte à débit fixe, avec la latence comptée à partir de l'heure d'envoi prévue plutôt qu'à partir du moment où la requête est partie
• Une correction à la manière de HdrHistogram dès que le générateur ne met pas en file les requêtes qu'il n'a pas réussi à envoyer
• p99 et p99.9 plutôt qu'une moyenne, avec votre propre fan-out compté : Dean et Barroso ont montré en 2013 que toucher 100 serveurs avec un p99 d'une seconde laisse 63 percent des requêtes lentes
• Un profil de trafic copié sur l'ad exchange qui fait mal, exécuté plus longtemps que l'intervalle de collecte forcée et sous le même quota cgroup

Un générateur de charge qui attend une réponse cesse d'émettre pendant précisément le blocage qu'il devait trouver, puis fait entrer ce silence dans la moyenne du résultat. Le percentile qu'il affiche ensuite décrit le générateur, pas votre bidder.

Allouer moins d'abord, puis actionner trois leviers

Nommez le chiffre d'arrêt avant de régler quoi que ce soit, car une réécriture décidée par épuisement n'est pas une décision. Deux chiffres, pas un : les allocations de heap par requête, qui pilotent l'assist, et le heap vivant, qui pilote le marquage.

L'ordre est la source avant le plafond, pas le plus gros gain d'abord. Commencez là où l'assist est généré : escape analysis sur le chemin de bid, des buffers réutilisés au lieu d'être alloués, et un codec qui lit les champs dont vous avez besoin au lieu de matérialiser un nouveau graphe d'objets. Gardez ses slices à durée de vie courte : une slice pointant dans le buffer de requête retient tout ce buffer pendant toute la vie du bid.

• sync.Pool soulage la pression et ne promet rien : un élément peut être retiré à tout moment sans notification, et un objet du pool reste marqué entre sa restitution et son éviction
• Le live set, c'est la facture : reconstruisez les index de campagnes et de segments en tableaux plats hors du hot path, pour que le graphe marqué cesse de croître avec le nombre de campagnes
• GOGC échange de la mémoire contre du CPU de collecteur à un taux que le guide énonce clairement : le doubler réduit à peu près de moitié le coût CPU du GC, et la part d'assist baisse avec lui
• GOMEMLIMIT, c'est cet échange contre un plafond, souple par conception, car une limite dure transforme un pic de heap en blocage indéfini
• GOMAXPROCS dans un conteneur : Go 1.25 lit la limite CPU du cgroup et explicitement pas les requests CPU, donc un pod avec des requests et sans limite garde l'ancien comportement

L'approche a un plafond : Uber a rapporté en 2021 que le réglage de GOGC face à la limite mémoire du conteneur avait récupéré environ 70,000 cœurs sur l'ensemble de ses services critiques. C'est un résultat de coût, pas un percentile.

Ce qu'un hot path en Rust vous donne, et ce que vous payez pour l'avoir

RTB House a décrit en juin 2025 un service de bidding en JVM où un découpage en microservices produisait un volume élevé de petites requêtes : la latence ajoutée devait rester sous 7 ms face à une requête moyenne d'environ 2.5 ms, et les percentiles 98 et 99 cassaient sous des pauses G1 fréquentes. Ils sont passés à generational ZGC et l'ont payé en mémoire.

Notez ce qu'a exigé cette réparation : un second collecteur vers lequel basculer. Go n'en livre qu'un et il n'est pas pluggable, donc les leviers Go sont le taux d'allocation, la forme du live set, et GOGC face à GOMEMLIMIT. Ce qu'un hot path en Rust supprime est en revanche précis : pas d'assist, pas de marquage en arrière-plan, pas de cycle forcé. Ce qui ne disparaît pas est plus long que ce que la plupart des équipes imaginent :

• L'allocateur, plus les défauts de page et le placement NUMA : la bibliothèque standard de Rust indique que l'allocateur global par défaut n'est pas spécifié, et malloc sous de nombreux threads est une source de queue de latence
• L'ordonnancement, car un runtime async avec un pool de workers reproduit les effets du scheduler Go dès qu'une tâche bloquante tombe sur un worker
• La comptabilité mémoire, puisque GOMEMLIMIT ne couvre que la mémoire du runtime Go : un allocateur Rust dans le même processus se situe hors de votre plafond, et l'application de la limite passe à l'OOM killer
• Les personnes, c'est-à-dire qui est d'astreinte la nuit sur le hot path et ce que coûtent deux toolchains dans un même dépôt
• La frontière, si Go reste à l'extérieur : Cockroach Labs a mesuré un appel cgo à 171 ns contre 1.83 ns pour un appel Go en 2015, et c'est le rapport qui survit

Si la queue de latence se loge dans le parsing de la requête, dans la connexion à l'ad exchange ou dans la mise en file du scheduler, Rust ne rend aucune de ces millisecondes, et réécrire le mauvais composant dépense un trimestre pour conserver le même taux de timeout.

Déplacez donc le plus petit morceau qui détient les allocations, pas le service : la boucle d'évaluation d'impression et ses index, la sélection des candidats, le ciblage, les lookups de fréquence et de budget, le scoring. Chiffrez la frontière au franchissement : une fois par bid request avec un buffer plat, jamais une fois par règle de ciblage. Validez sur des instances séparées alimentées par un flux miroir, jamais à l'intérieur du processus testé, où un chemin shadow double les deux quantités que vous mesurez.

Le prestataire qui répare ça demande d'abord le rapport de timeouts

La seconde moitié de la question, qui fait ce genre de travail, a un test qui ne demande aucune liste de fournisseurs. Un prestataire qui répare une latence pilotée par le GC se comporte autrement qu'un prestataire qui vend une réécriture :

• Demande la distribution des tmax et le rapport de timeouts par ad exchange avant de demander le dépôt
• Énonce la décomposition - handler, scheduler, réseau - et lequel des trois il s'attend à voir détenir les millisecondes, avant de proposer un langage
• Apporte son propre générateur en boucle ouverte et son propre profil de trafic, et refuse un percentile en boucle fermée comme preuve
• Nomme le critère de sortie à l'avance : quel ad exchange, quel percentile, quelle marge contre son tmax, quelle mémoire pour mille requêtes
• Sait staffer le hot path ensuite, car une réécriture pour laquelle personne n'est d'astreinte la nuit, c'est le deuxième incident

Aucun d'eux ne demande de faire confiance : chacun est un document que vous pouvez réclamer dès la première conversation, et celui qui revient vague dit que le diagnostic est en train d'être sauté.

La première question n'est donc pas quel langage. C'est lequel des trois postes - handler, scheduler ou réseau - détient les millisecondes manquantes sur la connexion qui expire, et si les octets alloués par bid request bougent quand vous vous y attaquez.

Ce qu'amBrain peut étayer publiquement : amBrain est une société de développement logiciel spécialisée dans les plateformes de trading, les matching engines, les systèmes de real-time bidding et l'ingénierie de plateformes de casino ; nous construisons des logiciels depuis 2019, et en AdTech ce que nous construisons, c'est du développement de DSP, des plateformes d'enchères en temps réel et de l'ingénierie d'ad exchange. Nous travaillons en trois formats : livraison complète, équipe dédiée ou ingénieurs intégrés à votre équipe. Si vous pesez une réécriture contre une passe de réglage, la conversation qui vaut la peine fait la décomposition avant de choisir un langage.