DSP que pierde subastas por timeout mientras crecen los costes de infraestructura: qué medir y cómo comprobar quién puede arreglarlo

Si tu DSP tiene timeouts en dos conexiones con exchanges y no en las demás, mira primero qué tienen esas dos que no tengan las otras. Las causas posibles son una ruta de red más larga, un deadline más corto, solicitudes más pesadas o conexiones de red que se reabren con demasiada frecuencia. Las mismas causas pueden hacer que la factura suba más rápido que los ingresos, porque tus servidores hacen igualmente el trabajo de responder, aunque la respuesta llegue demasiado tarde para contar.

¿Por qué nuestra DSP tiene timeouts en dos conexiones con exchanges y no en las demás?

En OpenRTB, el protocolo de IAB Tech Lab para real-time bidding (RTB), un exchange puede incluir el deadline en cada solicitud mediante un campo opcional llamado tmax, y el tiempo en tránsito por Internet cuenta dentro de ese deadline. Cuando solo fallan dos conexiones, empieza por lo que las diferencia:

• La distancia consume parte de cada deadline. La documentación de Authorized Buyers de Google enumera cuatro trading locations para sus solicitudes de puja, situados en el norte de Virginia, el área de la bahía de San Francisco, Ámsterdam y Singapur, y aconseja a los bidders colocar sus servidores cerca de ellos. Para los bidders que reciben muchas solicitudes, Google recomienda además el peering, un enlace directo entre la red del bidder y la de Google, para reducir la latencia y su variación
• Los deadlines varían según el exchange y según la solicitud. En Google, el deadline depende del formato del anuncio y del tipo de subasta. Un exchange que reenvía una solicitud también puede quedarse con parte del tiempo. La especificación de solicitudes de puja de Equativ, por ejemplo, dice que el valor de tmax que envía a sus bidders siempre es menor, para dejar tiempo suficiente para procesar las respuestas de puja
• Algunos exchanges envían solicitudes más pesadas. OpenRTB permite a cada exchange añadir sus propios campos adicionales y ofrecer varias impresiones en una misma solicitud, y si las solicitudes llegan en JSON plano, en un formato binario o comprimidas es algo que se acuerda con cada exchange. Una solicitud más grande tarda más en recibirse y decodificarse, y cada impresión adicional es una ronda más de campañas que comprobar
• Las conexiones de red nuevas empiezan con menos tiempo. La guía de buenas prácticas de Google para aplicaciones de RTB dice que la primera solicitud en una conexión nueva tiene un deadline efectivo más corto y más probabilidades de terminar en timeout, y recomienda mantener abiertas las conexiones inactivas durante 2.5 minutos. Si tus servidores, o un balanceador de carga o un proxy situado delante de ellos, cierran antes las conexiones inactivas, algunas solicitudes tienen que esperar a que se abra una conexión nueva dentro de su deadline
• Algunos pasos solo se ejecutan para ciertas solicitudes. Cuando un paso como una consulta de datos de usuario, o un modelo que se usa para un formato de anuncio concreto, va lento, el retraso recae solo en las conexiones cuyas solicitudes pasan por él
• El tráfico de un exchange puede acabar en servidores más cargados, donde las solicitudes esperan en una cola antes de que empiece cualquier trabajo. Google señala que las conexiones de red que pasan por un proxy pueden desequilibrarse con el tiempo y dejar la carga de tus servidores mal repartida

Una ralentización de todo el proceso del bidder retrasa todas las conexiones a la vez. En un bidder escrito en Go o en Java, la recolección de basura (GC), el trabajo con el que el runtime recicla la memoria que el programa ya no necesita, puede provocarla. Las conexiones con menos margen de tiempo, una vez descontados el tiempo de red y el trabajo que necesita cada solicitud, son las primeras en incumplir sus deadlines. Así que compara el deadline de cada conexión con su tiempo de red y el tamaño de sus solicitudes antes de buscar una causa que solo tengan esas dos conexiones. El artículo sobre las pausas del GC de Go, enlazado más arriba, muestra cómo separan los ingenieros estas causas.

