Práticas recomendadas para aplicativos de RTB

Este guia explica as práticas recomendadas que devem ser consideradas ao desenvolver aplicativos de acordo com o protocolo RTB.

Gerenciar conexões

Mantenha as conexões ativas

Estabelecer uma nova conexão aumenta as latências e exige muito mais recursos em ambas as extremidades do que a reutilização de um existente. Fechando menos é possível reduzir o número de conexões que precisam ser abertas de novo.

Primeiro, toda conexão nova requer uma ida e volta extra de rede para estabelecer. Como estabelecemos conexões sob demanda, a primeira solicitação em um tem um prazo efetivo menor e é mais provável de expirar do que solicitações subsequentes. Qualquer tempo limite adicional aumenta a taxa de erro, o que pode levar para seu proponente sendo restringido.

Segundo, muitos servidores da Web geram um thread de worker dedicado para cada conexão. estabelecidos. Isso significa que, para encerrar 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. É muito de sobrecarga desnecessária.

Evite encerrar conexões

Comece ajustando o comportamento da conexão. A maioria dos padrões de 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. De acordo com do Google, faz sentido reutilizar as conexões quantas vezes for possível. Qa recomendamos que você defina:

• Tempo limite de inatividade de 2,5 minutos.
• Número máximo de solicitações em uma conexão com a maior valor 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 a configuração KeepAliveTimeout a 150, MaxKeepAliveRequests a zero e MaxClients como um valor que depende do tipo de servidor.

Depois que o comportamento da conexão for ajustado, verifique também se o código do bidder não encerra 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 seu proponente recebe sobrecarregada, as conexões começam a fechar e o número de tempos limite aumenta, o que faz com que seu proponente seja limitado.

Mantenha as conexões equilibradas

Se o Authorized Buyers se conectar aos servidores do bidder por um servidor proxy, as conexões podem ficar desequilibradas ao longo do tempo porque, sabendo apenas o endereço IP do servidor proxy, não consegue 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 permanecem ociosos porque, no momento, eles não são necessários. 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 impedir isso O fechamento de todas as conexões após 10.000 solicitações para reequilibrar automaticamente 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, e não uma vez por conexão se 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, Definir 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 estiverem processando consistentemente muitas solicitações em comparação com seus colegas.

Lide com a sobrecarga corretamente

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. Consequentemente, vale a pena considerar como seu proponente se comportará com receber muito tráfego.

Para acomodar mudanças temporárias de tráfego (de até uma semana) entre regiões (especialmente entre Ásia e Oeste dos EUA, Leste e Oeste dos EUA), recomendamos um amortecimento de 15% entre o pico de 7 dias e o QPS por negociação. Localizaçã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 fácil de implementar, esse proponente tem o pior preço quando sobrecarregadas. Ele simplesmente tenta responder a todas as solicitações de lance recebidas, sem seja qual for o caso, enfileirando aqueles que não podem ser atendidos imediatamente. Cenário: que pode ser assim:

• À medida que a taxa de solicitação sobe, as latências de solicitação também aumentam, até que todas tempo limite de início
• As latências aumentam rapidamente à medida que as taxas de chamadas se aproximam do pico
• A limitação é aplicada, reduzindo drasticamente o número de chamadas permitidas
• As latências começam a se recuperar, diminuindo a limitação
• O ciclo começa novamente.

O gráfico de latência desse proponente se parece com uma serra de olho muito íngreme padrão 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 "erro na sobrecarga" bidder

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 com tempos limite internos, desativando enfileiramento de conexões (controlado por ListenBackLog no Apache), a implementação de um modo de queda probabilístico quando a utilização ou as latências ficarem muito alto ou algum outro mecanismo. Se o Google observar uma taxa de erro acima de 15%, começaremos 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 lembra uma serra de olho rasa padrão durante sobrecargas, localizado em torno do máximo e a taxa de conversão.

A abordagem "sem lance na sobrecarga" bidder

Esse proponente aceita chamadas até uma determinada taxa e, em seguida, começa a retornar "sem lance" em caso de 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. A é 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 proponente mostra uma estabilização que (artificialmente) para de ficar paralelamente à taxa de solicitação nos horários de pico, e uma queda correspondente a fração de respostas que contém um lance.

Recomendamos combinar o erro "erro na sobrecarga" com a opção "sem lance na sobrecarga" da seguinte forma:

• 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 na sobrecarga, as máquinas de front-end podem usar uma resposta automática "sem lance" e não precisa analisar a solicitação.
• Implementar verificações de integridade dos back-ends, de modo que, se nenhum tiver capacidade suficiente disponível, eles retornem um "sem lance" resposta.

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. Você pode pensar nisso como "sem lance na sobrecarga" com máquinas front-end retornando 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 faça com que mais erros sejam retornados, reduz os tempos limite e evita que o servidor entre em um estado em que não pode responder a nenhuma solicitação.

Responder a pings

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

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"

Tenha em mente que, ao contrário do que você pode esperar, a solicitação de ping não contém nenhuma dos espaços de anúncios. Além disso, como detalhado acima, você não deve fechar a conexão depois de responder a uma solicitação de ping.

Considerar o peering

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

• Na Internet, os links de transporte público são escolhidos principalmente por meio de "hot-potato roteamento", que encontra o link mais próximo fora de nossa rede que pode obter um e o roteia por esse link. Quando o tráfego passa por uma seção do backbone que pertence ao provedor com quem temos muitas conexões de peering, é provável que o link escolhido esteja próximo ao o pacote é iniciado. Além desse ponto, não podemos controlar 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 inversa começa com um breve salto na rede do Google e permanece o restante do caminho. Manter a maior parte da viagem gerenciada pelo Google a infraestrutura garante que o pacote siga uma rota de baixa latência e evita grande variabilidade potencial.

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 distribui um endereço, ou um subconjunto de endereços, em resposta a uma consulta e depois percorrer essa resposta de alguma forma.
2. O servidor DNS sempre responde com o mesmo conjunto de endereços, mas a ordem dos endereços na resposta.

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

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.