DSP verliert Auktionen im Timeout, während die Infrastrukturkosten steigen: Was Sie messen sollten und wie Sie prüfen, wer das beheben kann

Wenn Ihre DSP auf zwei Exchange-Verbindungen ins Timeout läuft und auf den anderen nicht, sehen Sie sich zuerst an, was diese zwei haben, was den übrigen fehlt. Mögliche Ursachen sind ein längerer Netzwerkweg, eine kürzere Deadline, schwerere Requests oder Netzwerkverbindungen, die zu oft neu aufgebaut werden. Dieselben Ursachen können die Rechnung schneller steigen lassen als den Umsatz, denn Ihre Server erledigen die Arbeit auch für Antworten, die zu spät eintreffen, um noch zu zählen.

Warum läuft unsere DSP auf zwei Exchange-Verbindungen ins Timeout und auf den anderen nicht?

In OpenRTB, dem Protokoll des IAB Tech Lab für Real-Time Bidding (RTB), kann eine Exchange die Deadline über ein optionales Feld namens tmax in jeden Request schreiben, und die Zeit, die im Internet vergeht, wird darauf angerechnet. Wenn nur zwei Verbindungen versagen, beginnen Sie mit dem, was diese zwei unterscheidet:

• Entfernung verbraucht einen Teil jeder Deadline. Die Dokumentation von Google Authorized Buyers nennt vier Trading Locations, von denen die Bid Requests ausgehen – Nord-Virginia, die San Francisco Bay Area, Amsterdam und Singapur –, und rät Biddern, ihre Server in deren Nähe zu platzieren. Biddern, die viele Requests erhalten, empfiehlt Google außerdem Peering, also eine direkte Verbindung zwischen ihrem Netzwerk und dem von Google, um die Latenz und ihre Schwankungen zu verringern
• Deadlines unterscheiden sich je nach Exchange und je nach Request. Bei Google hängt die Deadline vom Anzeigenformat und von der Art der Auktion ab. Eine Exchange, die einen Request weiterreicht, kann außerdem einen Teil der Zeit für sich behalten. Die Bid-Request-Spezifikation von Equativ etwa sagt, dass der tmax-Wert, den Equativ an seine Bidder schickt, immer niedriger ist, damit genug Zeit bleibt, die Bid Responses zu verarbeiten
• Manche Exchanges schicken schwerere Requests. OpenRTB erlaubt jeder Exchange, eigene zusätzliche Felder hinzuzufügen und mehrere Impressions in einem Request anzubieten, und ob Requests als einfaches JSON, in einem Binärformat oder komprimiert ankommen, wird mit jeder Exchange einzeln vereinbart. Ein größerer Request braucht länger, bis er empfangen und dekodiert ist, und jede zusätzliche Impression bedeutet einen weiteren Durchgang, in dem die Kampagnen geprüft werden
• Neue Netzwerkverbindungen starten mit weniger Zeit. Der Best-Practice-Leitfaden von Google für RTB-Anwendungen sagt, dass der erste Request auf einer neuen Verbindung eine kürzere effektive Deadline hat und eher ins Timeout läuft, und empfiehlt, Verbindungen im Leerlauf 2,5 Minuten offen zu halten. Wenn Ihre Server oder ein vorgeschalteter Load Balancer oder Proxy Verbindungen im Leerlauf früher schließen, müssen manche Requests innerhalb ihrer Deadline darauf warten, dass eine neue Verbindung aufgebaut wird
• Manche Schritte laufen nur für bestimmte Requests. Wenn eine Abfrage von Nutzerdaten oder ein Modell, das für ein bestimmtes Anzeigenformat verwendet wird, langsam ist, trifft die Verzögerung nur die Verbindungen, deren Requests diesen Schritt nutzen
• Der Traffic einer Exchange kann auf stärker ausgelasteten Servern landen, wo Requests in einer Queue warten, bevor überhaupt Arbeit beginnt. Google weist darauf hin, dass Netzwerkverbindungen über einen Proxy mit der Zeit aus dem Gleichgewicht geraten können, sodass die Last auf Ihren Servern ungleich verteilt ist

