DSP perdendo leilões por timeout enquanto os custos de infraestrutura crescem: o que medir e como verificar quem pode resolver

Se o seu DSP dá timeout em duas conexões de exchange e não nas outras, olhe primeiro para o que essas duas têm e as demais não. As causas possíveis são uma rota de rede mais longa, um deadline mais curto, requisições mais pesadas ou conexões de rede reabertas com frequência demais. As mesmas causas podem fazer a conta subir mais rápido que a receita, porque os seus servidores fazem o trabalho de qualquer jeito, mesmo para respostas que chegam tarde demais para contar.

Por que o nosso DSP dá timeout em duas conexões de exchange e não nas outras?

No OpenRTB, o protocolo do IAB Tech Lab para real-time bidding (RTB), uma exchange pode colocar o deadline em cada requisição por meio de um campo opcional chamado tmax, e o tempo gasto na Internet conta dentro desse deadline. Quando só duas conexões falham, comece pelo que as diferencia:

• A distância consome parte de cada deadline. A documentação do Authorized Buyers do Google lista quatro trading locations para as bid requests dele, no norte da Virgínia, na região da Baía de São Francisco, em Amsterdã e em Singapura, e aconselha os bidders a colocar os servidores perto deles. Para bidders que recebem muitas requisições, o Google também recomenda peering, uma ligação direta entre a rede do bidder e a do Google, para reduzir a latência e o quanto ela varia
• Os deadlines variam por exchange e por requisição. No Google, o deadline depende do formato do anúncio e do tipo de leilão. Uma exchange que repassa uma requisição adiante também pode ficar com parte do tempo para si. A especificação de bid request da Equativ, por exemplo, diz que o valor de tmax enviado aos bidders dela é sempre menor, para deixar tempo suficiente para processar as bid responses
• Algumas exchanges enviam requisições mais pesadas. O OpenRTB permite que cada exchange acrescente campos extras próprios e ofereça várias impressões em uma mesma requisição, e se as requisições chegam em JSON simples, em um formato binário ou comprimidas é algo combinado com cada exchange. Uma requisição maior leva mais tempo para ser recebida e decodificada, e cada impressão a mais é mais uma rodada de campanhas a verificar
• Conexões de rede novas começam com menos tempo. O guia de boas práticas do Google para aplicações de RTB diz que a primeira requisição em uma conexão nova tem um deadline efetivo mais curto e mais chance de dar timeout, e recomenda manter as conexões ociosas abertas por 2,5 minutos. Se os seus servidores, ou um balanceador de carga ou proxy na frente deles, fecham as conexões ociosas antes disso, algumas requisições precisam esperar que uma conexão nova seja aberta dentro do próprio deadline
• Algumas etapas só rodam para certas requisições. Quando uma etapa como uma consulta de dados de usuário, ou um modelo usado em um formato de anúncio específico, fica lenta, o atraso cai só sobre as conexões cujas requisições passam por ela
• O tráfego de uma exchange pode cair em servidores mais carregados, onde as requisições esperam em uma fila antes de qualquer trabalho começar. O Google observa que conexões de rede feitas através de um proxy podem ficar desbalanceadas com o tempo e deixar a carga desigual entre os seus servidores

Uma lentidão no processo inteiro do bidder atrasa todas as conexões ao mesmo tempo. Em um bidder em Go ou Java, a coleta de lixo (GC), o trabalho do runtime de reciclar a memória de que o programa não precisa mais, pode causar isso. As conexões com menos folga de tempo, depois de descontados o tempo de rede e o trabalho que cada requisição exige, são as primeiras a perder o deadline. Então compare o deadline de cada conexão com o tempo de rede e o tamanho das requisições dela antes de procurar uma causa que só essas duas conexões tenham. O artigo sobre pausas de GC no Go, com link acima, mostra como os engenheiros separam essas causas.

Por que a nossa conta de infraestrutura cresce mais rápido que a receita?

