Un DSP qui perd des enchères sur timeout pendant que les coûts d'infrastructure augmentent : que mesurer et comment vérifier qui peut y remédier

Si votre DSP tombe en timeout sur deux connexions d'ad exchange et pas sur les autres, regardez d'abord ce que ces deux-là ont et que les autres n'ont pas. Les causes possibles sont une route réseau plus longue, une échéance plus courte, des requêtes plus lourdes ou des connexions réseau rouvertes trop souvent. Les mêmes causes peuvent faire grimper la facture plus vite que le chiffre d'affaires, parce que vos serveurs font quand même le travail pour des réponses qui arrivent trop tard pour compter.

Pourquoi notre DSP tombe-t-il en timeout sur deux connexions d'ad exchange et pas sur les autres ?

Dans OpenRTB, le protocole de real-time bidding (RTB) de l'IAB Tech Lab, un ad exchange peut indiquer l'échéance dans chaque requête via un champ facultatif appelé tmax, et le temps passé sur Internet est décompté de cette échéance. Quand seules deux connexions échouent, commencez par ce qui les distingue :

• La distance consomme une partie de chaque échéance. La documentation Authorized Buyers de Google recense quatre trading locations pour ses bid requests, en Virginie du Nord, dans la région de la baie de San Francisco, à Amsterdam et à Singapour, et conseille aux bidders de placer leurs serveurs à proximité. Pour les bidders qui reçoivent beaucoup de requêtes, Google recommande aussi le peering, une liaison directe entre leur réseau et celui de Google, afin de réduire la latence et ses variations
• Les échéances varient selon l'ad exchange et selon la requête. Chez Google, l'échéance dépend du format publicitaire et du type d'enchère. Un ad exchange qui transmet une requête plus loin peut aussi garder une partie du temps pour lui. La spécification des bid requests d'Equativ, par exemple, indique que la valeur tmax envoyée à ses bidders est toujours inférieure, afin de laisser assez de temps pour traiter les bid responses
• Certains ad exchanges envoient des requêtes plus lourdes. OpenRTB permet à chaque ad exchange d'ajouter ses propres champs supplémentaires et de proposer plusieurs impressions dans une même requête, et c'est avec chaque ad exchange que l'on convient de la forme des requêtes : JSON brut, format binaire ou compression. Une requête plus grosse met plus de temps à être reçue et décodée, et chaque impression supplémentaire ajoute un passage de plus sur les campagnes à vérifier
• Les nouvelles connexions réseau démarrent avec moins de temps. Le guide des bonnes pratiques de Google pour les applications RTB indique que la première requête sur une nouvelle connexion dispose d'une échéance effective plus courte et risque davantage de tomber en timeout, et il recommande de garder les connexions inactives ouvertes pendant 2,5 minutes. Si vos serveurs, ou un load balancer ou un proxy placé devant eux, ferment plus tôt les connexions inactives, certaines requêtes doivent attendre qu'une nouvelle connexion s'ouvre à l'intérieur de leur échéance
• Certaines étapes ne s'exécutent que pour certaines requêtes. Quand une étape comme une consultation de données utilisateur, ou un modèle utilisé pour un format publicitaire précis, est lente, le retard ne touche que les connexions dont les requêtes passent par elle
• Le trafic d'un ad exchange peut atterrir sur des serveurs plus chargés, où les requêtes attendent dans une file avant que le moindre travail ne commence. Google note que les connexions réseau établies via un proxy peuvent se déséquilibrer avec le temps et répartir inégalement la charge sur vos serveurs

Un ralentissement de l'ensemble du processus du bidder retarde toutes les connexions à la fois. Dans un bidder en Go ou en Java, le garbage collection (GC), le travail par lequel le runtime recycle la mémoire dont le programme n'a plus besoin, peut en provoquer un. Les connexions qui ont le moins de marge, une fois déduits le temps réseau et le travail que demande chaque requête, sont les premières à manquer leur échéance. Comparez donc l'échéance de chaque connexion avec son temps réseau et la taille de ses requêtes avant de chercher une cause propre à ces deux connexions. L'article sur les pauses GC de Go, dont le lien figure plus haut, montre comment les ingénieurs distinguent ces causes.

Pourquoi notre facture d'infrastructure augmente-t-elle plus vite que notre chiffre d'affaires ?