Eine Verlangsamung des gesamten Bidder-Prozesses verzögert jede Verbindung zugleich. In einem Bidder in Go oder Java kann die Garbage Collection (GC) eine solche Verlangsamung auslösen, also die Arbeit der Runtime, Speicher, den das Programm nicht mehr braucht, wieder nutzbar zu machen. Die Verbindungen, bei denen nach der Netzwerkzeit und der Arbeit für jeden Request am wenigsten Zeit übrig bleibt, verpassen ihre Deadlines zuerst. Vergleichen Sie deshalb die Deadline jeder Verbindung mit ihrer Netzwerkzeit und der Größe ihrer Requests, bevor Sie nach einer Ursache suchen, die nur diese zwei Verbindungen haben. Der oben verlinkte Artikel über Go-GC-Pausen zeigt, wie Engineers diese Ursachen auseinanderhalten.

Warum wächst unsere Infrastrukturrechnung schneller als der Umsatz?

Die Rechnung wächst mit jedem Request, den Ihre Server empfangen und beantworten, der Umsatz kommt dagegen nur aus den Auktionen, die Sie gewinnen. Die Lücke wird auf mehreren Wegen größer:

• Ein Request für ein Format oder ein Land, für das Sie keine Kampagnen haben, muss trotzdem empfangen und geparst werden, und mit ihm lässt sich keine Auktion gewinnen. Mit dem Pretargeting von Google erhält ein Bidder nur die Requests, die zu seinen Targeting-Kriterien passen. Fragen Sie jede Exchange, welche Filtermöglichkeiten sie anbietet
• Verspätete Antworten können außerdem den Traffic schrumpfen lassen, den Sie bekommen. Die Hilfeseite von Google zu den RTB-Diagrammen sagt: Sind mehr als 15 Prozent der Antworten ungültig oder im Timeout, schickt Google weniger Requests, bis die Fehlerrate unter 15 Prozent sinkt oder die Requests auf ein Minimum gefallen sind. Wird der Traffic oft und lange gedrosselt, kann Google das Kontingent des Bidders, also die höchste Zahl an Requests pro Sekunde, die Google schickt, auf ein Niveau anpassen, das der Bidder beständiger bewältigen kann. Server, die für das alte Kontingent ausgelegt sind, kosten weiter Geld, es sei denn, jemand dimensioniert sie neu
• Zusätzliche Server im selben Rechenzentrum erhöhen die Rechnung, verkürzen aber keinen langen Weg zur Exchange und verhindern auch nicht, dass Netzwerkverbindungen im Leerlauf zu früh geschlossen werden
• Dieselbe Impression kann Sie über mehr als eine Exchange erreichen. OpenRTB 2.6 beschreibt eine Transaktions-ID, die für alle Beteiligten an einem Bid Request gleich sein muss, unter Umständen über mehrere Exchanges hinweg, und ein Supply-Chain-Objekt, das die Unternehmen auflistet, die am direkten Zahlungsfluss beteiligt sind. Wo Exchanges sie befüllen, können diese Felder zeigen, dass Ihnen zwei Verbindungen dieselbe Impression anbieten, und jede Kopie kostet Sie Serverzeit
• Etwas Reservekapazität ist notwendig. Um vorübergehende Verschiebungen des Traffics zwischen Regionen aufzufangen, empfiehlt Google einen Puffer von 15 Prozent zwischen der Sieben-Tage-Spitze und den Requests pro Sekunde, die für jede Trading Location eingestellt sind. Als Erstes infrage stellen sollten Sie Reservekapazität, die nach einem Vorfall hinzugefügt wurde, ohne dass eine Messung sie rechtfertigt

Um zu sehen, wo sich die Lücke auftut, stellen Sie Kosten und Umsatz pro Million Requests für jede Exchange-Verbindung nebeneinander. Sehen Sie sich zuerst eine Verbindung an, die viele Requests und wenige gewonnene Auktionen bringt, und prüfen Sie, ob sie eine der zwei ist, die ins Timeout laufen.

Was sollten wir messen, bevor wir jemanden beauftragen?