A conta cresce com cada requisição que os seus servidores recebem e respondem, e a receita só vem dos leilões que você ganha. A diferença aumenta de várias formas:

• Uma requisição de um formato ou país para o qual você não tem campanhas ainda precisa ser recebida e decodificada, e não tem como ganhar. O pretargeting do Google permite que um bidder receba só as requisições que correspondem aos seus critérios de segmentação. Pergunte a cada exchange que filtragem ela oferece
• Respostas atrasadas também podem reduzir o tráfego que você recebe. A página de ajuda do Google sobre os gráficos de RTB diz que, quando mais de 15 por cento das respostas são inválidas ou dão timeout, o Google envia menos requisições até que a taxa de erro caia abaixo de 15 por cento ou que as requisições cheguem a um mínimo. Se o tráfego é restringido com frequência e por longos períodos, o Google pode ajustar a cota do bidder, o máximo de requisições por segundo que ele vai enviar, para um nível que o bidder consiga atender de forma mais consistente. Servidores dimensionados para a cota antiga continuam custando dinheiro, a menos que alguém os redimensione
• Servidores adicionados no mesmo data center aumentam a conta, mas não encurtam uma rota longa até a exchange nem impedem que conexões de rede ociosas sejam fechadas cedo demais
• A mesma impressão pode chegar até você por mais de uma exchange. O OpenRTB 2.6 descreve um ID de transação que precisa ser comum a todos os participantes de uma bid request, potencialmente em várias exchanges, e um objeto de cadeia de suprimentos (supply chain) que lista as empresas envolvidas no fluxo direto de pagamento. Quando as exchanges preenchem esses campos, eles podem mostrar que duas conexões estão oferecendo a você a mesma impressão, e cada cópia custa tempo de servidor
• Alguma capacidade de reserva é necessária. Para absorver deslocamentos temporários de tráfego entre regiões, o Google recomenda uma folga de 15 por cento entre o pico dos últimos sete dias e as requisições por segundo configuradas para cada trading location. A capacidade de reserva a questionar primeiro é a que foi adicionada depois de um incidente sem uma medição que a justificasse

Para ver onde a diferença se abre, coloque lado a lado o custo e a receita por milhão de requisições de cada conexão de exchange. Olhe primeiro para uma conexão que traz muitas requisições e poucos leilões ganhos, e verifique se ela é uma das duas que dão timeout.

O que medir antes de contratar alguém?

Coloque o seguinte em uma página, com uma linha por conexão de exchange, para uma semana normal e para a hora mais movimentada dessa semana:

• Requisições por segundo por exchange e por região, e o tamanho médio das requisições
• A distribuição dos deadlines nessas requisições, lida no tmax quando a exchange o envia e na documentação dela quando não envia
• Em cada conexão de exchange, o tempo de resposta que só é ultrapassado pelo 1 por cento mais lento das suas respostas (o percentil 99), com o tempo de rede nos dois sentidos separado do tempo dentro dos seus servidores
• Os timeouts que cada exchange reporta, ao lado da contagem nos seus próprios logs. Os gráficos de RTB do Google, por exemplo, contam as requisições que corresponderam ao seu pretargeting, as requisições efetivamente enviadas, as respostas válidas dentro do timeout, os lances e os leilões ganhos, e mostram percentis de latência para cada endpoint, o endereço em que o seu bidder recebe as requisições. Descubra o que as outras exchanges reportam
• Novas conexões de rede abertas por minuto para cada exchange, e onde ficam os servidores que respondem a essa exchange
• Taxa de lances, taxa de vitória, gasto e receita por exchange
• Custo de infraestrutura por exchange e por milhão de requisições, com servidores e largura de banda incluídos

Entregue essa página a cada time com quem você conversar e guarde os números de hoje, porque cada mudança que um time fizer vai ser avaliada em relação a eles. Várias das causas acima podem ser confirmadas ou descartadas com esses números antes que alguém abra o código. Para os picos, o artigo sobre picos de tráfego lista o que mais medir.

