Best Practices für RTB-Anwendungen

In diesem Leitfaden werden Best Practices erläutert, die bei der Entwicklung von Anwendungen zu berücksichtigen sind. gemäß dem EZG-Protokoll an.

Verbindungen verwalten

Verbindungen aufrechterhalten

Das Herstellen einer neuen Verbindung erhöht die Latenzen und dauert wesentlich länger als eine Wiederverwendung. Indem Sie weniger Kunden -Verbindungen können Sie die Anzahl der Verbindungen reduzieren, die geöffnet werden müssen. noch einmal.

Zunächst erfordert jede neue Verbindung einen zusätzlichen Netzwerk-Roundtrip, zu etablieren. Da wir Verbindungen bei Bedarf herstellen, wird die erste Anfrage einer hat eine kürzere effektive Frist und führt eher zu einer Zeitüberschreitung als nachfolgende 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 eine Menge unnötigen Aufwand.

Schließen von Verbindungen vermeiden

Beginnen Sie mit der Feinabstimmung des Verbindungsverhaltens. Die meisten Server-Standardeinstellungen sind auf mit einer großen Anzahl von Clients, die jeweils nur eine kleine Anzahl von Clients -Anfragen. Bei RTB hingegen sendet ein kleiner Pool von Computern Anfragen im Namen einer großen Anzahl von Browsern. Darunter ist es sinnvoll, Verbindungen so oft wie möglich wiederzuverwenden. Mi. empfehlen wir Folgendes:

  • 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 bis 150, MaxKeepAliveRequests bis Null und MaxClients auf einen Wert, der vom Servertyp abhängt.

Sobald das Verbindungsverhalten optimiert ist, sollten Sie auch sicherstellen, Der Bietercode trennt Verbindungen nicht unnötig. 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 Ihre Gebotsfunktion dass die Verbindungen überlastet sind und die Anzahl der Zeitüberschreitungen zunimmt. Dadurch wird Ihre Gebotsanwendung gedrosselt.

Verbindungen im Gleichgewicht 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, da Authorized Buyers und die Server des Bieters neu gestartet werden, können sehr variabel sein.

Wenn einige Verbindungen stark ausgelastet sind, können andere geöffnete Verbindungen möglicherweise bleiben größtenteils inaktiv, da sie zu diesem Zeitpunkt nicht benötigt werden. Als Der Traffic von Authorized Buyers ändert sich und inaktive Verbindungen können aktiv werden. können inaktive Verbindungen sein. Dies kann zu einer ungleichmäßigen Last auf Ihren Bieterservern führen. wenn die Verbindungen schlecht geclustert 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 dass Proxy-Verbindungen über einen Hardware-Load-Balancer oder eine Firewall wird festgelegt, sobald die Verbindungen hergestellt sind. 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. In Apache haben Sie zum Beispiel MaxKeepAliveRequests auf 5.000 festlegen
  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 werden Kontingente auf ist eine schwierige Aufgabe, und bei einer Vielzahl von ein Back-End zu Spitzenzeiten ausfällt und sich der Traffic-Mix ändert, Für jede Anfrage ist eine höhere Verarbeitung erforderlich oder es wird gerade ein Kontingentwert festgelegt 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

In Bezug auf das Verhalten bei hoher Last können Bieter sich in drei Kategorien:

Die „Auf alles reagieren“ Bieter

Diese Gebotsfunktion lässt sich zwar einfach implementieren, schneidet aber am schlechtesten ab, wenn überlastet. Er versucht lediglich, auf jede eingehende Gebotsanfrage zu antworten, die nicht sofort geliefert werden können. 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 Latenzen werden wiederhergestellt, was zu einer Reduzierung der Drosselung führt.
  • Der Zyklus zu beginnt erneut.

Das Latenzdiagramm für diese Gebotsanwendung ähnelt einer sehr steilen Sägezahnanlage Muster zu ändern. Anfragen in der Warteschlange führen dazu, dass der Server mit dem Paging beginnt. oder etwas anderes tun, das zu einer langfristigen Verlangsamung führt. sich erst nach Ende der Spitzenzeiten wieder erholen. während der Spitzenzeit. In beiden Fällen werden weniger Callouts als wenn das Kontingent einfach auf einen niedrigeren Wert festgelegt worden wäre.