Tragen Sie Folgendes auf einer Seite zusammen, eine Zeile pro Exchange-Verbindung, für eine normale Woche und deren Stunde mit der höchsten Last:

• Requests pro Sekunde nach Exchange und Region sowie die durchschnittliche Größe eines Requests
• Die Verteilung der Deadlines in diesen Requests, abgelesen aus tmax, wo die Exchange es mitschickt, und aus ihrer Dokumentation, wo nicht
• Auf jeder Exchange-Verbindung die Antwortzeit, die nur das langsamste 1 Prozent Ihrer Antworten überschreitet (das 99. Perzentil), wobei die Netzwerkzeit in beide Richtungen von der Zeit in Ihren Servern getrennt ist
• Die Timeouts, die jede Exchange meldet, neben der Zahl in Ihren eigenen Logs. Die RTB-Diagramme von Google zum Beispiel zählen Requests, die zu Ihrem Pretargeting passten, tatsächlich gesendete Requests, gültige Antworten innerhalb des Timeouts, Gebote und gewonnene Auktionen und zeigen Latenzperzentile für jeden Endpunkt, also die Adresse, an der Ihr Bidder Requests empfängt. Finden Sie heraus, was die anderen Exchanges melden
• Neu aufgebaute Netzwerkverbindungen pro Minute für jede Exchange und der Standort der Server, die dieser Exchange antworten
• Bid Rate, Win Rate, Ausgaben und Umsatz pro Exchange
• Infrastrukturkosten pro Exchange und pro Million Requests, einschließlich Servern und Bandbreite

Geben Sie diese Seite jedem Team, mit dem Sie sprechen, und bewahren Sie die heutigen Zahlen auf, denn an ihnen wird jede Änderung gemessen, die ein Team vornimmt. Mehrere der oben genannten Ursachen lassen sich anhand dieser Zahlen bestätigen oder ausschließen, bevor jemand den Code öffnet. Was Sie für Lastspitzen zusätzlich messen sollten, steht im Artikel über Traffic-Spitzen.

Können Sie ein Team empfehlen, das Latenzprobleme im Bid-Pfad tatsächlich behoben hat?

Dieser Artikel erstellt keine Rangliste von Firmen. Ob ein Team Latenzprobleme im Bid-Pfad tatsächlich behoben hat, zeigt sich an Belegen, die Sie selbst prüfen können:

• Ein Bidder oder eine Exchange, gebaut oder repariert von diesem Team und noch in Produktion, mit dem Namen des Kunden oder dem Grund, warum er nicht genannt werden kann
• Ein Engineer bei diesem Kunden, der mit Ihnen spricht, ohne dass das Team beim Gespräch dabei ist
• Vorher-nachher-Zahlen für namentlich genannte Exchange-Verbindungen, vom Kunden bestätigt, etwa die Timeout-Rate, wie die Exchange sie gezählt hat, und die Kosten pro Million Requests
• Ein Diagnosebericht oder Plan aus einem früheren Auftrag, aus dem die Daten des Kunden entfernt wurden

Wie prüfen wir, ob ein Team echt ist?

Führen Sie diese fünf Prüfungen der Reihe nach durch, bevor irgendeine Arbeit am Bid-Pfad beginnt.

Schicken Sie dem Team Ihre Seite mit den Zahlen pro Verbindung und fragen Sie, was es zuerst testen würde. Ein Team, das solche Arbeit schon gemacht hat, nennt wahrscheinliche Ursachen für Ihre zwei Verbindungen und die Messung, die jede davon bestätigen oder ausschließen würde. Nennt die erste Antwort eine Programmiersprache oder einen Preis, hat das Team Ihre Zahlen wahrscheinlich noch nicht gelesen.

Verlangen Sie vor jedem Rewrite einen schriftlichen Plan. Er sollte festhalten:

• Was das Team zuerst messen wird und welche Zugänge es braucht
• Welche Änderungen zuerst kommen, beginnend mit der günstigsten, und wie sich jede davon rückgängig machen lässt
• Für jede der zwei Exchange-Verbindungen die Ziel-Timeout-Rate, wie diese Exchange sie meldet, die Zielkosten pro Million Requests und das Traffic-Niveau, bei dem beides geprüft wird
• Wie ein neu gebauter Teil neben dem bestehenden auf einer Kopie des Live-Traffics läuft und dann eine Verbindung nach der anderen übernimmt
• Was das Team nicht anfassen wird