La facture augmente avec chaque requête que vos serveurs reçoivent et à laquelle ils répondent, et le chiffre d'affaires ne vient que des enchères que vous remportez. L'écart se creuse de plusieurs façons :

• Une requête pour un format ou un pays pour lequel vous n'avez aucune campagne doit quand même être reçue et décodée, et elle ne peut pas gagner. Le pretargeting de Google permet à un bidder de ne recevoir que les requêtes qui correspondent à ses critères de ciblage. Demandez à chaque ad exchange quel filtrage il propose
• Les réponses tardives peuvent aussi réduire le trafic qu'on vous envoie. La page d'aide de Google sur les graphiques RTB indique que, lorsque plus de 15 % des réponses sont invalides ou tombent en timeout, Google envoie moins de requêtes jusqu'à ce que le taux d'erreur repasse sous 15 % ou que les requêtes tombent à un minimum. Si le trafic est bridé souvent et longtemps, Google peut ajuster le quota du bidder, le nombre maximal de requêtes par seconde qu'il lui enverra, à un niveau que le bidder peut tenir de façon plus constante. Les serveurs dimensionnés pour l'ancien quota continuent de coûter de l'argent tant que personne ne les redimensionne
• Des serveurs ajoutés dans le même data center font monter la facture, mais ne raccourcissent pas une route longue jusqu'à l'ad exchange et n'empêchent pas les connexions réseau inactives d'être fermées trop tôt
• La même impression peut vous parvenir par plus d'un ad exchange. OpenRTB 2.6 décrit un identifiant de transaction qui doit être commun à tous les participants d'une bid request, potentiellement sur plusieurs ad exchanges, et un objet de chaîne d'approvisionnement (supply chain) qui liste les sociétés impliquées dans le flux direct de paiement. Là où les ad exchanges les renseignent, ces champs peuvent montrer que deux connexions vous proposent la même impression, et chaque copie vous coûte du temps serveur
• Une certaine capacité de réserve est nécessaire. Pour absorber des déplacements temporaires de trafic entre régions, Google recommande une marge de 15 % entre le pic des sept derniers jours et les requêtes par seconde configurées pour chaque trading location. La capacité de réserve à remettre en question en premier est celle qui a été ajoutée après un incident sans mesure pour la justifier

Pour voir où l'écart se creuse, mettez côte à côte le coût et le chiffre d'affaires par million de requêtes pour chaque connexion d'ad exchange. Regardez d'abord une connexion qui apporte beaucoup de requêtes et peu d'enchères gagnées, et vérifiez si c'est l'une des deux qui tombent en timeout.

Que mesurer avant d'engager qui que ce soit ?

Mettez ces éléments sur une seule page, une ligne par connexion d'ad exchange, pour une semaine normale et pour son heure la plus chargée :

• Requêtes par seconde par ad exchange et par région, et taille moyenne des requêtes
• La distribution des échéances dans ces requêtes, lue dans tmax quand l'ad exchange l'envoie et dans sa documentation quand il ne l'envoie pas
• Sur chaque connexion d'ad exchange, le temps de réponse que seul le 1 % le plus lent de vos réponses dépasse (le 99e percentile), avec le temps réseau dans les deux sens séparé du temps passé dans vos serveurs
• Les timeouts que signale chaque ad exchange, à côté du décompte de vos propres logs. Les graphiques RTB de Google, par exemple, comptent les requêtes qui correspondaient à votre pretargeting, les requêtes réellement envoyées, les réponses valides arrivées avant le timeout, les bids et les enchères gagnées, et affichent des percentiles de latence pour chaque endpoint, l'adresse où votre bidder reçoit les requêtes. Renseignez-vous sur ce que signalent les autres ad exchanges
• Nouvelles connexions réseau ouvertes par minute pour chaque ad exchange, et emplacement des serveurs qui répondent à cet ad exchange
• Taux de bid, taux de victoire, dépense et chiffre d'affaires par ad exchange
• Coût d'infrastructure par ad exchange et par million de requêtes, serveurs et bande passante compris

Donnez cette page à chaque équipe avec laquelle vous discutez, et conservez les chiffres d'aujourd'hui, car chaque changement apporté par une équipe sera jugé par rapport à eux. Plusieurs des causes ci-dessus peuvent être confirmées ou écartées à partir de ces chiffres avant que quiconque n'ouvre le code. Pour les pics, l'article sur les pics de trafic indique ce qu'il faut mesurer d'autre.

