Prácticas recomendadas para las aplicaciones de RTB

En esta guía, se explican las prácticas recomendadas a tener en cuenta cuando se desarrollan aplicaciones. de acuerdo con el protocolo 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. Cerrando menos puedes reducir la cantidad de conexiones que se deben abrir de nuevo.

Primero, cada conexión nueva requiere un recorrido de ida y vuelta adicional de red para establecer. 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.

Segundo, muchos servidores web generan un subproceso de trabajador dedicado para cada conexión establecidos. 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. Es una gran cantidad de sobrecarga innecesaria.

Evita cerrar conexiones

Primero, ajusta el comportamiento de conexión. La mayoría de los valores predeterminados del servidor con grandes cantidades de clientes, y cada uno de ellos hace que un 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. Mié te recomendamos que establezcas lo siguiente:

• Tiempo de espera de inactividad a 2.5 minutos.
• Cantidad máxima de solicitudes en una conexión a la más alta el valor 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 las conexiones equilibradas

Si Authorized Buyers se conecta a los servidores de tu ofertante a través de un servidor proxy, las conexiones pueden desequilibrarse con el tiempo porque, con solo conocer la dirección IP del servidor proxy, no puede determinar qué servidor de ofertantes recibe cada solicitud de oferta. Con el tiempo, a medida que Authorized Buyers se establezca y cierre y los servidores del ofertante, la cantidad de conexiones asignados a cada uno puede volverse muy variable.

Cuando algunas conexiones se usan en gran medida, es posible que otras permanecen inactivos en su mayoría porque no son necesarios 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 evitarlo, Cerrar todas las conexiones después de 10,000 solicitudes para volver a balancear automáticamente conexiones de red 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, establecer MaxKeepAliveRequests en 5,000
3. Configurar los servidores del ofertante para supervisar sus porcentajes de solicitudes y cerrar algunas de sus propias conexiones si manejan demasiadas solicitudes de forma constante 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, resulta útil considerar cómo se comportará tu ofertante ingresa demasiado tráfico.

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

En cuanto al comportamiento en cargas pesadas, los ofertantes se dividen en tres categorías: categorías:

La respuesta a todo ofertante

Si bien es fácil de implementar, este ofertante tiene una mejor tarifa cuando sobrecargado. Simplemente intenta responder a todas las solicitudes de oferta recibidas lo que importa y se pone en cola aquello que no se puede entregar de inmediato. Situación hipotética que resulta, a menudo, algo así:

• 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 durante todo el período de tráfico máximo. En cualquier caso, se realizan menos textos destacados o que si la cuota se hubiera establecido en un valor inferior.

El error de sobrecarga ofertante

Este ofertante acepta solicitudes de oferta hasta un determinado porcentaje y, luego, comienza a devolver errores en 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 con la limitación. A diferencia de la opción "responder a todo", ofertante, este ofertante "corta sus pérdidas", lo que le permite recuperarse de inmediato cuando aumentan los porcentajes de solicitudes fuera de servicio.

El gráfico de latencia de este ofertante se asemeja a un diente de sierra superficial tradicional durante las sobrecargas, localizado en torno al máximo aceptable tasa.

La estrategia de oferta ofertante

Este ofertante acepta solicitudes de oferta hasta un determinado porcentaje y, luego, comienza a devolver “sin oferta” para evitar sobrecargas. Similar al mensaje “error en sobrecarga” ofertante, Esto se puede implementar de varias maneras. Lo que cambia es que no se devuelve a Google, de manera que nunca limitemos las solicitudes de oferta. 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 ofertar sobre 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 frontend pueden usar un parámetro estándar "no-bid" respuesta y no necesita analizar la solicitud en absoluto.
• 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 algo de sobrecarga y da a los backends la oportunidad responden a exactamente la mayor cantidad de solicitudes posible. Puedes pensar en esto como "no ofertar por sobrecarga" con máquinas frontend recurriendo a “error en sobrecarga" cuando los recuentos de solicitudes son considerablemente 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 provoca que se devuelvan más errores, reduce los tiempos de espera y evita que el servidor entre en un estado en el que no puede responder a ninguna solicitud.

Responde 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:

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

"id": "4YB27BCXimH5g7wB39nd3t"

id: "7xd2P2M7K32d7F7Y50p631"

Al contrario de lo que imaginas, la solicitud de ping no contiene espacios publicitarios. Además, como se detalló anteriormente, 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. El los extremos de conexión permanecen iguales, pero los vínculos intermedios cambian. Consulta la Guía de intercambio de tráfico 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 transporte público se eligen principalmente a través de “hot-potato” enrutamiento", que encuentra el vínculo más cercano fuera de nuestra red que puede obtener una el paquete a su destino y lo enruta a través de ese vínculo. Cuándo el tráfico recorre una sección de la red troncal que es propiedad de un proveedor con el que conexiones de intercambio de tráfico, es probable que el vínculo elegido esté cerca de inicios de paquetes. 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. Viaje inverso comienza con un salto corto a la Red de Google y permanece en la establecer conexión con tu red el resto del tiempo. Mantener la mayor parte del viaje en un servicio administrado por Google garantiza que el paquete tome una ruta de baja latencia y evita mucha variabilidad potencial.

Enviar DNS estático

Les recomendamos a los compradores que siempre envíen un solo resultado de DNS estático a Google y que en Google para manejar 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 no es buena para el balanceo de cargas, ya que hay mucho almacenamiento en caché múltiples niveles de la pila y los intentos de evitar el almacenamiento en caché probablemente no obtener los resultados preferidos, ya que Google cobra el tiempo de resolución de DNS al ofertante.

La segunda técnica no logra balancear las cargas porque Google selecciona al azar una dirección IP de la lista de respuesta de DNS para que el orden en la la respuesta no importa.

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.