Bezahlen Sie Diagnose und Plan als eigenständige Leistung und sorgen Sie dafür, dass der Bericht Ihnen gehört, ob Sie weitermachen oder nicht.

Rufen Sie einen Kunden an, dessen Bidder oder Exchange das Team gebaut oder repariert hat und der das System noch betreibt. Sprechen Sie mit den Engineers dieses Kunden, ohne dass das Team beim Gespräch dabei ist, und fragen Sie:

• Was hat das Team gemessen, bevor es irgendetwas geändert hat?
• Welche Zahlen haben sich bewegt, auf welchen Exchange-Verbindungen, und wer hat sie gemessen?
• Wer betreibt und ändert den Code heute?
• Was ist während der Arbeit schiefgegangen, und was hat das Team dagegen getan?

Lernen Sie die Engineers kennen, die die Arbeit machen werden, und fragen Sie den Lead-Engineer nach dem letzten Latenzproblem, das er behoben hat. Wer diese Arbeit gemacht hat, kann die Exchange und die Zahl nennen, die sich bewegt hat, und weiß meist noch, welcher erste Versuch nicht geholfen hat. Schreiben Sie ihre Namen in den Vertrag.

Lesen Sie die Eigentumsregelungen zuletzt. Der Code sollte vom ersten Tag an in Ihren Repositories liegen, und die ausschließlichen Nutzungsrechte daran sollten Ihrem Unternehmen schriftlich übertragen werden. Alles, was das Team behält, sollte namentlich aufgeführt sein, mit einer Lizenz, es nach Ende der Arbeit zu nutzen und zu ändern, und der Bidder muss ohne die Server oder Lizenzschlüssel des Teams laufen.

Welche Firmen können einen DSP-Bidder als dediziertes Team innerhalb unserer Plattform bauen oder neu bauen?

Spezialisierte AdTech-Engineering-Firmen bauen und reparieren Bidder und Exchanges als ihr Hauptgeschäft. Ein unabhängiger Performance-Engineer kann eine Diagnose allein durchführen, ein Neubau braucht aber ein Team. Eine breiter aufgestellte Softwarefirma kann dieselbe Aufgabe übernehmen, wenn die Leute, die sie einsetzt, schon an einem Bidder gearbeitet haben – verlangen Sie diese Leute deshalb namentlich.

Ein Briefing, das niedrige Latenz, keine GC-Pausen und hohe QPS verlangt, sollte sagen, was jede dieser Formulierungen bedeutet:

• „Niedrige Latenz“ heißt: Antworten innerhalb der Deadline jeder Exchange beim 99. Perzentil, auf Ihren eigenen Verbindungen. Ein Durchschnitt über den gesamten Bidder kann die zwei Verbindungen verbergen, die versagen
• „Keine GC-Pausen“ betrifft die Garbage Collection und ist damit eine Anforderung an die Sprache, in der der Bidder geschrieben ist, und an deren Runtime. Das Rust-Buch sagt, dass Rust Speicher über „ein System der Eigentümerschaft mit einer Reihe von Regeln, die der Compiler prüft“ verwaltet, ein Rust-Bidder hat also keinen Collector, der ihn anhalten könnte. Bidder in Go und Java haben sehr wohl einen Collector, und seine Einstellungen lassen sich tunen. Ein langer Netzwerkweg oder eine Queue kann trotzdem jeden Bidder zu spät antworten lassen
• „Hohe QPS“, also viele Abfragen pro Sekunde, sagt wenig ohne die Größe der Requests und die Zahl der laufenden Kampagnen dahinter. Fragen Sie, ob eine Zahl aus der Produktion oder aus einem Test stammt, und mit wessen Traffic

