Bonnes pratiques pour les applications RTB

Ce guide décrit les bonnes pratiques à suivre lors du développement d'applications conformément au protocole RTB.

Gérer les connexions

Maintenir les connexions actives

L'établissement d'une nouvelle connexion augmente les latences et nécessite beaucoup plus de ressources à la fois à l'origine et à la destination qu'une réutilisation d'une connexion existante. En fermant moins de connexions, vous pouvez réduire le nombre de connexions qui doivent être ouvertes à 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 demandes ultérieures. Tout délai avant expiration supplémentaire augmente le taux d'erreur, ce qui peut entraîner la limitation de votre enchérisseur.

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

Éviter de fermer les connexions

Commencez par ajuster le comportement de 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 conditions, il est logique de réutiliser les connexions autant de fois que possible. Nous vous recommandons de définir les éléments suivants :

• Délai d'inactivité défini sur 2,5 minutes.
• Nombre maximal de requêtes sur une connexion à la valeur la plus élevée possible.
• Nombre maximal de connexions à la valeur la plus élevée que votre RAM peut accueillir, en veillant à vérifier que le nombre de connexions ne s'approche pas trop de cette valeur.

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 des délais d'inactivité, assurez-vous que le code renvoie sa réponse sans fermer . Vous évitez ainsi que votre enchérisseur ne soit surchargé, que les connexions ne commencent à se fermer et que le nombre de délais d'attente augmente, ce qui entraîne la limitation de votre enchérisseur.

Maintenir l'équilibre des connexions

Si Authorized Buyers se connecte aux serveurs de votre enchérisseur via un serveur proxy, les connexions peuvent devenir déséquilibrées au fil du temps. En effet, ne connaissant que l'adresse IP du serveur proxy, Authorized Buyers ne peut pas déterminer quel serveur d'enchérisseur 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 rester principalement inactives, car elles ne sont pas nécessaires pour le moment. 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 fermant toutes les connexions après 10 000 requêtes, afin de rééquilibrer automatiquement les connexions actives au fil du temps. Si le trafic reste déséquilibré dans votre environnement, vous pouvez prendre d'autres mesures :

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. Vous ne devriez donc fournir une valeur plus stricte que si vous constatez toujours que des connexions actives se regroupent dans votre environnement. Dans Apache, par exemple, définissez 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érer la surcharge de manière élégante

Dans l'idéal, les quotas doivent être suffisamment élevés pour que votre enchérisseur puisse recevoir toutes les requêtes 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 fluctuations temporaires du trafic (jusqu'à une semaine) entre les 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 d'ajouter une marge de 15 % entre le pic sur sept jours et le débit de requêtes par seconde par zone de trading.

En termes de comportement en cas de charge importante, les enchérisseurs se répartissent en trois grandes catégories :

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

Bien qu'il soit simple à mettre en œuvre, cet enchérisseur est le moins performant 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. Le scénario qui s'ensuit est souvent le suivant :

• À mesure que le taux de requêtes augmente, les latences de requêtes augmentent également, jusqu'à ce que toutes les requêtes commencent à expirer.
• Les temps de latence s'allongent à mesure que les taux d'appels approchent.
• Le débit est limité, 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. En outre, les requêtes mises en file d'attente entraînent le démarrage de la pagination de la mémoire ou une autre action qui provoque un ralentissement à long terme. Les latences ne se rétablissent pas du tout tant que les pics d'activité ne sont pas terminés, ce qui entraîne une baisse des taux de rappel 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'enchérisseur "error on overload"

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 constate 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 augmente vers le bas.

Le graphique de la latence pour cet enchérisseur ressemble à un motif en dents de scie peu profond lors des surcharges, localisé autour du taux maximal acceptable.

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. Comme pour l'enchérisseur "erreur en cas de surcharge", cette fonctionnalité peut être implémentée de plusieurs manières. La différence ici est que est renvoyé à Google. Ainsi, nous ne réduisons jamais les demandes d'appel. La surcharge est absorbée par les machines de front-end, qui ne permettent que le trafic qu'elles peuvent gérer de continuer vers les backends.

Le graphique de latence de cet enchérisseur montre un plateau qui (artificiellement) cesse de suivre le taux de requêtes aux heures de pointe, et une baisse correspondante de 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:

• Surprovisionnez les interfaces et définissez-les sur "erreur en cas de surcharge" pour maximiser le nombre de connexions auxquelles elles peuvent répondre d'une manière ou d'une autre.
• En cas d'erreur de surcharge, les machines de front-end peuvent utiliser une réponse prédéfinie "pas d'enchère" et n'ont pas besoin d'analyser la requête.
• Implémentez une vérification de l'état des backends afin que, si aucun n'a une capacité disponible suffisante, ils renvoient une réponse "pas d'enchère".

Cela permet d'absorber une partie de la surcharge et donne aux backends la possibilité de répondre exactement au nombre de requêtes qu'ils peuvent gérer. 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 requêtes de ping, bien que ce ne soit pas la gestion des connexions en soi, 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:

id: "7xd2P2M7K32d7F7Y50p631"

{
  "id": "4YB27BCXimH5g7wB39nd3t"
}

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

Gardez à l'esprit que, contrairement à ce que vous pourriez penser, la requête ping ne contient aucun emplacement publicitaire. 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 peering avec Google. Le peering permet d'optimiser le chemin emprunté par le trafic pour atteindre votre enchérisseur. 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. Voici pourquoi le peering est une bonne pratique :

• Sur Internet, les liens de transports en commun sont principalement choisis par le biais 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. Quel que soit l'origine du paquet, il traverse les liens que Google possède ou loue jusqu'à atteindre le point de peering partagé, qui doit se trouver à proximité de l'emplacement de l'enchérisseur. 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 des serveurs DNS des enchérisseurs lorsqu'ils tentent de charger un solde ou de gérer la disponibilité :

1. Le serveur DNS distribue une adresse ou un sous-ensemble d'adresses en réponse à une requête, puis fait le tour de 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 fait tourner 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 modifie un enregistrement DNS, Google respectera la valeur TTL (Time To Live) définie dans ses enregistrements DNS, mais l'intervalle d'actualisation reste incertain.