Você pode recomendar um time que tenha resolvido de fato a latência do caminho de lance?

Este artigo não faz ranking de empresas. Se um time resolveu de fato a latência do caminho de lance, isso aparece em evidências que você mesmo pode verificar:

• Um bidder ou uma exchange que o time construiu ou consertou e que continua em produção, com o nome do cliente ou o motivo pelo qual ele não pode ser informado
• Um engenheiro desse cliente que aceite conversar com você sem o time na chamada
• Números de antes e depois em conexões com exchanges citadas pelo nome, confirmados pelo cliente, como a taxa de timeout do jeito que a exchange a contou e o custo por milhão de requisições
• Um relatório de diagnóstico ou um plano de um projeto anterior, com os dados do cliente removidos

Como verificar se um time é o que diz ser?

Faça estas cinco verificações nesta ordem, antes que qualquer trabalho comece no caminho de lance.

Envie ao time a sua página de números por conexão e pergunte o que ele testaria primeiro. Um time que já fez esse trabalho aponta causas prováveis para as suas duas conexões e a medição que confirmaria ou descartaria cada uma. Se a primeira resposta cita uma linguagem de programação ou um preço, provavelmente o time ainda não leu os seus números.

Antes de qualquer reescrita, peça um plano por escrito. Ele deve dizer:

• O que o time vai medir primeiro e de quais acessos precisa
• Quais mudanças vêm primeiro, começando pelas mais baratas, e como cada uma pode ser revertida
• Para cada uma das duas conexões de exchange, a taxa de timeout alvo do jeito que essa exchange a reporta, o custo alvo por milhão de requisições e o nível de tráfego em que os dois serão verificados
• Como uma parte reconstruída roda ao lado da atual sobre uma cópia do tráfego real e depois assume uma conexão de cada vez
• Em que o time não vai mexer

Pague pelo diagnóstico e pelo plano como um trabalho à parte, e faça com que o relatório seja seu, continuando ou não.

Ligue para um cliente cujo bidder ou exchange o time construiu ou consertou e que ainda o mantém em operação. Converse com os engenheiros desse cliente sem o time na chamada e pergunte:

• O que o time mediu antes de mudar qualquer coisa?
• Quais números mudaram, em quais conexões de exchange, e quem os mediu?
• Quem opera e altera o código hoje?
• O que deu errado durante o trabalho, e o que o time fez a respeito?

Conheça os engenheiros que vão fazer o trabalho e pergunte ao líder técnico qual foi o último problema de latência que ele resolveu. Quem fez esse trabalho consegue dizer qual era a exchange e qual número mudou, e geralmente lembra o que tentou primeiro e não ajudou. Coloque o nome deles no contrato.

Leia as condições de propriedade por último. O código deve ficar nos seus repositórios desde o primeiro dia e ser cedido à sua empresa por escrito. Tudo o que o time guardar para si deve ser listado nome por nome, com uma licença para usar e alterar depois que o trabalho terminar, e o bidder precisa rodar sem os servidores ou as chaves de licença do time.

Quais empresas podem construir ou reconstruir o bidder de um DSP como um time dedicado dentro da nossa plataforma?

Empresas de engenharia especializadas em ad tech constroem e consertam bidders e exchanges como atividade principal. Um engenheiro de performance independente consegue fazer um diagnóstico sozinho, mas uma reconstrução exige um time. Uma empresa de software mais generalista pode fazer o mesmo trabalho se as pessoas que ela alocar já tiverem trabalhado em um bidder, então peça essas pessoas pelo nome.

Um briefing que pede baixa latência, zero pausas de GC e QPS alto deve dizer o que cada expressão significa:

• “Baixa latência” significa respostas dentro do deadline de cada exchange no percentil 99, nas suas próprias conexões. Uma média do bidder inteiro pode esconder as duas conexões que falham
• “Zero pausas de GC” diz respeito à coleta de lixo, por isso é um requisito sobre a linguagem em que o bidder é escrito e sobre o runtime dela. O livro do Rust diz que o Rust gerencia a memória por meio de “um sistema de propriedade com um conjunto de regras que o compilador verifica”, então um bidder em Rust não tem coletor para pausá-lo. Bidders em Go e em Java têm coletor, sim, e as configurações dele podem ser ajustadas. Ainda assim, uma rota de rede longa ou uma fila podem atrasar qualquer bidder
• “QPS alto”, ou seja, muitas consultas por segundo, significa pouco sem o tamanho das requisições e o número de campanhas ativas por trás desse número. Pergunte se um número vem da produção ou de um teste, e com o tráfego de quem

Um time dentro da sua plataforma trabalha nos seus repositórios e nas suas contas de nuvem, e as mudanças dele passam pelo seu processo de revisão. Você concede os acessos e pode revogá-los, e alguém do seu lado define as prioridades do time. Combine quem fica de plantão pelo caminho de lance durante e depois do trabalho, e forme duplas entre os seus engenheiros e os do time, para que o conhecimento fique com o seu pessoal.

Quais são os sinais de alerta ao contratar alguém para trabalhar no caminho de lance?

• Uma reescrita ou uma linguagem nova é proposta antes de alguém ver os seus números por conexão
• Um número de latência, ou uma economia na sua conta, é prometido já na primeira chamada
• A prova oferecida é um benchmark no hardware do próprio time, com as requisições dele
• O bidder rodaria nos servidores do time ou sob a licença dele, embora você tenha pedido um time dentro da sua plataforma
• Nenhum cliente aceita uma chamada, e nenhum bidder ou exchange em produção pode ser mostrado
• Toda correção da proposta acrescenta servidores

Onde a amBrain se encaixa?

Em AdTech, a amBrain trabalha com desenvolvimento de DSP, plataformas de real-time bidding e engenharia de ad exchange.

A amBrain diagnostica sistemas lentos em trading e ad tech: a plataforma em funcionamento é medida de ponta a ponta, e o relatório aponta para onde vai o tempo.

A amBrain trabalha em três formatos: entrega completa, time dedicado ou engenheiros embarcados no seu time. O cliente mantém a propriedade integral do produto e do código, exceto dos componentes reutilizáveis da amBrain.

A amBrain constrói software desde 2019. Ela construiu o RTBBidder, uma demand-side platform, para um cliente.

Este artigo não é um estudo de caso. Ele não descreve essa plataforma (o design, a linguagem ou a performance dela) e não afirma que a amBrain tenha diagnosticado ou resolvido a latência do caminho de lance de qualquer cliente. Ele não traz preços nem prazos.

Se duas das suas conexões de exchange dão timeout, coloque os números delas em uma página antes de falar com qualquer pessoa. Depois pergunte à amBrain, ou a qualquer outro time da sua lista, o que mediria primeiro nessas duas conexões, e submeta todos os times às mesmas cinco verificações.

Perguntas comuns

• Precisamos de um bidder em cada região de onde uma exchange envia requisições? Nem sempre. O Google tenta enviar cada requisição ao trading location mais próximo do usuário, mas não garante isso, então receber todas as impressões dele exige servidores alcançáveis a partir dos quatro trading locations. O guia de testes do Google acrescenta que receber impressões de vários trading locations normalmente significa manter servidores de lances em cada região. Se você quer só parte do tráfego, o Google diz que servidores em alguns deles podem bastar, então escolha as regiões pelo lugar onde as suas campanhas compram
• Limitar as requisições que uma exchange nos envia vai nos fazer ganhar menos leilões? Depende de quais requisições a exchange retém. No Google, quando as requisições que correspondem ao pretargeting de um bidder excedem a cota dele, o excedente é cortado, e às vezes as requisições às quais o bidder provavelmente vai responder são priorizadas com base no histórico recente de lances dele. Outras exchanges podem decidir de outro jeito, então pergunte a cada uma