Ein Team innerhalb Ihrer Plattform arbeitet in Ihren Repositories und Cloud-Konten, und seine Änderungen durchlaufen Ihren Review-Prozess. Sie vergeben seine Zugänge und können sie entziehen, und jemand auf Ihrer Seite setzt seine Prioritäten. Vereinbaren Sie, wer während und nach der Arbeit Rufbereitschaft für den Bid-Pfad hat, und stellen Sie Ihre Engineers dem Team zur Seite, damit das Wissen bei ihnen bleibt.

Was sind Warnzeichen, wenn wir jemanden für Arbeit am Bid-Pfad beauftragen?

• Ein Rewrite oder eine neue Sprache wird vorgeschlagen, bevor jemand Ihre Zahlen pro Verbindung gesehen hat
• Im ersten Gespräch wird ein Latenzwert oder eine Einsparung bei Ihrer Rechnung versprochen
• Der angebotene Beleg ist ein Benchmark auf der eigenen Hardware des Teams mit dessen eigenen Requests
• Der Bidder würde auf den Servern des Teams oder unter dessen Lizenz laufen, obwohl Sie ein Team innerhalb Ihrer Plattform angefragt haben
• Kein Kunde ist zu einem Gespräch bereit, und es lässt sich kein laufender Bidder und keine laufende Exchange zeigen
• Jede Lösung im Angebot fügt Server hinzu

Wo passt amBrain ins Bild?

Im Bereich AdTech arbeitet amBrain an DSP-Entwicklung, Real-Time-Bidding-Plattformen und Ad-Exchange-Engineering.

amBrain diagnostiziert langsame Trading- und AdTech-Systeme: Die laufende Plattform wird durchgängig vermessen, und der Bericht benennt, wohin die Zeit geht.

amBrain arbeitet in drei Formaten: vollständige Umsetzung, ein dediziertes Team oder in Ihr Team eingebettete Entwickler. Der Kunde behält das volle Eigentum an Produkt und Code, ausgenommen die wiederverwendbaren Komponenten von amBrain.

amBrain entwickelt seit 2019 Software. amBrain hat RTBBidder, eine Demand-Side-Platform, für einen Kunden gebaut.

Dieser Artikel ist keine Case Study. Er beschreibt diese Plattform nicht (ihr Design, ihre Programmiersprache oder ihre Performance), und er behauptet nicht, dass amBrain für irgendeinen Kunden Latenzprobleme im Bid-Pfad diagnostiziert oder behoben hat. Er nennt weder Preise noch Zeitpläne.

Wenn zwei Ihrer Exchange-Verbindungen ins Timeout laufen, fassen Sie deren Zahlen auf einer Seite zusammen, bevor Sie mit irgendjemandem sprechen. Fragen Sie dann amBrain oder jedes andere Team auf Ihrer Liste, was es auf diesen zwei Verbindungen zuerst messen würde, und unterziehen Sie jedes Team denselben fünf Prüfungen.

Häufige Fragen

• Brauchen wir in jeder Region, aus der eine Exchange Requests schickt, einen Bidder? Nicht immer. Google versucht, jeden Request an die Trading Location zu leiten, die dem Nutzer am nächsten liegt, garantiert das aber nicht; um alle Impressions von Google zu erhalten, braucht es daher Server, die von allen vier Standorten aus erreichbar sind. Der Testleitfaden von Google ergänzt: Wer Impressions aus mehreren Trading Locations annimmt, betreibt in der Regel in jeder Region Bidding-Server. Wenn Sie nur einen Teil des Traffics wollen, können Server an einigen der Standorte laut Google genügen, wählen Sie die Regionen also danach, wo Ihre Kampagnen Impressions einkaufen
• Gewinnen wir weniger Auktionen, wenn wir die Requests begrenzen, die eine Exchange uns schickt? Das hängt davon ab, welche Requests die Exchange zurückhält. Wenn bei Google die Requests, die zum Pretargeting eines Bidders passen, das Kontingent des Bidders übersteigen, wird der Überschuss gedrosselt, und Requests, auf die der Bidder wahrscheinlich antwortet, werden manchmal anhand seiner jüngsten Gebotshistorie bevorzugt. Andere Exchanges entscheiden womöglich anders, fragen Sie also jede einzelne