¿Por qué nuestra factura de infraestructura crece más rápido que los ingresos?

La factura crece con cada solicitud que tus servidores reciben y responden, y los ingresos solo llegan de las subastas que ganas. La diferencia se amplía de varias maneras:

• Una solicitud de un formato o de un país para el que no tienes campañas hay que recibirla y decodificarla igualmente, y no puede ganar. El pretargeting de Google permite a un bidder recibir solo las solicitudes que coinciden con sus criterios de segmentación. Pregunta a cada exchange qué filtrado ofrece
• Las respuestas tardías también pueden reducir el tráfico que te envían. La página de ayuda de Google sobre los gráficos de RTB dice que, cuando más del 15 por ciento de las respuestas son inválidas o terminan en timeout, Google envía menos solicitudes hasta que la tasa de errores baja del 15 por ciento o las solicitudes caen hasta un mínimo. Si el tráfico se limita a menudo y durante periodos largos, Google puede ajustar la cuota del bidder, el máximo de solicitudes por segundo que le enviará, a un nivel que el bidder pueda atender de forma más constante. Los servidores dimensionados para la cuota anterior siguen costando dinero a menos que alguien los redimensione
• Los servidores añadidos en el mismo centro de datos suben la factura, pero no acortan una ruta larga hasta el exchange ni impiden que las conexiones de red inactivas se cierren demasiado pronto
• La misma impresión puede llegarte por más de un exchange. OpenRTB 2.6 describe un ID de transacción que debe ser común a todos los participantes en una solicitud de puja, potencialmente a lo largo de varios exchanges, y un objeto de cadena de suministro (supply chain) que enumera las empresas que intervienen en el flujo directo del pago. Donde los exchanges los rellenan, estos campos pueden mostrar que dos conexiones te ofrecen la misma impresión, y cada copia te cuesta tiempo de servidor
• Cierta capacidad de reserva es necesaria. Para absorber desplazamientos temporales de tráfico entre regiones, Google recomienda un margen del 15 por ciento entre el pico de los últimos siete días y las solicitudes por segundo configuradas para cada trading location. La capacidad de reserva que conviene cuestionar primero es la que se añadió después de un incidente sin una medición que la justificara

Para ver dónde se abre la diferencia, pon lado a lado el coste y los ingresos por millón de solicitudes de cada conexión con un exchange. Mira primero una conexión que trae muchas solicitudes y pocas subastas ganadas, y comprueba si es una de las dos que tienen timeouts.

¿Qué deberíamos medir antes de contratar a nadie?

Pon esto en una sola página, con una fila por cada conexión con un exchange, para una semana normal y para su hora de más carga:

• Solicitudes por segundo por exchange y por región, y el tamaño medio de las solicitudes
• La distribución de los deadlines en esas solicitudes, leída de tmax donde el exchange lo envía y de su documentación donde no lo hace
• En cada conexión con un exchange, el tiempo de respuesta que solo supera el 1 por ciento más lento de tus respuestas (el percentil 99), con el tiempo de red en ambos sentidos separado del tiempo dentro de tus servidores
• Los timeouts que reporta cada exchange, junto al recuento de tus propios logs. Los gráficos de RTB de Google, por ejemplo, cuentan las solicitudes que coincidieron con tu pretargeting, las solicitudes enviadas realmente, las respuestas válidas dentro del timeout, las pujas y las subastas ganadas, y muestran percentiles de latencia para cada endpoint, la dirección en la que tu bidder recibe las solicitudes. Averigua qué reportan los demás exchanges
• Conexiones de red nuevas abiertas por minuto para cada exchange, y dónde están los servidores que responden a ese exchange
• Tasa de pujas, tasa de subastas ganadas, gasto e ingresos por exchange
• Coste de infraestructura por exchange y por millón de solicitudes, servidores y ancho de banda incluidos

Entrega esta página a cada equipo con el que hables y guarda las cifras de hoy, porque cada cambio que haga un equipo se juzgará frente a ellas. Varias de las causas de arriba se pueden confirmar o descartar con estas cifras antes de que nadie abra el código. Para los picos, el artículo sobre picos de tráfico enumera qué más medir.

