Ir para o conteúdo principal
Capacidade

Sala de espera

Quando a multidão é maior do que a aplicação, a fila pertence à frente dela — ordenada, justa e com um número que o visitante vê mesmo.

O TR7 Waiting Room admite visitantes ao ritmo que a sua aplicação consegue servir e mantém os restantes numa fila ordenada sobre a plataforma de entrega. Dois tetos fazem o trabalho: quantos visitantes podem estar dentro ao mesmo tempo e com que rapidez podem entrar novos. Tudo o resto — a página com a sua marca, a posição, o tempo estimado, a isenção dos motores de busca verificados — existe para que a fila seja algo que se suporta e não algo que se abandona.

Por serviço
Cada serviço publicado tem o seu próprio teto e a sua própria página de espera
0
Linhas de código da aplicação alteradas para colocar uma fila à frente
Observação
Modo que dimensiona a fila antes do evento em vez de durante

Um dia de lançamento não falha devagar. Falha de uma vez.

O planeamento de capacidade assume que o tráfego chega a um ritmo. A abertura das vendas, o lançamento de uma campanha, os resultados de exames e a abertura de marcações não chegam a um ritmo: chegam num instante. A aplicação também não degrada com educação — o pool de ligações enche, a base de dados forma fila, os tempos de resposta sobem e os utilizadores recarregam, duplicando a carga que causou o problema.

As respostas habituais pioram tudo. O autoscaling acrescenta instâncias depois de o pico ter caído e de a base de dados já ser o estrangulamento. A limitação de taxa recusa pedidos — o que, para quem está na fila por um bilhete de concerto, é indistinguível de um site avariado. Ambas deixam a mesma impressão: no momento em que mais queria estar pronto, não estava.

Uma sala de espera muda a forma do problema. A multidão não é recusada nem descartada: é ordenada. A aplicação serve o número que serve bem, os restantes guardam um lugar com posição e estimativa, e a plataforma admite o seguinte assim que um lugar fica livre.

Nossa abordagem

A fila corre na plataforma de entrega, à frente da aplicação, por isso continua de pé quando a aplicação já está no limite — e nenhuma linha de código da aplicação participa em admitir, reter ou libertar seja quem for.

Um teto que a aplicação consegue mesmo servir

Defina o número máximo de visitantes admitidos ao mesmo tempo num serviço publicado. Esse número vem daquilo que a aplicação demonstra aguentar bem, não daquilo que o hardware poderia teoricamente deixar passar.

Um portão sobre o ritmo de chegada, não só sobre o tamanho da multidão

Um teto separado limita quantos visitantes novos podem entrar por minuto. É isto que protege um backend que aguenta uma população grande e estável mas colapsa quando dez mil pessoas chegam no mesmo segundo.

Modo de observação — a capacidade é encontrada antes do evento

Execute a sala de espera em modo de observação e ela conta o que teria acontecido sem reter ninguém. Dimensiona a fila com o seu próprio tráfego, num dia normal, e chega ao evento com um número em que confia em vez de um que adivinhou.

Bots verificados não ocupam lugar na fila

Motores de busca verificados e sondas de monitorização são reconhecidos e isentos: a indexação e as verificações de disponibilidade continuam durante o evento e nenhum lugar é gasto com tráfego que nunca ia comprar nada.

Capacidades

Tudo o que se segue é configurado por serviço publicado, no mesmo ecrã que o resto da política de tráfego, e cada alteração entra em vigor por recarga a quente — inclusive durante o evento.

Máximo de visitantes simultâneos, por serviço publicado

Aplicações diferentes têm limites diferentes e um mesmo equipamento pode correr uma sala de espera distinta para cada uma ao mesmo tempo. O teto é uma propriedade do serviço, não da caixa.

Novos visitantes por minuto — proteção contra picos

O portão de chegada é independente do teto de concorrência. Um pool confortável com 20.000 pessoas lá dentro pode ainda assim ser destruído por 20.000 a chegar de uma vez; é este controlo que separa os dois casos.

Páginas de espera condicionais — só onde importa

A fila aplica-se por condição: os percursos de pagamento e de bilhetes ficam protegidos enquanto o catálogo, a ajuda e a página de estado continuam abertos. O visitante espera pelo que é escasso, não pelo site inteiro.

Posição e tempo estimado, à vista do visitante

Uma fila sem número é indistinguível de uma página bloqueada. A página de espera mostra onde está o visitante e quanto tempo deverá demorar: é essa a diferença entre esperar e sair.

O lugar é mantido — recarregar não o custa

A posição está ligada à sessão do visitante: recarregar, perder a ligação ou passar de dados móveis para Wi-Fi não manda ninguém para o fim. As tempestades de recarga deixam de ser um dano autoinfligido.

A sua própria página de espera

A página é um modelo que você controla — a sua marca, a sua língua, a sua mensagem — servida pela plataforma mesmo quando a aplicação atrás está totalmente ocupada.

Admissão assim que um lugar fica livre

