Prácticas recomendadas para las aplicaciones de RTB

En esta guía, se explican las prácticas recomendadas que debes tener en cuenta cuando desarrollas aplicaciones según el Protocolo de RTB.

Administra conexiones

Mantén las conexiones activas

Establecer una conexión nueva aumenta las latencias y lleva mucho más recursos en ambos extremos que reutilizar uno existente. Si cierras menos conexiones, puedes reducir la cantidad de conexiones que se deben volver a abrir.

En primer lugar, cada conexión nueva requiere un recorrido de red adicional para establecerse. Como establecemos conexiones a pedido, la primera solicitud en un conexión tiene un plazo efectivo más corto y es más probable que se agote el tiempo de espera que solicitudes posteriores. Los tiempos de espera adicionales aumentan la tasa de error, lo que puede provocar se limite a su ofertante.

En segundo lugar, muchos servidores web crean un subproceso de trabajo dedicado para cada conexión establecida. Esto significa que, para cerrar y volver a crear la conexión, el servidor debe cerrarse y descartarse un subproceso, asignar uno nuevo, hacerlo ejecutable y y compila el estado de conexión antes de procesar la solicitud. Eso es mucha carga innecesaria.

Evita cerrar conexiones

Para comenzar, ajusta el comportamiento de la conexión. La mayoría de los valores predeterminados del servidor están diseñados para entornos con una gran cantidad de clientes, cada uno de los cuales realiza una pequeña cantidad de solicitudes. Para RTB, en cambio, un grupo pequeño de máquinas envía solicitudes en de una gran cantidad de navegadores, en términos relativos. Debajo de estos tiene sentido reutilizar las conexiones tantas veces como sea posible. Te recomendamos que configures lo siguiente:

  • Tiempo de espera de inactividad a 2.5 minutos.
  • Es la cantidad máxima de solicitudes en una conexión al valor más alto posible.
  • Cantidad máxima de conexiones al valor más alto que puede tener tu RAM adaptarse, pero asegúrate de verificar que la cantidad de conexiones no acerca ese valor demasiado de cerca.

En Apache, por ejemplo, esto implicaría configurar De KeepAliveTimeout a 150, de MaxKeepAliveRequests a cero y MaxClients a un valor que depende del tipo de servidor.

Una vez ajustado tu comportamiento de conexión, asegúrate también de que tu el código del ofertante no cierra las conexiones innecesariamente. Por ejemplo, si tienes código de frontend que muestra un valor predeterminado "sin oferta" respuesta en caso de que el backend o tiempos de espera, asegúrate de que el código devuelva su respuesta sin cerrar conexión. De esa manera, evita la situación en la que si el ofertante obtiene sobrecargado, las conexiones comienzan a cerrarse y aumenta la cantidad de tiempos de espera lo que causa que se limite su ofertante.

Mantén el equilibrio de las conexiones

Si Authorized Buyers se conecta a los servidores de tu oferta a través de un servidor proxy, es posible que las conexiones se desbalanceen con el tiempo, ya que, como solo se conoce la dirección IP del servidor proxy, Authorized Buyers no puede determinar qué servidor de oferta recibe cada texto destacado. Con el tiempo, a medida que Authorized Buyers establece y cierra conexiones, y se reinician los servidores del ofertante, la cantidad de conexiones asignadas a cada uno puede variar mucho.

Cuando algunas conexiones se usan mucho, es posible que otras conexiones abiertas permanezcan inactivas porque no se necesitan en ese momento. Como Cambios en el tráfico de Authorized Buyers, por lo que las conexiones inactivas pueden activarse. conexiones pueden quedar inactivas. Es posible que se generen cargas desiguales en los servidores de ofertantes. si las conexiones están mal agrupadas. Google intenta evitar esto cerrando todas las conexiones después de 10,000 solicitudes para reequilibrar automáticamente las conexiones activas con el tiempo. Si aún observas que el tráfico está desequilibrado en tu puedes seguir estos pasos:

  1. Selecciona el backend por solicitud en lugar de una vez por conexión si usas proxies de frontend.
  2. Especifica una cantidad máxima de solicitudes por conexión si estás de acuerdo conexiones mediante proxy a través de un balanceador de cargas de hardware o firewall, y la de la asignación se corrige una vez que se establecen las conexiones. Ten en cuenta que Google especifica un límite superior de 10,000 solicitudes por conexión, solo deberías proporcionar un valor más estricto si aún encuentras conexiones que se agrupan en clústeres en tu entorno. En Apache, por ejemplo, configura MaxKeepAliveRequests en 5,000.
  3. Configura los servidores del ofertante para que supervisen sus tasas de solicitudes y cierren algunas de sus propias conexiones si, de forma constante, controlan demasiadas solicitudes en comparación con sus pares.