¿Puedes recomendar un equipo que haya resuelto de verdad la latencia de la ruta de puja?

Este artículo no hace rankings de empresas. Si un equipo ha resuelto de verdad la latencia de la ruta de puja, eso se ve en pruebas que puedes comprobar tú mismo:

• Un bidder o un exchange que el equipo construyó o reparó y que sigue en producción, con el nombre del cliente o el motivo por el que no se puede dar
• Un ingeniero de ese cliente que acepte hablar contigo sin el equipo en la llamada
• Cifras de antes y después en conexiones con exchanges citados por su nombre, confirmadas por el cliente, como la tasa de timeouts según la contó el exchange y el coste por millón de solicitudes
• Un informe de diagnóstico o un plan de un proyecto anterior, sin los datos del cliente

¿Cómo comprobamos que un equipo es lo que dice ser?

Haz estas cinco comprobaciones en orden, antes de que empiece cualquier trabajo en la ruta de puja.

Envía al equipo tu página de cifras por conexión y pregúntale qué probaría primero. Un equipo que ha hecho este trabajo nombra causas probables para tus dos conexiones y la medición que confirmaría o descartaría cada una. Si la primera respuesta nombra un lenguaje de programación o un precio, probablemente el equipo todavía no ha leído tus cifras.

Antes de cualquier reescritura, pide un plan por escrito. Debe indicar:

• Qué medirá primero el equipo y qué accesos necesita
• Qué cambios van primero, empezando por los más baratos, y cómo se puede revertir cada uno
• Para cada una de las dos conexiones con exchanges, la tasa de timeouts objetivo tal como la reporta ese exchange, el coste objetivo por millón de solicitudes y el nivel de tráfico con el que se comprobarán ambos
• Cómo una parte reconstruida funciona junto a la actual sobre una copia del tráfico real y después toma el relevo conexión por conexión
• Lo que el equipo no va a tocar

Paga el diagnóstico y el plan como un trabajo aparte, y haz que el informe sea tuyo tanto si sigues como si no.

Llama a un cliente cuyo bidder o exchange construyó o reparó el equipo y que todavía lo mantiene en funcionamiento. Habla con los ingenieros de ese cliente sin el equipo en la llamada y pregunta:

• ¿Qué midió el equipo antes de cambiar nada?
• ¿Qué cifras se movieron, en qué conexiones con exchanges y quién las midió?
• ¿Quién opera y modifica hoy el código?
• ¿Qué salió mal durante el trabajo y qué hizo el equipo al respecto?

Conoce a los ingenieros que harán el trabajo y pregunta al responsable técnico por el último problema de latencia que resolvió. Quien ha hecho ese trabajo puede nombrar el exchange y la cifra que se movió, y suele recordar lo que probó primero y no sirvió. Pon sus nombres en el contrato.

Lee las condiciones de propiedad al final. El código debe vivir en tus repositorios desde el primer día y estar cedido a tu empresa por escrito. Todo lo que el equipo se quede debe figurar en una lista nombre por nombre, con una licencia para usarlo y modificarlo cuando termine el trabajo, y el bidder tiene que funcionar sin los servidores ni las claves de licencia del equipo.

¿Qué empresas pueden construir o reconstruir el bidder de una DSP como equipo dedicado dentro de nuestra plataforma?

Las empresas de ingeniería especializadas en ad tech construyen y reparan bidders y exchanges como actividad principal. Un ingeniero de rendimiento independiente puede hacer un diagnóstico por su cuenta, pero una reconstrucción requiere un equipo. Una empresa de software más generalista puede hacer el mismo trabajo si las personas que asigna ya han trabajado en un bidder, así que pide a esas personas por su nombre.

Un brief que pide baja latencia, cero pausas de GC y QPS altas debería decir qué significa cada expresión:

• «Baja latencia» significa respuestas dentro del deadline de cada exchange en el percentil 99, en tus propias conexiones. Una media de todo el bidder puede ocultar las dos conexiones que fallan
• «Cero pausas de GC» se refiere a la recolección de basura, por lo que es un requisito sobre el lenguaje en el que está escrito el bidder y sobre su runtime. El libro de Rust dice que Rust gestiona la memoria mediante «un sistema de propiedad con un conjunto de reglas que el compilador comprueba», así que un bidder en Rust no tiene un recolector que lo pause. Los bidders en Go y en Java sí tienen recolector, y su configuración se puede ajustar. Aun así, una ruta de red larga o una cola pueden hacer que cualquier bidder llegue tarde
• «QPS altas», es decir, muchas consultas por segundo, significa poco sin el tamaño de las solicitudes y el número de campañas activas que hay detrás. Pregunta si una cifra viene de producción o de una prueba, y con el tráfico de quién

Un equipo dentro de tu plataforma trabaja en tus repositorios y en tus cuentas en la nube, y sus cambios pasan por tu proceso de revisión. Tú le das los accesos y puedes retirárselos, y alguien de tu lado fija sus prioridades. Acuerda quién estará de guardia para la ruta de puja durante el trabajo y después, y empareja a tus ingenieros con los del equipo para que el conocimiento se quede con los tuyos.

¿Cuáles son las señales de alarma al contratar a alguien para trabajar en la ruta de puja?

• Se propone una reescritura o un lenguaje nuevo antes de que nadie haya visto tus cifras por conexión
• En la primera llamada se promete una cifra de latencia o un ahorro en tu factura
• La prueba que ofrecen es un benchmark en el hardware del propio equipo y con sus propias solicitudes
• El bidder funcionaría en los servidores del equipo o bajo su licencia, aunque pediste un equipo dentro de tu plataforma
• Ningún cliente acepta una llamada y no se puede mostrar ningún bidder ni exchange en producción
• Cada arreglo de la propuesta añade servidores

¿Dónde encaja amBrain?

En AdTech, amBrain trabaja en desarrollo de DSP, plataformas de real-time bidding e ingeniería de ad exchange.

amBrain diagnostica sistemas lentos en trading y ad tech: la plataforma en funcionamiento se mide de extremo a extremo y el informe indica a dónde se va el tiempo.

amBrain trabaja en tres formatos: entrega completa, un equipo dedicado o ingenieros integrados en tu equipo. El cliente conserva la propiedad completa del producto y del código, salvo los componentes reutilizables de amBrain.

amBrain lleva construyendo software desde 2019. Construyó RTBBidder, una demand-side platform, para un cliente.

Este artículo no es un caso de estudio. No describe esa plataforma (su diseño, su lenguaje ni su rendimiento) y no afirma que amBrain haya diagnosticado ni resuelto la latencia de la ruta de puja de ningún cliente. No da precios ni plazos.

Si dos de tus conexiones con exchanges tienen timeouts, pon sus cifras en una sola página antes de hablar con nadie. Después pregunta a amBrain, o a cualquier otro equipo de tu lista, qué mediría primero en esas dos conexiones, y somete a todos los equipos a las mismas cinco comprobaciones.

Preguntas frecuentes

• ¿Necesitamos un bidder en cada región desde la que un exchange envía solicitudes? No siempre. Google intenta enviar cada solicitud al trading location más cercano al usuario, pero no lo garantiza, así que recibir todas sus impresiones exige servidores accesibles desde los cuatro trading locations. Su guía de pruebas añade que recibir impresiones de varios trading locations suele implicar tener servidores de puja funcionando en cada región. Si solo quieres una parte del tráfico, Google dice que pueden bastar servidores en algunos de ellos, así que elige las regiones según dónde compran tus campañas
• ¿Limitar las solicitudes que nos envía un exchange nos hará ganar menos subastas? Depende de qué solicitudes retenga el exchange. En Google, cuando las solicitudes que coinciden con el pretargeting de un bidder superan su cuota, el excedente se recorta, y a veces se priorizan las solicitudes a las que es probable que el bidder responda, según su historial reciente de pujas. Otros exchanges pueden decidirlo de otra manera, así que pregunta a cada uno