Best Practices für RTB-Anwendungen

In diesem Leitfaden werden Best Practices erläutert, die Sie bei der Entwicklung von Anwendungen gemäß dem RTB-Protokoll berücksichtigen sollten.

Verbindungen verwalten

Verbindungen aufrechterhalten

Das Herstellen einer neuen Verbindung erhöht die Latenzen und dauert wesentlich länger als eine Wiederverwendung. Wenn Sie weniger Verbindungen schließen, können Sie die Anzahl der Verbindungen reduzieren, die wieder geöffnet werden müssen.

Zunächst erfordert jede neue Verbindung einen zusätzlichen Netzwerk-Roundtrip, zu etablieren. Da wir Verbindungen auf Anfrage herstellen, hat die erste Anfrage an eine Verbindung eine kürzere effektive Frist und es ist wahrscheinlicher, dass eine Zeitüberschreitung auftritt als bei nachfolgenden Anfragen. Zusätzliche Zeitüberschreitungen erhöhen die Fehlerrate, was zu gedrosselt wird.

Außerdem erzeugen viele Webserver für jede Verbindung einen dedizierten Worker-Thread. festgelegt ist. Das bedeutet, dass der Server zum Schließen und Neuerstellen der Verbindung Sie müssen einen Thread beenden und verwerfen, einen neuen zuweisen, ihn ausführbar machen und Erstellen Sie den Verbindungsstatus, bevor Sie die Anfrage schließlich verarbeiten. Das ist ein unnötig hoher Aufwand.

Verbindungen nicht schließen

Passen Sie zuerst das Verbindungsverhalten an. Die meisten Serverstandardeinstellungen sind auf Umgebungen mit einer großen Anzahl von Clients zugeschnitten, die jeweils nur eine kleine Anzahl von Anfragen stellen. Bei RTB hingegen sendet ein kleiner Pool von Computern Anfragen im Namen einer großen Anzahl von Browsern. Unter diesen Bedingungen ist es sinnvoll, Verbindungen so oft wie möglich wiederzuverwenden. Wir empfehlen Folgendes festzulegen:

  • Zeitlimit für Inaktivität auf 2,5 Minuten.
  • Maximale Anzahl von Anfragen bei einer Verbindung mit der höchsten möglichen Wert.
  • Maximale Anzahl von Verbindungen zum höchsten Wert für den RAM die Anforderungen erfüllen, während Sie überprüfen, ob die Anzahl der Verbindungen nähert sich diesem Wert nicht zu sehr an.

In Apache würde das beispielsweise bedeuten, KeepAliveTimeout auf 150, MaxKeepAliveRequests auf null und MaxClients auf einen Wert festzulegen, der vom Servertyp abhängt.

Nachdem Sie das Verbindungsverhalten optimiert haben, sollten Sie auch dafür sorgen, dass Ihr Bidder-Code Verbindungen nicht unnötig schließt. Wenn Sie beispielsweise Frontend-Code, der ein Standardgebot ohne Gebot zurückgibt Antwort im Fall eines Backends oder Zeitüberschreitungen auftreten, stellen Sie sicher, dass der Code seine Antwort zurückgibt, ohne den So vermeiden Sie, dass Ihr Bidder überlastet wird, Verbindungen geschlossen werden und die Anzahl der Zeitüberschreitungen zunimmt, wodurch Ihr Bidder gedrosselt wird.

Verbindungen ausgewogen halten

Wenn über Authorized Buyers eine Verbindung zu den Servern des Bieters hergestellt wird über einen Proxyserver laufen, können die Verbindungen mit der Zeit unausgeglichen werden. da Authorized Buyers nur die IP-Adresse des Proxyservers kennen, kann nicht festgestellt werden, welcher Bieterserver die einzelnen Callouts erhält. Im Laufe der Zeit, wenn Authorized Buyers Verbindungen herstellt und schließt und die Server des Bieters neu gestartet werden, kann die Anzahl der Verbindungen, die jeweils zugeordnet sind, sehr unterschiedlich sein.