Controla la sobrecarga correctamente

Lo ideal sería que las cuotas fueran lo suficientemente altas para que tu ofertante pueda recibir que puede manejar, pero no más que eso. En la práctica, mantener las cuotas en niveles óptimos es una tarea difícil, y ocurren sobrecargas para una variedad de un backend que falla durante las horas de mayor demanda, una mezcla de tráfico que cambia para que se requiere más procesamiento para cada solicitud o un valor de cuota que se acaba de establecer demasiado alto. Por lo tanto, vale la pena considerar cómo se comportará tu oferta con demasiado tráfico entrante.

Para adaptarse a los cambios temporales de tráfico (hasta una semana) entre regiones (especialmente entre Asia y el oeste de EE.UU., y el este y el oeste de EE.UU.), recomendamos un margen del 15% entre el máximo de 7 días y las QPS por ubicación de mercado.

En términos de comportamiento bajo cargas pesadas, los ofertantes se dividen en tres categorías generales:

El ofertante "responde a todo"

Si bien es sencillo de implementar, este ofertante tiene el peor rendimiento cuando se sobrecarga. Simplemente intenta responder a todas las solicitudes de oferta recibidas se pongan en cola las que no puedan entregarse de inmediato. La situación que se produce suele ser algo como lo siguiente:

  • A medida que aumenta el porcentaje de solicitudes, también lo hacen las latencias comenzar a agotar el tiempo de espera
  • Las latencias aumentan de manera abrupta a medida que las tasas de solicitudes de oferta se acercan al pico
  • Se activa la regulación, lo que reduce considerablemente la cantidad de textos destacados permitidos
  • Las latencias comienzan a recuperarse, lo que provoca una reducción de la limitación
  • El ciclo vuelve a comenzar.

El gráfico de latencia para este ofertante se asemeja a un diente de sierra muy pronunciado . Como alternativa, las solicitudes en cola hacen que el servidor inicie la paginación memoria o hacer algo más que provoca una demora a largo plazo, y las latencias no se recuperan hasta que finalizan las horas de mayor demanda, lo que genera una depresión depresiva durante todo el período de tráfico máximo. En cualquier caso, se realizan o responden menos textos destacados que si la cuota se hubiera establecido en un valor más bajo.

El ofertante con "error de sobrecarga"

Este ofertante acepta textos destacados hasta una tasa determinada y, luego, comienza a mostrar errores para algunos textos destacados. Esto puede hacerse mediante tiempos de espera internos, inhabilitando puesta en cola de conexiones (controlada por ListenBackLog en Apache) la implementación de un modo de caída probabilístico cuando el uso o las latencias son demasiado alto o algún otro mecanismo. Si Google observa una tasa de error superior al 15%, comenzaremos a reducir la velocidad. A diferencia del ofertante que "responde a todo", este ofertante "corta sus pérdidas", lo que le permite recuperarse de inmediato cuando disminuyen las tasas de solicitudes.

El gráfico de latencia de este ofertante se asemeja a un patrón de sierra suave durante las sobrecargas, localizado alrededor de la tasa máxima aceptable.

El ofertante que no realiza ofertas en sobrecarga

Este ofertante acepta textos destacados hasta una tasa determinada y, luego, comienza a mostrar respuestas de "sin oferta" para cualquier sobrecarga. Al igual que el ofertante de "error de sobrecarga", esto se puede implementar de varias maneras. La diferencia es que no se muestra ningún indicador a Google, por lo que nunca reducimos el tamaño de los textos destacados. El la sobrecarga se absorbe por las máquinas frontend, lo que solo permite el tráfico que puedan manejar para continuar a través de los backends.

El gráfico de latencia de este ofertante muestra una meseta que (artificialmente) deja de hacer paralelamente el porcentaje de solicitudes en las horas de mayor demanda y la disminución correspondiente la fracción de respuestas que contienen una oferta.

Recomendamos combinar la columna "error en sobrecarga" con el mensaje "no-bid on sobrecarga" de la siguiente manera:

  • Aprovisionar en exceso los frontends y configurarlos en errores de sobrecarga para maximizar la cantidad de conexiones a las que pueden responder de alguna forma
  • Cuando se produce un error de sobrecarga, las máquinas de frontend pueden usar una respuesta predeterminada de "sin oferta" y no es necesario analizar la solicitud.
  • Implementar la verificación de estado de los backends, de modo que, si no hay suficiente capacidad disponible, se muestre un error de “sin oferta” respuesta.