Pouvez-vous recommander une équipe qui a réellement corrigé la latence du chemin de bid ?

Cet article ne classe pas les sociétés. Qu'une équipe ait réellement corrigé la latence du chemin de bid, cela se voit à des preuves que vous pouvez vérifier vous-même :

• Un bidder ou un ad exchange que l'équipe a construit ou réparé et qui tourne toujours en production, avec le nom du client ou la raison pour laquelle il ne peut pas être donné
• Un ingénieur de ce client qui accepte de vous parler sans l'équipe en ligne
• Des chiffres avant et après sur des connexions à des ad exchanges nommés, confirmés par le client, comme le taux de timeout tel que l'ad exchange l'a compté et le coût par million de requêtes
• Un rapport de diagnostic ou un plan issu d'une mission antérieure, expurgé des données du client

Comment vérifier qu'une équipe est bien ce qu'elle prétend être ?

Menez ces cinq vérifications dans l'ordre, avant que le moindre travail ne commence sur le chemin de bid.

Envoyez à l'équipe votre page de chiffres par connexion et demandez-lui ce qu'elle testerait en premier. Une équipe qui a déjà fait ce travail cite des causes probables pour vos deux connexions et la mesure qui confirmerait ou écarterait chacune d'elles. Si la première réponse cite un langage de programmation ou un prix, l'équipe n'a probablement pas encore lu vos chiffres.

Avant toute réécriture, demandez un plan écrit. Il doit préciser :

• Ce que l'équipe mesurera en premier, et de quels accès elle a besoin
• Quels changements viennent en premier, en commençant par les moins coûteux, et comment chacun peut être annulé
• Pour chacune des deux connexions d'ad exchange, le taux de timeout cible tel que cet ad exchange le signale, le coût cible par million de requêtes, et le niveau de trafic auquel les deux seront vérifiés
• Comment une partie reconstruite tourne à côté de l'actuelle sur une copie du trafic réel, puis prend le relais une connexion à la fois
• Ce à quoi l'équipe ne touchera pas

Payez le diagnostic et le plan comme un travail à part, et faites en sorte que le rapport vous appartienne, que vous poursuiviez ou non.

Appelez un client dont l'équipe a construit ou réparé le bidder ou l'ad exchange, et qui l'exploite toujours. Parlez aux ingénieurs de ce client sans l'équipe en ligne, et demandez :

• Qu'est-ce que l'équipe a mesuré avant de changer quoi que ce soit ?
• Quels chiffres ont bougé, sur quelles connexions d'ad exchange, et qui les a mesurés ?
• Qui exploite et modifie le code aujourd'hui ?
• Qu'est-ce qui a mal tourné pendant le travail, et qu'a fait l'équipe face à cela ?

Rencontrez les ingénieurs qui feront le travail, et interrogez le responsable technique sur le dernier problème de latence qu'il a corrigé. Quelqu'un qui a fait ce travail sait nommer l'ad exchange et le chiffre qui a bougé, et se souvient en général de ce qu'il a essayé d'abord et qui n'a pas aidé. Inscrivez leurs noms dans le contrat.

Lisez les clauses de propriété en dernier. Le code doit résider dans vos dépôts dès le premier jour et être cédé par écrit à votre entreprise. Tout ce que l'équipe conserve doit figurer sur une liste nominative, avec une licence pour l'utiliser et le modifier une fois le travail terminé, et le bidder doit tourner sans les serveurs ni les clés de licence de l'équipe.

Quelles sociétés peuvent construire ou reconstruire le bidder d'un DSP en tant qu'équipe dédiée au sein de notre plateforme ?

Les sociétés d'ingénierie spécialisées en ad tech construisent et réparent des bidders et des ad exchanges : c'est leur activité principale. Un ingénieur performance indépendant peut mener un diagnostic seul, mais une reconstruction demande une équipe. Une société logicielle plus généraliste peut faire le même travail si les personnes qu'elle affecte ont déjà travaillé sur un bidder : demandez donc ces personnes nommément.

Un brief qui demande une faible latence, zéro pause GC et un QPS élevé doit préciser ce que signifie chaque expression :