Der „Fehler bei Überlast“ Bieter

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, Verbindungswarteschlange (gesteuert von ListenBackLog in Apache) Implementierung eines probabilistischen Drop-Modus, wenn Auslastung oder Latenzen zu stark werden oder einen anderen Mechanismus verwenden. Wenn Google eine Fehlerrate von über 15 % feststellt, drosseln wir. Im Gegensatz zur Funktion „Auf alles reagieren“ Bieter, dieser Bieter „verringert Verluste“, Dadurch ist eine sofortige Wiederherstellung möglich, wenn die Anforderungsraten 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 Callouts bis zu einem bestimmten Preis und kehrt dann zurück "kein Gebot" auf Überlastung reagieren. Ähnlich wie „Fehler bei Überlast“ Bieter, kann dies auf verschiedene Arten implementiert werden. Der Unterschied besteht darin, an Google zurückgegeben, sodass Callouts nicht gedrosselt werden. Die wird die Überlast von den Frontend-Maschinen absorbiert, die nur den Traffic die sie verarbeiten können, um zu den Back-Ends zu gelangen.

Im Latenzdiagramm für diesen Bieter wird ein Plateau angezeigt, das (künstlich) stoppt das Parallelisieren der Anforderungsrate zu Spitzenzeiten und ein entsprechender Rückgang den Anteil der Antworten, die ein Gebot enthalten.

Wir empfehlen, die Spalten „Fehler bei Überlast“ „No-bid on overload“ (Kein Gebot für Überlastung) festlegen. auf folgende Weise an:

  • Überdimensionieren Sie die Frontends und stellen Sie sie auf einen Fehler bei Überlast ein, um die Anzahl der Verbindungen zu maximieren, auf die sie in irgendeiner Form reagieren können.
  • Wenn bei einer Überlast ein Fehler auftritt, können die Frontend-Maschinen eine vorformulierte "Kein Gebot"-Konfiguration verwenden. und müssen die Anfrage überhaupt nicht parsen.
  • Implementieren Sie Systemdiagnosen der Back-Ends, sodass sie ein "Kein Gebot" zurückgeben, wenn keine ausreichenden Kapazitäten zur Verfügung stehen. Antwort.

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 auf alles reagieren müssen, sollten Sie sie in eine andere „Fehler bei Überlast“ indem Sie das Verbindungsverhalten so anpassen, überlastet werden soll. Dies führt zwar zu mehr Fehlern, Verringert Zeitüberschreitungen und verhindert, dass der Server in einen Zustand wechselt, in dem er kann nicht auf Anfragen antworten.

Auf Pings antworten

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 zur Plausibilitätsprüfung und Fehlerbehebung für den Bieterstatus, Verbindungsabbruch Verhalten, Latenz und mehr. Ping-Anfragen haben das folgende Format:

Google

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

OpenRTB-JSON

"id": "4YB27BCXimH5g7wB39nd3t"

OpenRTB-Protokollzwischenspeicher

id: "7xd2P2M7K32d7F7Y50p631"

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 Schwankungen zu reduzieren, ist das Peering mit Google. 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 dafür, Peering als Best Practice zu betrachten, lassen sich wie folgt zusammenfassen:

  • Im Internet werden Verbindungen mit öffentlichen Verkehrsmitteln hauptsächlich über Routenplanung“ mit der der nächstgelegene Link außerhalb unseres Netzwerks gefunden wird, an sein Ziel und leitet das Paket über diese Verbindung. 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. Danach haben wir keine Kontrolle über die Route, die das Paket folgt dem Bieter, sodass er an andere autonome Systeme zurückgesendet wird. (Werbenetzwerke).

  • Wenn dagegen eine Direct Peering-Vereinbarung besteht, werden Pakete 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 senden

Wir empfehlen Käufern, immer nur ein einzelnes statisches DNS-Ergebnis an Google zu senden und sich auf auf Google für die Traffic-Bereitstellung.

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 und diese Antwort dann nacheinander durchläuft.
  2. Der DNS-Server antwortet immer mit demselben Satz von Adressen, wechselt jedoch zyklisch die Reihenfolge der Adressen in der Antwort.

Die erste Technik ist schlecht beim Load-Balancing, 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 TTL(Time-to-Live), die zuvor in den DNS-Einträgen festgelegt ist, aber das Aktualisierungsintervall bleibt ungewiss.