À medida que as sessões terminam, os visitantes seguintes são libertados automaticamente. Ninguém espera por um temporizador que deixou de corresponder à realidade.

Visibilidade ao vivo durante o evento

Profundidade da fila, admissões por minuto, espera média e abandono estão no ecrã enquanto o evento acontece: a decisão de subir ou descer o teto é tomada com evidência.

Profundidade operacional

Uma sala de espera vale o que valer o seu comportamento nos casos incómodos: uma comutação a meio do evento, uma frota de bots na fila, um visitante com ligação instável.

01

A fila está na plataforma, não na aplicação

Sem agente, sem biblioteca, sem alterações de código e sem um serviço de filas para operar. A aplicação nunca fica a saber que existe uma sala de espera; simplesmente nunca vê mais tráfego do que consegue servir.

02

Ordem justa, ligada à sessão

A admissão é por ordem de chegada e a posição acompanha a sessão do visitante em vez de um endereço IP: um NAT empresarial, um CGNAT de operador ou uma linha de escritório partilhada não colocam toda a gente uns atrás dos outros.

03

Combina-se com o resto da proteção

O scoring de bots corre antes da fila, por isso o tráfego automatizado é tratado em vez de ser posto em fila. A limitação de taxa continua a aplicar-se a quem está dentro. A sala de espera gere a multidão honesta; não lhe é pedido que seja um controlo de segurança.

04

Sobrevive a uma comutação

O estado da fila é replicado no cluster: a falha de um nó durante uma abertura de vendas não reinicia a fila. O evento continua no nó sobrevivente com as posições intactas.

05

Comportamento ao recarregar, com novos separadores e dispositivos partilhados

Um segundo separador junta-se ao mesmo lugar em vez de ocupar outro. Há regras explícitas para expiração de sessão e abandono: os lugares deixados por visitantes que saíram voltam para a fila.

06

Liga e desliga durante o evento

Toda a funcionalidade é uma alteração a quente. Pode ser ativada minutos antes da abertura e desativada assim que o pico passa, sem perder uma ligação nem reiniciar nada.

Quando usar

Aberturas de venda e bilheteira

Concertos, jogos e vendas de viagens concentram o tráfego de um ano em noventa segundos. A sala de espera transforma um pico impossível de servir numa fila ordenada e cada visitante mantém um lugar que consegue ver.

Lançamentos de produto e campanhas

Uma campanha que resulta é, na camada de rede, indistinguível de um ataque. A sala de espera deixa o marketing ter sucesso sem pedir à infraestrutura que absorva todo esse sucesso num segundo.

Janelas de candidatura no setor público

Resultados de exames, prazos fiscais e aberturas de marcações são anunciados a toda uma população ao minuto. Uma fila com posição visível é também a resposta mais justa que se pode dar aos cidadãos.

Picos de salário e fim de mês na banca

Picos previsíveis e repetidos não justificam dimensionar a plataforma permanentemente para a pior hora do mês. A sala de espera cobre o pico e a plataforma continua dimensionada para o dia normal.

Perguntas frequentes

Em que difere da limitação de taxa?
A limitação recusa pedidos acima de um limiar; o visitante recebe um erro e não sabe o que fazer. Uma sala de espera aceita toda a gente e ordena-a: ninguém é recusado, a cada um é dito onde está e quanto tempo deverá demorar. Ambas têm o seu lugar e funcionam juntas — a limitação trata do abuso, a sala de espera trata da procura legítima que é simplesmente maior do que a aplicação.
É preciso alterar a aplicação?
Não. A fila corre na plataforma de entrega à frente da aplicação: não há biblioteca para integrar, agente para instalar nem serviço de filas para operar. A aplicação só vê o tráfego já admitido.
Como escolhemos o número certo de concorrência?
Corra primeiro a sala de espera em modo de observação. Ela conta, sobre o seu próprio tráfego, o que teria sido posto em fila sem reter ninguém: assim define o teto com evidência de uma semana normal em vez de um palpite feito sob pressão no próprio dia.
O que acontece se um visitante recarregar ou perder a ligação?
O lugar está ligado à sessão e não ao pedido: recarregar, perder a ligação ou mudar de rede mantém a posição. Isto importa mais do que parece — sem isso, os visitantes preocupados recarregam, a recarga multiplica a carga e a fila começa a causar o problema que veio evitar.
Os motores de busca e a monitorização ficam presos na fila?
Não. Motores verificados e sondas de monitorização são reconhecidos e isentos: a indexação e as verificações de disponibilidade continuam normalmente durante o evento, sem consumir lugar.
O que acontece à fila se um nó do cluster falhar durante o evento?
O estado da fila é replicado no cluster: o nó sobrevivente continua a mesma fila com as posições intactas. Uma comutação a meio de uma abertura de vendas não se torna num segundo incidente.

Esteja pronto para o minuto que decide o trimestre

Teto de concorrência, portão de chegada e uma fila com a sua marca — configurados por serviço e dimensionados em modo de observação antes do evento. Vamos montá-lo sobre o seu próprio tráfego.