Práticas recomendadas para aplicativos de RTB

Este guia explica as práticas recomendadas a serem consideradas ao desenvolver aplicativos de acordo com o protocolo RTB.

Gerenciar conexões

Mantenha as conexões ativas

Estabelecer uma nova conexão aumenta a latência e consome muito mais recursos em ambas as extremidades do que reutilizar uma conexão existente. Ao fechar menos conexões, você pode reduzir o número de conexões que precisam ser abertas novamente.

Primeiro, cada nova conexão exige uma ida e volta de rede extra para ser estabelecida. Como estabelecemos conexões sob demanda, a primeira solicitação em uma conexão tem um prazo de validade mais curto e é mais propensa a expirar do que as solicitações subsequentes. Qualquer tempo limite extra aumenta a taxa de erro, o que pode levar ao limitação do seu bidder.

Segundo, muitos servidores da Web geram uma linha de execução de trabalho dedicada para cada conexão estabelecidos. Isso significa que, para fechar e recriar a conexão, o servidor precisa encerrar e descartar uma linha de execução, alocar uma nova, torná-la executável e criar o estado da conexão antes de processar a solicitação. Isso gera uma sobrecarga desnecessária.

Evite fechar conexões

Comece ajustando o comportamento de conexão. A maioria dos padrões do servidor é personalizada ambientes com um grande número de clientes, cada um gerando um pequeno número solicitações. Para RTB, por outro lado, um pequeno conjunto de máquinas envia solicitações de um grande número de navegadores. Abaixo destes do Google, faz sentido reutilizar as conexões quantas vezes for possível. Qa recomendamos que você defina:

  • Tempo limite de inatividade para 2,5 minutos.
  • Número máximo de solicitações em uma conexão para o valor mais alto possível.
  • Número máximo de conexões com o valor mais alto que sua RAM pode acomodar e, ao mesmo tempo, verificar se o número de conexões não se aproxime muito desse valor.

No Apache, por exemplo, isso implicaria definir KeepAliveTimeout como 150, MaxKeepAliveRequests como zero e MaxClients como um valor que depende do tipo de servidor.

Depois que o comportamento de conexão for ajustado, também será necessário garantir que o código do bidder não feche conexões desnecessariamente. Por exemplo, se você tiver código de front-end que retorna um padrão "sem lance" resposta em caso de solicitações de back-end erros ou tempos limite, verifique se o código retorna sua resposta sem fechar a uma conexão com a Internet. Assim, você evita a situação em que, se o bidder ficar sobrecarregado, as conexões começarão a ser encerradas e o número de tempos limite aumentará, causando a limitação do bidder.

Equilibre as conexões

Se os compradores autorizados se conectarem aos servidores do seu bidder por um servidor proxy, as conexões poderão ficar desequilibradas ao longo do tempo porque, conhecendo apenas o endereço IP do servidor proxy, os compradores autorizados não podem determinar qual servidor do bidder está recebendo cada chamada. Com o tempo, à medida que o Authorized Buyers for estabelecido e fechar e os servidores do bidder são reiniciados, o número de conexões mapeadas para cada uma delas podem se tornar altamente variáveis.

Quando algumas conexões são muito utilizadas, outras conexões abertas podem permanecer inativas porque não são necessárias no momento. Conforme o tráfego do Authorized Buyers muda, as conexões inativas podem ficar ativas e ativas; podem ficar inativas. Isso pode causar uma carga desigual nos servidores do bidder se as conexões estiverem mal agrupadas. O Google tenta evitar isso fechando todas as conexões após 10.000 solicitações, para reequilibrar automaticamente as conexões mais usadas ao longo do tempo. Se o tráfego ainda estiver desequilibrado nas do seu ambiente, há outras etapas que você pode seguir:

  1. Selecione o back-end por solicitação, em vez de uma vez por conexão, se você estiver usando proxies de front-end.
  2. Especifique um número máximo de solicitações por conexão se você for usando um balanceador de carga de hardware ou firewall é corrigido quando as conexões são estabelecidas. Observe que o Google já especifica um limite superior de 10.000 solicitações por conexão, então você só precisará fornecer um valor mais estrito se ainda encontrar em clusters no seu ambiente. No Apache, por exemplo, defina MaxKeepAliveRequests como 5.000.
  3. Configure os servidores do bidder para monitorar as taxas de solicitação e fechar algumas das próprias conexões se ele estiver processando muitas solicitações em comparação com os pares.