• « Faible latence » signifie des réponses dans l'échéance de chaque ad exchange au 99e percentile, sur vos propres connexions. Une moyenne sur l'ensemble du bidder peut masquer les deux connexions qui échouent
• « Zéro pause GC » est une affaire de garbage collection : c'est donc une exigence qui porte sur le langage dans lequel le bidder est écrit et sur son runtime. Le livre de Rust indique que Rust gère la mémoire au moyen d'« un système de propriété avec un ensemble de règles que le compilateur vérifie », si bien qu'un bidder en Rust n'a pas de collecteur pour le mettre en pause. Les bidders en Go et en Java ont bien un collecteur, et ses réglages peuvent être ajustés. Une route réseau longue ou une file d'attente peuvent tout de même mettre n'importe quel bidder en retard
• « QPS élevé », c'est-à-dire beaucoup de requêtes par seconde, ne veut pas dire grand-chose sans la taille des requêtes et le nombre de campagnes actives qui se trouvent derrière. Demandez si un chiffre vient de la production ou d'un test, et sur le trafic de qui

Une équipe au sein de votre plateforme travaille dans vos dépôts et vos comptes cloud, et ses changements passent par votre processus de revue. C'est vous qui lui accordez ses accès et qui pouvez les lui retirer, et quelqu'un de votre côté fixe ses priorités. Convenez de qui est d'astreinte sur le chemin de bid pendant et après le travail, et faites travailler vos ingénieurs en binôme avec ceux de l'équipe, pour que le savoir reste de votre côté.

Quels sont les signaux d'alerte quand on engage quelqu'un pour travailler sur le chemin de bid ?

• Une réécriture ou un nouveau langage est proposé avant que quiconque ait vu vos chiffres par connexion
• Un chiffre de latence, ou une économie sur votre facture, est promis dès le premier appel
• La preuve proposée est un benchmark sur le propre matériel de l'équipe, avec ses propres requêtes
• Le bidder tournerait sur les serveurs de l'équipe ou sous sa licence, alors que vous avez demandé une équipe au sein de votre plateforme
• Aucun client n'accepte d'appel, et aucun bidder ni ad exchange en production ne peut être montré
• Chaque correctif de la proposition ajoute des serveurs

Où se situe amBrain ?

En AdTech, amBrain travaille sur le développement de DSP, les plateformes d'enchères en temps réel et l'ingénierie d'ad exchange.

amBrain diagnostique les systèmes lents dans le trading et l'ad tech : la plateforme en fonctionnement est mesurée de bout en bout, et le rapport indique où passe le temps.

amBrain travaille en trois formats : la prestation complète, une équipe dédiée ou des ingénieurs intégrés à votre équipe. Le client conserve la pleine propriété du produit et du code, à l'exception des composants réutilisables d'amBrain.

amBrain développe des logiciels depuis 2019. Elle a construit RTBBidder, une demand-side platform, pour un client.

Cet article n'est pas une étude de cas. Il ne décrit pas cette plateforme (sa conception, son langage ou ses performances), et il n'affirme pas qu'amBrain a diagnostiqué ou corrigé la latence du chemin de bid pour quelque client que ce soit. Il ne donne ni prix ni délais.

Si deux de vos connexions d'ad exchange tombent en timeout, mettez leurs chiffres sur une seule page avant de parler à qui que ce soit. Demandez ensuite à amBrain, ou à toute autre équipe de votre liste, ce qu'elle mesurerait en premier sur ces deux connexions, et soumettez chaque équipe aux mêmes cinq vérifications.

Questions fréquentes

• Faut-il un bidder dans chaque région d'où un ad exchange envoie ses requêtes ? Pas toujours. Google essaie d'envoyer chaque requête au trading location le plus proche de l'utilisateur, mais ne le garantit pas : recevoir toutes ses impressions demande donc des serveurs joignables depuis les quatre trading locations. Son guide de test ajoute que recevoir des impressions de plusieurs trading locations suppose en général de faire tourner des serveurs de bidding dans chaque région. Si vous ne voulez qu'une partie du trafic, Google indique que des serveurs dans certains d'entre eux peuvent suffire : choisissez donc les régions selon l'endroit où vos campagnes achètent
• Limiter les requêtes qu'un ad exchange nous envoie nous fera-t-il gagner moins d'enchères ? Cela dépend des requêtes que l'ad exchange retient. Chez Google, quand les requêtes qui correspondent au pretargeting d'un bidder dépassent son quota, l'excédent est écrêté, et les requêtes auxquelles le bidder est susceptible de répondre sont parfois priorisées en fonction de son historique d'enchères récent. D'autres ad exchanges peuvent en décider autrement : posez donc la question à chacun