Esto permite absorber parte de la sobrecarga y les brinda a los backends la oportunidad de responder exactamente tantas solicitudes como puedan controlar. Puedes considerar esto como "sin oferta en sobrecarga", con máquinas de frontend que recurren a "error en sobrecarga" cuando los recuentos de solicitudes son significativamente más altos de lo esperado.

Si tienes la opción "Responde todo" ofertante, considera transformarlo en un "error de sobrecarga" como ofertante ajustando el comportamiento de conexión para que se aplique se niega a sobrecargarse. Si bien esto hace que se muestren más errores, reduce los tiempos de espera y evita que el servidor entre en un estado en el que no pueda responder a ninguna solicitud.

Responde a los pings

Asegúrate de que tu ofertante pueda responder a las solicitudes de ping sin conexión de proyectos en sí, es sorprendentemente importante para la depuración. Google usa ping solicitudes de comprobación de estado y depuración del estado de ofertante, cierre de conexión la latencia, el comportamiento y la latencia, entre otros. Las solicitudes de ping tienen la siguiente forma:

Protobuf de OpenRTB

id: "7xd2P2M7K32d7F7Y50p631"

JSON de OpenRTB

{
  "id": "4YB27BCXimH5g7wB39nd3t"
}

Google (obsoleto)

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

Ten en cuenta que, a diferencia de lo que podrías esperar, la solicitud de ping no contiene ningún espacio de anuncios. Además, como se detalla más arriba, no debes cerrar la conexión después de responder a una solicitud de ping.

Considera el intercambio de tráfico

Otra forma de reducir la latencia o la variabilidad de la red es intercambiar tráfico con Google. El intercambio de tráfico ayuda a optimizar la ruta que sigue el tráfico para llegar a tu ofertante. Los extremos de conexión permanecen iguales, pero los vínculos intermedios cambian. Consulta la guía de peering para obtener más detalles. El para considerar el intercambio de tráfico como una práctica recomendada se puede resumir de la siguiente manera:

  • En Internet, los vínculos de tránsito se eligen principalmente a través del "enrutamiento de papas calientes", que encuentra el vínculo más cercano fuera de nuestra red que puede llevar un paquete a su destino y enruta el paquete a través de ese vínculo. Cuando el tráfico atraviesa una sección de la red troncal que pertenece a un proveedor con el que tenemos muchas conexiones de intercambio de datos, es probable que el vínculo elegido esté cerca de donde comienza el paquete. Más allá de ese punto, no tenemos control de la ruta a la que se dirige se le sigue al ofertante, por lo que podría rebotar en otros sistemas autónomos (redes) durante el proceso.

  • Por el contrario, cuando se aplica un acuerdo de intercambio de tráfico directo, siempre se envía a lo largo de un vínculo de intercambio de tráfico. Sin importar dónde se origine el paquete, recorre los vínculos que Google posee o arrienda hasta llegar al de intercambio de tráfico, que debe estar cerca de la ubicación del ofertante. El viaje inverso comienza con un salto corto a la red de Google y permanece en la red de Google durante el resto del recorrido. Mantener la mayor parte del viaje en la infraestructura administrada por Google garantiza que el paquete tome una ruta de baja latencia y evite mucha variabilidad potencial.

Envía un DNS estático

Recomendamos que los compradores siempre envíen un solo resultado de DNS estático a Google y que confíen en Google para que controle la entrega del tráfico.

A continuación, se incluyen dos prácticas comunes Servidores DNS cuando se intenta cargar equilibrar o administrar la disponibilidad:

  1. El servidor DNS reparte una dirección, o un subconjunto de direcciones, en respuesta a una consulta y recorrer esta respuesta de alguna manera.
  2. El servidor DNS siempre responde con el mismo conjunto de direcciones, pero el orden de las direcciones en la respuesta.

La primera técnica es deficiente en el balanceo de cargas, ya que hay mucha almacenamiento en caché en varios niveles de la pila, y es probable que los intentos de omitir el almacenamiento en caché tampoco obtengan los resultados preferidos, ya que Google le cobra al ofertante el tiempo de resolución de DNS.

La segunda técnica no logra el balanceo de cargas, ya que Google selecciona de forma aleatoria una dirección IP de la lista de respuestas de DNS, por lo que no importa el orden de la respuesta.

Si un ofertante realiza un cambio de DNS, Google respetará el TTL(tiempo de actividad) que se establecido en sus registros DNS, pero el intervalo de actualización sigue siendo incierto.