Bonnes pratiques pour les applications RTB

Ce guide explique les bonnes pratiques à suivre lors du développement d'applications. conformément au protocole d'enchères en temps réel.

Gérer les connexions

Maintenir les connexions actives

L'établissement d'une nouvelle connexion augmente les latences et prend beaucoup plus aux deux extrémités plutôt que de réutiliser une ressource existante. En fermant moins de connexions, vous pouvez réduire le nombre de connexions à ouvrir à nouveau.

Tout d'abord, chaque nouvelle connexion nécessite un aller-retour réseau supplémentaire vers établir. Comme nous établissons des connexions à la demande, la première requête sur un la connexion a un délai effectif plus court et est plus susceptible d'expirer que les requêtes ultérieures. Tout dépassement de délai avant expiration augmente le taux d'erreur, ce qui peut entraîner à votre système d'enchères.

Deuxièmement, de nombreux serveurs Web génèrent un thread de travail dédié pour chaque connexion établi. Cela signifie que pour fermer et recréer la connexion, le serveur doit arrêter et supprimer un thread, en attribuer un nouveau, le rendre exécutable et de créer l'état de la connexion, avant de traiter la requête. C'est beaucoup de frais généraux inutiles.

Éviter de fermer les connexions

Commencez par régler le comportement de la connexion. La plupart des serveurs par défaut sont adaptés environnements avec un grand nombre de clients, chacun effectuant un petit nombre de requêtes. Pour le système d'enchères en temps réel, en revanche, un petit pool de machines pour le compte d'un grand nombre de navigateurs. Dans ces il est judicieux de réutiliser les connexions autant de fois que possible. Mer nous vous recommandons de définir:

  • Délai d'inactivité défini sur 2,5 minutes.
  • Nombre maximal de requêtes sur une connexion au plus élevé valeur possible.
  • Nombre maximal de connexions pouvant atteindre la valeur de RAM la plus élevée s'adapter, tout en vérifiant que le nombre de connexions n'approche pas cette valeur de trop près.

Dans Apache, par exemple, cela impliquerait de définir KeepAliveTimeout à 150, MaxKeepAliveRequests à zéro et MaxClients à une valeur qui dépend du type de serveur.

Une fois que le comportement de votre connexion est réglé, assurez-vous également que votre code d'enchères ne ferme pas les connexions inutilement. Par exemple, si vous avez qui renvoie le paramètre "aucune enchère" par défaut réponse en cas d'événement de backend ou les délais d'inactivité, assurez-vous que le code renvoie sa réponse sans fermer . Ainsi, si votre système d'enchères reçoit surchargées, les connexions commencent à se fermer et le nombre de délais avant expiration augmente, entraînant une limitation de votre système d'enchères.

Maintenir l'équilibre des connexions

Si Authorized Buyers se connecte aux serveurs de votre enchérisseur par le biais d'un serveur proxy, les connexions peuvent devenir déséquilibrées au fil du temps car le fait de connaître uniquement l'adresse IP du serveur proxy permet à Authorized Buyers ne peut pas déterminer quel serveur d'enchérisseurs reçoit chaque appel. Au fil du temps, à mesure qu'Authorized Buyers établit et conclut et que les serveurs de l'enchérisseur redémarre, le nombre de connexions mappés à chacun peuvent devenir très variables.

Lorsque certaines connexions sont fortement utilisées, d'autres connexions ouvertes peuvent restent principalement inactifs, car ils ne sont pas nécessaires à ce moment-là. En tant que Étant donné que le trafic d'Authorized Buyers évolue, les connexions inactives peuvent devenir actives. connexions peuvent devenir inactives. Cela peut entraîner des charges inégales sur les serveurs de votre système d'enchères si les connexions sont mal regroupées. Google tente d'éviter cela en en fermant toutes les connexions après 10 000 requêtes, afin de rééquilibrer automatiquement connexions au fil du temps. Si vous constatez toujours que le trafic est toujours déséquilibré dans votre vous pouvez prendre certaines mesures supplémentaires:

  1. Sélectionnez le backend par requête plutôt qu'une fois par connexion. si vous utilisez des proxys frontend.
  2. Spécifiez un nombre maximal de requêtes par connexion via un équilibreur de charge matériel ou un pare-feu, le mappage est fixe une fois les connexions établies. Notez que Google spécifie déjà une limite supérieure de 10 000 requêtes par connexion, donc vous ne devez indiquer une valeur plus stricte que si le nombre de caractères les connexions qui deviennent mises en cluster dans votre environnement. Dans Apache, par exemple, définir MaxKeepAliveRequests sur 5 000
  3. Configurer les serveurs de l'enchérisseur pour qu'il surveille ses taux de demandes et en conclut certains de leurs propres connexions si elles traitent systématiquement trop de requêtes par rapport à leurs pairs.