Processar sobrecarga de maneira suave

O ideal é que as cotas sejam altas o suficiente para que seu proponente possa receber que ele pode gerenciar, mas não mais do que isso. Na prática, manter as cotas em níveis ideais é uma tarefa difícil, e podem ocorrer sobrecargas por diversos motivos: um back-end que fica inativo durante os horários de pico, uma mistura de tráfego mudando para que é necessário mais processamento para cada solicitação ou um valor de cota está sendo definido muito alto. Por isso, é importante considerar como seu bidder vai se comportar com muito tráfego.

Para acomodar mudanças temporárias no tráfego (até uma semana) entre regiões (especialmente entre a Ásia e o oeste dos EUA e o leste dos EUA), recomendamos uma margem de 15% entre o pico de 7 dias e o QPS por local de negociação.

Em termos de comportamento sob cargas pesadas, os proponentes se enquadram em três categorias categorias:

A opção de “responder a tudo” bidder

Embora seja simples de implementar, esse bidder tem o pior desempenho quando sobrecarregado. Ele simplesmente tenta responder a cada solicitação de lance que chega, não importa o que aconteça, enfileirando qualquer um que não possa ser veiculado imediatamente. Cenário: que pode ser assim:

  • À medida que a taxa de solicitações aumenta, as latências de solicitação também aumentam, até que todas as solicitações comecem a expirar.
  • As latências aumentam rapidamente à medida que as taxas de chamadas de atenção se aproximam do pico.
  • A limitação é aplicada, reduzindo drasticamente o número de chamadas permitidas
  • As latências começam a se recuperar, fazendo com que o estrangulamento seja reduzido.
  • O ciclo começa de novo.

O gráfico de latência desse bidder se assemelha a um padrão de dente de serra muito íngreme. Como alternativa, as solicitações enfileiradas fazem com que o servidor inicie a paginação na memória ou realizar outra ação que cause uma lentidão de longo prazo, e as latências não se recuperam até que os horários de pico tenham passado, levando à queda nas chamadas das taxas durante todo o período de pico. Em ambos os casos, menos chamadas são feitas ou do que se a cota tivesse sido simplesmente definida com um valor mais baixo.

O bidder "error on overload"

Esse proponente aceita chamadas até uma determinada taxa e, em seguida, começa a retornar erros para algumas frases de destaque. Isso pode ser feito por meio de tempos limite internos, desativando a fila de conexões (controlada por ListenBackLog no Apache), implementando um modo de descarte probabilístico quando a utilização ou as latências ficam muito altas ou algum outro mecanismo. Se o Google observar uma taxa de erro acima de 15%, vamos começar a limitar. Ao contrário de “responder a tudo” proponente, este proponente “corta suas perdas”, o que permite uma recuperação imediata quando as taxas de solicitação para baixo.

O gráfico de latência desse bidder se assemelha a um padrão de dente de serra superficial durante sobrecargas, localizado em torno da taxa máxima aceitável.

O bidder "sem lance em sobrecarga"

Esse bidder aceita chamadas até uma determinada taxa e, em seguida, começa a retornar respostas "sem lance" para qualquer sobrecarga. Semelhante a "erro na sobrecarga" proponente isso pode ser implementado de várias maneiras. A diferença aqui é retornado ao Google. Assim, nunca limitamos as chamadas. O é absorvida pelas máquinas de front-end, o que só permite o tráfego que podem ser processadas para acessar os back-ends.

O gráfico de latência desse bidder mostra um platô que (artificialmente) para de paralelizar a taxa de solicitação nos horários de pico e uma queda correspondente na fração de respostas que contêm um lance.

Recomendamos combinar o "erro na sobrecarga" com a abordagem de "sem lance na sobrecarga", da seguinte maneira:

  • Provisione em excesso os front-ends e configure-os para que apresentem erros na sobrecarga, para ajudar a maximizar o número de conexões às quais eles podem responder de alguma forma.
  • Quando ocorre um erro de sobrecarga, as máquinas front-end podem usar uma resposta "sem lance" predefinida e não precisam analisar a solicitação.
  • Implemente a verificação de integridade dos back-ends para que, se nenhum deles tiver capacidade suficiente disponível, eles retornem uma resposta "sem lance".