Wenn einige Verbindungen stark ausgelastet sind, bleiben andere geöffnete Verbindungen möglicherweise größtenteils inaktiv, da sie derzeit nicht benötigt werden. Wenn sich der Traffic von Authorized Buyers ändert, können inaktive Verbindungen aktiv werden und aktive Verbindungen inaktiv. Dies kann zu einer ungleichmäßigen Auslastung Ihrer Bieterserver führen, wenn die Verbindungen schlecht gruppiert sind. Google versucht, dies zu verhindern, Schließen aller Verbindungen nach 10.000 Anfragen, um im Laufe der Zeit. Wenn der Traffic in Ihrem Konto immer noch unausgeglichen ist, können Sie weitere Schritte unternehmen:

  1. Wählen Sie das Backend pro Anfrage statt einmal pro Verbindung aus wenn Sie Front-End-Proxys verwenden.
  2. Geben Sie eine maximale Anzahl von Anfragen pro Verbindung an, wenn Sie Verbindungen über einen Hardware-Load Balancer oder eine Firewall proxyn und die Zuordnung nach dem Herstellen der Verbindungen festgelegt ist. Beachten Sie, dass Google gibt bereits eine Obergrenze von 10.000 Anfragen pro Verbindung an. sollten Sie nur dann einen strengeren Wert angeben, wenn Sie weiterhin werden in Ihrer Umgebung geclustert. Legen Sie in Apache beispielsweise MaxKeepAliveRequests auf 5.000 fest.
  3. Konfigurieren Sie die Server des Bieters so, dass deren Anforderungsraten überwacht werden, und schließen Sie einige davon ab. ihrer eigenen Verbindungen nutzen, wenn sie durchweg zu viele Anfragen verarbeiten, im Vergleich zu ihren Mitbewerbern.

Mit Überlastung souverän umgehen

Idealerweise sind die Kontingente hoch genug, damit Ihre Gebotsfunktion alle Anforderungen, die er verarbeiten kann, aber nicht mehr. In der Praxis ist es schwierig, die Kontingente auf einem optimalen Niveau zu halten. Überlastungen können aus verschiedenen Gründen auftreten: Ein Backend fällt während Spitzenzeiten aus, der Traffic-Mix ändert sich, sodass für jede Anfrage mehr Verarbeitung erforderlich ist, oder der Kontingentwert ist einfach zu hoch. Daher zahlt es sich aus, zu berücksichtigen, wie Ihre Gebotsfunktion zu viele Zugriffe erhalten.

Um temporäre Verkehrsschichten zu berücksichtigen (bis zu einer Woche) zwischen Regionen (besonders zwischen Asien und US-West und US-Ost und US-West) empfehlen wir eine Pufferung von 15% zwischen dem 7-Tage-Spitzenwert und den Abfragen pro Sekunde pro Handel. Standort

Bidder lassen sich in Bezug auf ihr Verhalten bei hoher Auslastung in drei allgemeine Kategorien unterteilen:

Die „Auf alles reagieren“ Bieter

Diese Gebotsfunktion lässt sich zwar einfach implementieren, schneidet aber am schlechtesten ab, wenn überlastet. Es wird einfach versucht, auf jede eingehende Gebotsanfrage zu reagieren, unabhängig davon, ob sie sofort ausgeführt werden kann oder nicht. Alle Anfragen, die nicht sofort ausgeführt werden können, werden in die Warteschlange gestellt. Das Szenario dann in etwa so aus:

  • Mit steigender Anfragerate nehmen auch die Anfragelatenzen zu, bis alle Anfragen Zeitüberschreitung starten
  • Die Latenzen steigen steil an, wenn die Callout-Raten den Spitzenwert erreichen
  • Die Drosselung wird aktiviert, wodurch die Anzahl der zulässigen Callouts stark reduziert wird
  • Die Latenz beginnt sich zu erholen, wodurch die Drosselung reduziert wird.
  • Der Zyklus zu beginnt erneut.

Das Latenzdiagramm für diese Gebotsanwendung ähnelt einer sehr steilen Sägezahnanlage Muster zu ändern. Alternativ können anstehende Anfragen dazu führen, dass der Server mit dem Auslagern von Arbeitsspeicher beginnt oder etwas anderes tut, was zu einer langfristigen Verlangsamung führt. Die Latenzen normalisieren sich erst wieder, wenn die Spitzenzeiten vorbei sind, was zu niedrigen Auslöseraten während der gesamten Spitzenzeit führt. In beiden Fällen werden weniger Callouts als wenn das Kontingent einfach auf einen niedrigeren Wert festgelegt worden wäre.