Gérez la surcharge de façon optimale

Dans l'idéal, les quotas doivent être suffisamment élevés pour que votre système d'enchères puisse recevoir qu'il peut traiter, mais pas plus. En pratique, maintenir les quotas à un niveau aux niveaux optimaux est une tâche difficile et des surcharges peuvent survenir l'interruption d'un backend lors des pics d'activité, la répartition du trafic que chaque requête nécessite davantage de traitement ou qu'une valeur de quota venant d'être définie trop élevée. Il est donc judicieux de tenir compte du comportement de votre système d'enchères car le trafic entrant est trop important.

Pour tenir compte des variations de trafic temporaires (jusqu'à une semaine) entre régions (en particulier entre l'Asie et l'ouest des États-Unis, et l'est des États-Unis et l'ouest des États-Unis). nous recommandons une marge de 15% entre le pic de sept jours et le nombre de RPS par transaction. Emplacement.

En termes de comportement en cas de charges importantes, les enchérisseurs se divisent en trois grandes catégories catégories:

La fonction « répondre à tout » enchérisseur

Bien qu'il soit simple à mettre en œuvre, cet enchérisseur est le moins efficace surchargés. Il essaie simplement de répondre à chaque demande d'enchère et mettre en file d'attente celles qui ne peuvent pas être diffusées immédiatement. Scénario qui s'ensuit est souvent quelque chose comme ceci:

  • Plus le taux de requêtes augmente, plus la latence des requêtes augmente. début du délai avant expiration
  • Les temps de latence s'allongent à mesure que les taux d'appels approchent.
  • La limitation intervient, ce qui réduit considérablement le nombre d'appels autorisés
  • La latence commence à se redresser, ce qui réduit la limitation
  • Le cycle de recommence.

Le graphique de latence de ce système d'enchères ressemble à une courbe en dents de scie très abrupte. du modèle. Les requêtes en file d'attente provoquent aussi le lancement de la pagination par le serveur la mémoire ou d'effectuer toute autre action pouvant entraîner un ralentissement à long terme, et les latences ne récupèrent pas du tout avant la fin des pics d'activité, ce qui entraîne une baisse des appels pendant toute la période de pointe. Dans les deux cas, moins d'accroches sont créées que si le quota avait simplement été défini sur une valeur inférieure.

L'erreur "en cas de surcharge" enchérisseur

Cet enchérisseur accepte les appels jusqu'à un certain tarif, puis commence à renvoyer pour certaines accroches. Cela peut se faire par le biais de délais d'inactivité internes, mise en file d'attente de connexion (contrôlée par ListenBackLog sur Apache) Implémentation d'un mode d'abandon probabiliste lorsque l'utilisation ou les latences sont trop élevées élevée ou un autre mécanisme. Si Google observe un taux d'erreur supérieur à 15%, nous allons commencer à limiter. Contrairement à la « réponse à tout » enchérisseur, cet enchérisseur « réduit ses pertes », ce qui lui permet de récupérer immédiatement lorsque le taux de demandes diminue vers le bas.

Le graphique de latence de cet enchérisseur ressemble à une dent de scie superficielle. modèle en cas de surcharge, localisé autour de la valeur maximale acceptable taux de conversion.

L'opérateur "no-bid" en cas de surcharge enchérisseur

Cet enchérisseur accepte les appels jusqu'à un certain tarif, puis commence à renvoyer "no-bid" en cas de surcharge. Semblable à "Erreur en cas de surcharge" un enchérisseur, cela peut être mis en œuvre de différentes manières. La différence ici est que est renvoyé à Google, de sorte que nous ne réduisons jamais les demandes d'appel. La est absorbée par les machines frontend, qui n'autorisent que le trafic pour accéder aux backends.

Le graphique de latence pour cet enchérisseur montre un plateau qui (artificiellement) cesse de mettre en parallèle le taux de requêtes lors des pics d'activité et une baisse correspondante du nombre la fraction des réponses contenant une enchère.

Nous vous recommandons d'associer l'erreur en cas de surcharge avec l'option "no-bid" en cas de surcharge, de la manière suivante:

  • Surprovisionner les frontaux et les configurer en mode erreur en cas de surcharge, afin d'optimiser le nombre de connexions auxquelles elles peuvent répondre d'une manière ou d'une autre.
  • En cas d'erreur en cas de surcharge, les machines frontend peuvent utiliser un "no-bid" standardisé et n'ont pas besoin d'analyser la requête.
  • Mettre en œuvre une vérification de l'état des backends, de sorte que si aucun d'entre eux ne dispose d'une capacité suffisante, ils affichent une erreur "no bid" de réponse.

Cela permet d'absorber une certaine surcharge et offre aux backends répondre à exactement autant de requêtes qu'il peut en traiter. Vous pouvez penser à cela comme "no-bid" en cas de surcharge avec des machines d'interface revenant au système "Surcharge" lorsque le nombre de requêtes est considérablement plus élevé que prévu.

Si vous avez reçu une notification de type "répondre à tout" dans votre système d'enchères, envisagez de le transformer une erreur en cas de surcharge en ajustant le comportement de la connexion refuse d'être surchargée. Bien que cela entraîne davantage d'erreurs, réduit les délais avant expiration et empêche le serveur de parvenir à un état ne peut répondre à aucune requête.

Répondre aux pings

S'assurer que votre enchérisseur peut répondre aux demandes ping, même sans connexion la gestion en elle-même, est étonnamment important pour le débogage. Google utilise un ping demandes de contrôle de l'intégrité et de débogage de l'état du système d'enchères, fermeture de la connexion le comportement, la latence, etc. Les requêtes ping se présentent sous la forme suivante:

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

JSON OpenRTB

"id": "4YB27BCXimH5g7wB39nd3t"

Protobuf OpenRTB

id: "7xd2P2M7K32d7F7Y50p631"

Gardez à l'esprit que, contrairement à ce à quoi vous pouvez vous attendre, la demande ping ne contient espaces publicitaires. Comme indiqué ci-dessus, ne fermez pas la connexion après avoir répondu à une requête ping.

Envisager l'appairage

Un autre moyen de réduire la latence ou la variabilité du réseau consiste à établir un appairage avec Google. L'appairage permet d'optimiser le chemin emprunté par le trafic pour accéder à votre système d'enchères. La les points de terminaison de connexion restent les mêmes, mais les liens intermédiaires changent. Consultez le Consultez le guide d'appairage pour en savoir plus. La de considérer l'appairage comme une bonne pratique peut être résumé comme suit:

  • Sur Internet, les liens de transports en commun sont principalement choisis par le biais le routage, qui trouve le lien le plus proche en dehors de notre réseau qui peut obtenir paquet vers sa destination et le achemine via cette liaison. Quand ? le trafic traverse une section de backbone appartenant à un fournisseur avec lequel nous avons de connexions d'appairage, le lien choisi est probablement proche de l'emplacement le démarrage du paquet. Au-delà de ce point, nous n'avons aucun contrôle sur la route du paquet suit à l'enchérisseur, il peut donc être renvoyé vers d'autres systèmes autonomes (réseaux) tout au long du projet.

  • En revanche, lorsqu'un accord d'appairage direct est en place, les paquets sont toujours envoyées via une liaison d'appairage. Quelle que soit l'origine du paquet, il parcourt les liens détenus ou loués par Google jusqu'à atteindre le qui doit être proche de celui du système d'enchères. Le trajet inverse se connecte au réseau Google et reste sur le réseau réseau le reste du processus. Conserver la majeure partie du trajet sur les ressources gérées par Google de l'infrastructure garantit que le paquet suit une route à faible latence et évite une grande variabilité potentielle.

Envoyer un DNS statique

Nous recommandons aux acheteurs de toujours envoyer un seul résultat DNS statique à Google et de compter sur Google pour gérer la diffusion du trafic.

Voici deux pratiques courantes utilisées par les enchérisseurs les serveurs DNS lors du chargement équilibrer ou gérer la disponibilité:

  1. Le serveur DNS fournit une adresse ou un sous-ensemble d'adresses en réponse à une requête, puis passer en revue cette réponse d'une manière ou d'une autre.
  2. Le serveur DNS répond toujours avec le même ensemble d'adresses, mais des cycles l'ordre des adresses dans la réponse.

La première technique est mauvaise pour l'équilibrage de charge, car il y a beaucoup de mise en cache plusieurs niveaux de la pile, et il est peu probable que les tentatives de contournement de la mise en cache obtenir les résultats préférés, puisque Google facture le temps de résolution DNS de l'enchérisseur.

La deuxième technique ne permet aucun équilibrage de charge, sélectionne aléatoirement une adresse IP dans la liste de réponses DNS, de sorte que l'ordre dans la réponse n'a pas d'importance.

Si un enchérisseur effectue une modification DNS, Google respectera la valeur TTL(Time To Live) qui était défini dans ses enregistrements DNS, mais l'intervalle d'actualisation reste incertain.