Isso permite que parte da sobrecarga seja absorvida e dá aos back-ends a chance de responder ao máximo de solicitações que consegue processar. Pense nisso como "sem lance em sobrecarga", com máquinas front-end voltando para "erro em sobrecarga" quando as contagens de solicitações são significativamente maiores do que o esperado.

Se você tem uma opção de “responder a tudo” proponente, considere transformá-los um "erro na sobrecarga" proponente ajustando o comportamento da conexão para que ele funcione e se recusa a ficar sobrecarregado. Embora isso cause mais erros, ele reduz os tempos limite e evita que o servidor entre em um estado em que não possa responder a nenhuma solicitação.

Responder a pings

Garantir que o bidder possa responder a solicitações de ping, sem o gerenciamento de conexão em si, é surpreendentemente importante para a depuração. O Google usa solicitações de ping para verificar a validade e depurar o status do bidder, o comportamento de fechamento da conexão, a latência e muito mais. As solicitações de ping têm o seguinte formato:

Protobuf do OpenRTB

id: "7xd2P2M7K32d7F7Y50p631"

OpenRTB JSON

{
  "id": "4YB27BCXimH5g7wB39nd3t"
}

Google (descontinuado)

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

Ao contrário do que você pode esperar, a solicitação de ping não contém adslots. E, como detalhado acima, não feche a conexão depois de responder a uma solicitação de ping.

Considere o peering

Outra maneira de reduzir a latência ou variabilidade da rede é fazer peering com o Google. O peering ajuda a otimizar o caminho que o tráfego percorre para chegar ao seu bidder. O os endpoints de conexão permanecem os mesmos, mas os links intermediários mudam. Consulte o guia de peering para mais detalhes. O motivo para pensar no peering como uma prática recomendada pode ser resumido assim:

  • Na Internet, os links de trânsito são escolhidos principalmente pelo "roteamento hot-potato", que encontra o link mais próximo fora da nossa rede que pode levar um pacote ao destino e encaminha o pacote por esse link. Quando o tráfego atravessa uma seção de backbone de um provedor com quem temos muitas conexões de peering, é provável que o link escolhido esteja próximo de onde o pacote começa. Além desse ponto, não temos controle sobre a rota em que o pacote segue para o proponente, ou seja, ele pode ser devolvido para outros sistemas autônomos (redes) ao longo do caminho.

  • Por outro lado, quando existe um acordo de peering direto, os pacotes são são sempre enviadas por um link de peering. Não importa a origem do pacote, ele percorre os links de propriedade do Google ou os aluga até chegar ao ponto de peering, que deve estar próximo à localização do proponente. A viagem reversa começa com um salto curto para a rede do Google e permanece na rede do Google pelo resto do caminho. Manter a maior parte da viagem na infraestrutura gerenciada pelo Google garante que o pacote siga uma rota de baixa latência e evita muita variabilidade.

Enviar DNS estático

Recomendamos que os compradores sempre enviem um único resultado de DNS estático ao Google e confiem no Google para lidar com a entrega de tráfego.

Aqui estão duas práticas comuns dos proponentes servidores DNS ao tentar carregar equilibrar ou gerenciar a disponibilidade:

  1. O servidor DNS fornece um endereço ou um subconjunto de endereços em resposta a uma consulta e, em seguida, percorre essa resposta de alguma forma.
  2. O servidor DNS sempre responde com o mesmo conjunto de endereços, mas alterna a ordem dos endereços na resposta.

A primeira técnica é ruim no balanceamento de carga, porque há muito armazenamento em cache em vários níveis da pilha, e as tentativas de ignorar o armazenamento em cache provavelmente não vão gerar os resultados preferidos, já que o Google cobra o tempo de resolução de DNS para o licitante.

A segunda técnica não alcança o balanceamento de carga, já que o Google seleciona aleatoriamente um endereço IP da lista de respostas do DNS para que a ordem a resposta não importa.

Se um proponente fizer uma alteração de DNS, o Google respeitará o time to live(TTL) que foi definidos nos registros DNS, mas o intervalo de atualização permanece incerto.