Der Bieter „error on overload“

Dieser Bieter akzeptiert Callouts bis zu einem bestimmten Preis und kehrt dann zurück für einige Zusatzinformationen angezeigt. Dies kann durch interne Zeitüberschreitungen, das Deaktivieren der Verbindungswarteschlange (von ListenBackLog in Apache gesteuert), die Implementierung eines probabilistischen Aussetzmodus, wenn die Auslastung oder Latenz zu hoch wird, oder einen anderen Mechanismus erfolgen. Wenn Google eine Fehlerrate von über 15 % feststellt, drosseln wir. Im Gegensatz zum Bieter, der auf alles antwortet, „begrenzt dieser Bieter seine Verluste“, sodass er sich sofort erholen kann, wenn die Anfrageraten sinken.

Das Latenzdiagramm für diesen Bieter ähnelt einer flachen Sägezahnanlage Muster bei Überlastung, auf den maximal zulässigen Wert zu zahlen.

„Kein Gebot bei Überlast“ Bieter

Dieser Bieter akzeptiert Zusatzinformationen bis zu einer bestimmten Rate und gibt dann bei Überlastung Antworten vom Typ „kein Gebot“ zurück. Ähnlich wie beim Bietertyp „Fehler bei Überlastung“ kann dies auf verschiedene Arten implementiert werden. Der Unterschied besteht darin, dass kein Signal an Google zurückgegeben wird. Deshalb werden Zusatzinformationen nie gedrosselt. Die Überlastung wird von den Front-End-Maschinen absorbiert, die nur den Traffic weiterleiten, den sie verarbeiten können.

Das Diagramm für die Latenz dieses Bieters zeigt ein Plateau, das (künstlich) die Anfragerate zu Spitzenzeiten nicht mehr parallelisiert, und einen entsprechenden Rückgang des Anteils der Antworten, die ein Gebot enthalten.

Wir empfehlen, den Ansatz „Fehler bei Überlastung“ mit dem Ansatz „Kein Gebot bei Überlastung“ zu kombinieren. Gehen Sie dazu so vor:

  • Die Front-Ends überprovisionieren und bei Überlastung auf Fehler setzen, um die Anzahl der Verbindungen zu maximieren, auf die sie in irgendeiner Form reagieren können.
  • Bei einer Überlastung können die Front-End-Maschinen eine vordefinierte Antwort vom Typ „Kein Gebot“ verwenden und müssen die Anfrage nicht einmal parsen.
  • Implementieren Sie eine Systemdiagnose für die Back-Ends, damit bei keiner ausreichende Kapazität verfügbar ist, eine Antwort vom Typ „Kein Gebot“ zurückgegeben wird.

Dadurch kann ein Teil der Überlast absorbiert werden und die Back-Ends haben die Möglichkeit, auf genau so viele Anfragen antworten, wie sie verarbeiten können. Ihnen fällt das ein: „Kein Gebot bei Überlast“ wobei Frontend-Maschinen auf "Fehler auf Überlastung“ wenn die Anzahl der Anfragen deutlich höher ist als erwartet.

Wenn Sie einen Bieter haben, der auf alles antwortet, sollten Sie ihn in einen Bieter mit der Funktion „Bei Überlastung Fehler zurückgeben“ umwandeln. Passen Sie dazu das Verbindungsverhalten so an, dass er sich effektiv weigert, überlastet zu werden. Dadurch werden zwar mehr Fehler zurückgegeben, aber es werden weniger Zeitüberschreitungen verursacht und der Server gerät nicht in einen Zustand, in dem er nicht mehr auf Anfragen reagieren kann.

Auf Pings reagieren

Achten Sie darauf, dass die Gebotsfunktion auf Ping-Anfragen antworten kann, ohne eine Verbindung herzustellen ist für die Fehlerbehebung überraschend wichtig. Google verwendet Ping-Anfragen unter anderem zur Prüfung und Fehlerbehebung des Gebotsstatus, des Verbindungsschließungsverhaltens und der Latenz. Ping-Anfragen haben folgendes Format:

OpenRTB-Protokollzwischenspeicher

id: "7xd2P2M7K32d7F7Y50p631"

OpenRTB JSON

{
  "id": "4YB27BCXimH5g7wB39nd3t"
}

Google (veraltet)

id: "\3503cg\3023P\364\230\240\270\020\255\002\231\314\010\362\347\351\246\357("
is_test: true
is_ping: true

Anders als zu erwarten, enthält die Ping-Anfrage keine Anzeigenflächen. Wie oben beschrieben sollten Sie die Verbindung nach dem Antworten auf eine Ping-Anfrage nicht trennen.

Peering

Eine weitere Möglichkeit, die Netzwerklatenz oder -variabilität zu reduzieren, besteht darin, eine Peer-Verbindung zu Google herzustellen. Mit Peering können Sie den Pfad optimieren, den Traffic auf dem Weg zu Ihrer Gebotsfunktion zurücklegt. Die bleiben die Verbindungsendpunkte unverändert, aber die Zwischenlinks ändern sich. Weitere Informationen finden Sie in der Weitere Informationen Die Gründe, warum Peering als Best Practice betrachtet werden sollte, können so zusammengefasst werden:

  • Im Internet werden Transit-Links hauptsächlich über das Hot-Potato-Routing ausgewählt. Dabei wird der nächstgelegene Link außerhalb unseres Netzwerks gefunden, über den ein Paket an sein Ziel gelangen kann, und das Paket wird über diesen Link weitergeleitet. Wann? durchläuft der Traffic einen Backbone-Teil eines Anbieters, mit dem wir viele Peering-Verbindungen haben, befindet sich der ausgewählte Link wahrscheinlich in der Nähe. Paketstarts. Ab diesem Punkt haben wir keine Kontrolle über die Route, die das Paket zum Bieter nimmt. Es kann also auf dem Weg zu anderen autonomen Systemen (Netzwerken) weitergeleitet werden.

  • Im Gegensatz dazu werden Pakete bei einer direkten Peering-Vereinbarung immer über einen Peering-Link gesendet. Unabhängig davon, woher das Paket stammt, durchläuft Links, die Google gehören oder freigegeben, bis es die gemeinsam genutzten Peering-Punkt in der Nähe des Bieterstandorts befinden. Rückwärtsfahrt beginnt mit einem kurzen Sprung zum Google-Werbenetzwerk und bleibt auf der Google-Seite Netzwerk aufbauen. Den Großteil der Reise von Google verwalten lassen sorgt die Infrastruktur dafür, dass das Paket eine Route mit niedriger Latenz zurücklegt mögliche Variabilität.

Statisches DNS einreichen

Wir empfehlen Käufern, immer ein einzelnes statisches DNS-Ergebnis an Google zu senden und die Auslieferung des Traffics von Google verwalten zu lassen.

Hier sind zwei gängige Vorgehensweisen DNS-Server beim Laden von Guthaben verwalten oder Verfügbarkeit verwalten:

  1. Der DNS-Server gibt als Antwort eine oder eine Teilmenge von Adressen weiter mit einer Abfrage und durchlaufen diese Antwort dann irgendwie.
  2. Der DNS-Server antwortet immer mit demselben Satz von Adressen, wechselt jedoch zyklisch die Reihenfolge der Adressen in der Antwort.

Bei der ersten Methode ist das Load-Balancing schlecht, da in letzterem Stapelebenen befinden und Versuche, das Caching zu umgehen, erhalten die bevorzugten Ergebnisse, da Google die Zeit für die DNS-Auflösung Bieter.

Bei der zweiten Technik wird kein Load-Balancing erzielt, da Google wählt eine IP-Adresse nach dem Zufallsprinzip aus der DNS-Antwortliste aus, sodass die Reihenfolge Antwort keine Rolle spielt.

Wenn ein Bieter eine DNS-Änderung vornimmt, berücksichtigt Google die in den DNS-Einträgen festgelegte TTL (Gültigkeitsdauer). Das Aktualisierungsintervall bleibt jedoch ungewiss.