Na verdade, não conseguimos encontrar nenhum prós para um fora, um dentro. Em resumo, o problema com essa abordagem é que quando os usuários são visitantes de sites de comércio eletrônico, o webserver não sabe quantos usuários simultâneos ele tem em qualquer momento. É um showtopper. Aqui está o porquê.
Mais adiante neste artigo, também lhe dizemos como utilizar uma sala virtual baseada em taxas para proteger seu site também.
Tradicionalmente, os servidores de comércio eletrônico são provisionados para suportar um número máximo de usuários simultâneos, e a carga é muitas vezes definida desta forma. Há um problema com o uso desta abordagem para executar uma fila para um website - um problema que resolvemos com tarifas.
O problema surge porque os visitantes só estão realmente usando o webserver enquanto seu navegador está carregando cada página da web.
Por exemplo, digamos que um site de comércio eletrônico está vendendo ingressos. Desde o início da viagem do visitante até o final da viagem do visitante (a sessão do usuário), há seis páginas como o visitante
Todo o processo de transação leva, em média, cinco minutos.
Digamos, novamente por exemplo, que 100 visitantes chegam para comprar ingressos a cada minuto, e o tempo médio para completar o processo é de cinco minutos. A qualquer momento, há 500 pessoas no processo de transação ao mesmo tempo, e o servidor deve ser provisionado para suportar 500 usuários simultâneos.
Pode-se pensar que se poderia criar um Contador de Usuários Concorrentes que é incrementado cada vez que um novo visitante chega à página inicial, e decretado cada vez que um visitante completa a transação, e que isto lhe diria quantos usuários um único servidor lida a qualquer momento, mas isto não vai funcionar.
Não vai funcionar porque nem todos os visitantes completam a transação. As pessoas mudam de idéia, ou se distraem, ou vão embora e voltam mais tarde. Como o webserver só interage com os visitantes quando seus navegadores estão carregando páginas, o webserver não tem como saber quando isso aconteceu, ou para quem.
Em vez disso, para determinar que um visitante não faz mais parte do processo de transação, o servidor único tem que esperar para ver se não chegam mais pedidos de página daquele visitante e, em seguida, parar a sessão daquele visitante. O tempo de expiração deve ser sempre muito maior do que o tempo médio de transação (digamos 20 minutos neste exemplo), pois alguns visitantes levam muito mais tempo do que outros para completar sua transação.
Poder-se-ia acrescentar a facilidade de diminuir também o número de usuários simultâneos nocionais cada vez que uma sessão de visitantes é realizada desta forma, mas isto dá resultados muito ruins.
Se 10% dos 100 visitantes que chegam a cada minuto não completam sua transação, os que completam estarão ativos por cinco minutos em média e os que não completam serão considerados ativos por pelo menos 20 minutos sempre (na verdade, o tempo limite da sessão mais a duração média da sessão é mais provável quando se considera múltiplas sessões).
Isso é 90 * 5 + 10 * 20 = 650, e o servidor reportará 650 usuários simultâneos, mesmo que na verdade esteja menos ocupado!
Além disso, até 10 * 20 = 200 desses usuários simultâneos não estão realmente usando o site e estão no processo de timing out, que é mais de 30% dos usuários simultâneos relatados, apesar de serem apenas 10% dos visitantes que não completam a transação.
Agora vamos dizer que se deseja adicionar uma fila a este site, controlada por nosso Contador de Usuários Concorrentes. Uma vez que o site esteja na capacidade, então um indivíduo que esteja na frente da fila só será passado para o site uma vez que o contador decida. Isto é chamado de fila de um-a-um-em-linha. O que acontecerá é que 30% do tempo, uma pessoa na frente da fila estará esperando que alguém que não vai completar sua transação não conclua sua transação.
Há também o trabalho adicional de integração técnica e carga no website de criar e operar o balcão, e compartilhar essas informações com o sistema de fila. Se o mecanismo de compartilhamento ou contagem for interrompido ou quebrado, a fila fica presa. Pior ainda, se o servidor único ficar tão ocupado que não possa atualizar o servidor da fila para dizer ao servidor da fila para deixar a próxima pessoa entrar, a fila também fica presa.
Todos estes problemas são fácil e simplesmente resolvidos enviando os visitantes da frente da fila a uma taxa fixa e constante - neste caso, 100 visitantes por minuto.
Dessa forma, não há necessidade de medir o número real de usuários simultâneos, e não há necessidade de integração complexa com o site de venda de bilhetes, e não há risco de que a fila fique presa.
Por isso, em 2004, inventamos e patenteamos a Sala de Espera Virtual baseada em tarifas para sites movimentados.
Produto surpreendente e fácil! O Queue-Fair é realmente lindo. Tão fácil de definir os parâmetros em tempo real, e é tão fácil de integrar também. O suporte é reativo e amigável. Fui configurado com uma Sala de Espera Virtual em 15 minutos, incluindo as configurações! Portanto, protejo minha infra-estrutura contra todos estes picos de tráfego com o Queue-Fair.
Seu software significava que todos ficavam em fila de espera longe de nosso servidor e permitia que um fluxo suave de compradores passasse através do sistema. Foi ótimo! Qualquer loja on-line que tivesse uma adrenalina de clientes acharia isto realmente útil. Obrigado a um milhão e continue com o bom trabalho!
Brilhante! Estamos muito felizes e saciados com Queue-Fair, é maravilhoso ter este nível de apoio. O serviço está funcionando perfeitamente - vendemos milhares de ingressos em pouco tempo, e Queue-Fair nos ajudou a gerenciar o tráfego durante os picos de tráfego! Estamos recomendando o Queue-Fair aos nossos parceiros de serviço também. Estou realmente feliz!
As pessoas da Queue-Fair foram além e acima para nos ajudar a implementar seu sistema de fila de espera em um dia. Com mais de 25.000 pessoas na fila, eles nos ajudaram a administrar o tráfego durante nossos altos picos. O Queue-Fair faz o que deve ser feito; enfileirar as pessoas a um preço competitivo. Estamos satisfeitos com o sistema Queue-Fair e continuaremos usando-o durante eventos futuros.
Queue-Fair era exatamente o que precisávamos para gerenciar o tráfego e o serviço de apoio é ótimo! O sistema tem funcionado muito bem! Procuramos várias empresas e , sem dúvida, encontramos as melhores! Muito obrigado, Queue-Fair!
Um grande obrigado por dar uma resposta tão rápida a nossa pergunta. Enviado por e-mail às 21h de quarta-feira, recebeu uma página de fila de espera com a marca completa, pronta para uso às 11h de quinta-feira. Simplesmente brilhante! O painel e as características são ótimos - realmente intuitivos, realmente limpos e fáceis de usar. Enfileiramos mais de 22.000 pessoas para o evento de lançamento de nossos produtos a um custo extremamente competitivo. Muito obrigado por tudo! Estou realmente feliz em dar um testemunho brilhante ao Queue-Fair e recomendo-os a qualquer empresa que precise de um sistema de fila para seu evento ou promoção.
Se você souber quantos usuários simultâneos um servidor web lida, e o tempo médio de transação ou duração da visita, desde a primeira página em seu fluxo de transações até a página de confirmação do pedido, você pode converter isto em uma Taxa de fila usando a Lei de Little dividindo o número de usuários pela duração, desta forma:
Taxa de fila = Usuários simultâneos / Tempo de transação
Queue-Fair entregará os visitantes ao seu site na taxa que você especificar - temos de longe a Fila AI mais precisa no negócio para garantir que o número de visitantes que você deseja a cada minuto seja o número de visitantes que você recebe a cada minuto, contabilizando automaticamente as pessoas que não estão presentes quando sua vez é chamada, assim como as pessoas que voltam tarde.
Como isso se traduz no número de usuários simultâneos? É claro que nem todo visitante que chega ao seu site levará o tempo médio exato de transação para completar sua transação, mas você terá um número muito constante de Usuários Concorrentes com Queue-Fair, por causa da Lei de Grandes Números.
Por exemplo, digamos que você tenha uma taxa de fila de 100 visitantes por minuto. Enviaremos 100 visitantes ao seu site a cada minuto em um fluxo constante - é isso que fazemos e somos espantosamente bons nisso. Digamos também que as pessoas usam seu site por uma média (média) de cinco minutos, com 70% deles levando entre 4 e 6 minutos desde o momento em que passam pela fila até o momento em que fazem seu último pedido de página (quer completem ou não uma transação). Isso é um desvio padrão de um minuto para cada lado da média. Estatisticamente falando, isso significa que para cada visitante que leva cinco minutos e meio, haverá outro que leva quatro minutos e meio, e estas variações na duração das visitas individuais em várias sessões tendem, portanto, a cancelar um ao outro quando se está contando muitos deles de qualquer forma. A Lei dos Grandes Números diz que este cancelamento se torna cada vez mais exato quanto maior for o número de pessoas envolvidas.
Quão exato, exatamente? Podemos trabalhar isso com um pouco de estatística. Há um tamanho de amostra de 5 * 100 = 500, que é o Grande Número envolvido aqui. É o número de pessoas que você está contando. Isto significa que o erro padrão na média para o tempo de transação é 1 (o desvio padrão, 1 minuto) dividido pela raiz quadrada do tamanho da amostra (portanto, a raiz quadrada de 500) de acordo com a fórmula estatística de erro padrão na média, que dá um erro padrão na média para o tempo de transação de 0,044 minutos, ou apenas 2,7 segundos, o que é menos de um por cento.
Isto significa que com uma taxa de fila de 100, e um tempo de transação de 5 minutos dar ou tirar um minuto para cada visitante individual, você deve esperar entre 495 e 505 usuários simultâneos em seu site em torno de 70% do tempo, então a matemática diz que o uso de uma fila baseada em taxas irá entregar uma carga muito estável em seus servidores web, conforme desejado.
Mas a matemática é precisa? Há algumas sutilezas aqui - por exemplo, o tamanho da amostra que estamos alegremente enraizada nem sempre é exatamente 500 cada vez que os Usuários Concorrentes são contados (ou seja, a qualquer momento), e também uma distribuição normal (gaussiana) pode dar tempos de transação negativos que não ocorrem na vida real. Assim, usamos um simulador visitante por visitante, segundo por segundo, para fazer medições para verificar este tipo de cálculos, e isso nos diz que com os números acima, você deve esperar entre 493 e 507 visitantes 70% do tempo, de modo que a matemática se mantém notavelmente bem! A medição dos dados também nos diz que seu site terá 500 ± 15 usuários simultâneos em pelo menos 95% do tempo.
Isso é provavelmente mais estável do que a precisão com a qual seu servidor web pode medir o número de pessoas que usam seu site! Melhor ainda, o melhor aqui é que mesmo que você não tenha idéia do tempo médio de transação ou do desvio padrão para seus visitantes, estas quantidades matemáticas existem quer você as conheça ou não, e você terá uma carga estável de qualquer maneira.
O resultado final é que o Queue-Fair fornecerá o número de visitantes por minuto que você deseja com precisão praticamente perfeita, resultando em um número muito constante de usuários simultâneos em seu site, e uma carga estável do servidor web sobre a qual você tem controle total.
Viva!
E agora um aviso. Vale notar que a estabilidade do número de usuários simultâneos em seu site - e portanto a estabilidade da carga de seu servidor - depende criticamente da precisão com que seu provedor de Sala de Espera Virtual lhe envia o número de visitantes que você deseja a cada minuto, e este é portanto um fator chave quando você escolhe uma plataforma de Sala de Espera Virtual. Como nós fornecemos a Sala de Espera Virtual mais precisa do mundo, ninguém impede que seus servidores inundem melhor do que o Queue-Fair.
E se você não souber com quantos usuários simultâneos um servidor pode lidar, ou Tempo de Transação? Você pode olhar para a página que provavelmente será seu gargalo - geralmente a que é o resultado de um clique no botão "Buy Now" (Comprar agora). Use o Google Analytics para encontrar os visitantes únicos mensais dessa página, ou conte seus pedidos mensais. Divida isto por 30 * 24 * 60 = 43.200 que é o número de minutos em um mês (aproximadamente). É a média de visitantes por minuto durante o mês inteiro. Multiplique isto por três. Essa é sua média de visitantes por minuto durante o horário comercial (aproximadamente). Dobre isto. Esse é provavelmente um valor seguro para a Taxa de fila a ser usada.
Por exemplo, digamos que você processa 100.000 pedidos por mês - são 100.000 cliques do botão "Comprar agora". Isso é 100.000 / 43.200 = 2,31 pedidos por minuto. Você esperaria que a maioria destes pedidos fosse durante o dia, e que seus servidores fossem mais silenciosos à noite, então multiplique isto por 3 e são 7 pedidos por minuto como uma estimativa aproximada de quão ocupado seu servidor está durante o horário comercial. Se o número resultante for inferior a 50: haverá picos e troughs na demanda, então se seu servidor não estiver visivelmente lento nas horas de pico, multiplique isto por 2 para obter 14 usuários ativos por minuto. Se o número for superior a 50: os picos e troughs minuto a minuto serão menores em comparação, e não é seguro dobrar isto. O número com o qual você termina é provavelmente um número seguro para que a Taxa de fila comece e corresponde a quantas solicitações por segundo você pode gerenciar com segurança; você pode sempre aumentá-lo se achar que seus sistemas ainda respondem pelo desempenho do usuário final a essa taxa.
Se seus pedidos forem carimbados no tempo, você também pode olhar para o máximo de pedidos que recebeu em um único minuto no último mês - mas use com cautela, pois você não saberá quantos pedidos você pode ter perdido durante este minuto devido à lentidão de seus servidores, portanto reduza isto em 20%.
O restante deste artigo discute algumas outras formas de se trabalhar a Taxa de fila.
Vale ressaltar que existem pelo menos duas definições de "Usuários simultâneos" no uso comum.
Usamos a definição, "o número de pessoas envolvidas em um fluxo de transações a qualquer momento". Esse é o número chave que você precisa saber para definir a taxa de fila. É o número de usuários que estão visualizando seu site neste momento. O número de sessões simultâneas é geralmente um pouco maior do que o número de conexões ou usuários simultâneos, porque algumas das sessões estão em processo de extinção, aumentando a duração média da sessão.
Contraste isto com quantas solicitações simultâneas, que é o número de solicitações HTTP sendo processadas por seu servidor web a qualquer momento. Muito confuso, muitas pessoas de tecnologia significarão quantas Solicitações simultâneas quando disserem quantos Usuários simultâneos.
Depois há Conexões simultâneas (ou conexões TCP simultâneas à mesma porta do servidor em sua placa de interface de rede), que é o número de soquetes TCP/IP abertos na porta de seu servidor ou serviço backend a qualquer momento. Ao fazer solicitações de página, os navegadores deixarão, por padrão, a conexão aberta caso qualquer outra solicitação seja feita pela página, ou o usuário vá para uma página diferente. Isto reduz o número de solicitações por segundo para abrir novas conexões TCP/IP, tornando o processo do servidor mais eficiente. Os intervalos de tempo para estas conexões simultâneas variam de acordo com o navegador, de 60 segundos a nunca fechar. Seu servidor também pode fechar automaticamente as conexões após um período de inatividade. Em servidores web Linux você pode obter uma contagem de conexões simultâneas para a mesma porta do servidor com este comando: netstat -aenp | grep ":80 |:443 " | wc -l
que você pode tentar se estiver curioso. Mais uma vez, algumas pessoas também chamam isto de "Usuários Concorrentes", quando realmente significa conexões simultâneas.
De fato, se você pedir a seu provedor de hospedagem para lhe informar o número máximo de usuários simultâneos que seu servidor web lida (quanto tráfego de pico), eles provavelmente lhe darão um número de sessões simultâneas, solicitações simultâneas ou conexões simultâneas, pela simples razão de que eles não sabem seu tempo médio de transação, número de páginas em seu fluxo de transações, ou qualquer outra informação que lhes permita informar quantos usuários simultâneos seu servidor web lida. Todos estes números têm valores diferentes.
Se você estiver solicitando informações ao seu provedor de hospedagem ou equipe técnica sobre os níveis máximos de tráfego, é super importante que você esclareça se eles significam Usuários simultâneos, Sessões simultâneas, Solicitações simultâneas ou Conexões simultâneas.
Eis o porquê. Cada página é uma única solicitação HTTP, mas todas as imagens, scripts e outros arquivos que vêm de sua aplicação web que o navegador usa para exibir a página também são solicitações HTTP.
Imaginemos que sua equipe técnica lhe tenha dito que o servidor suporta 500 Usuários Concorrentes, mas na verdade eles significam 500 Solicitações Concorrentes. Com seu tempo de transação de 5 minutos, você usa a fórmula acima e assume que seu site pode suportar 100 visitantes por minuto.
Pode ser? Não.
À medida que as pessoas passam pelo fluxo da transação, elas estão apenas fazendo solicitações de seus servidores enquanto cada página é carregada. Isto afeta quanto tráfego por segundo ou usuários ativos seu servidor pode lidar. Do tempo de transação de cinco minutos, isso é apenas alguns segundos para um usuário médio. Portanto, você pode pensar que 500 solicitações simultâneas significam que você pode lidar com muito mais usuários simultâneos, mas você pode muito bem estar errado. Você pode ver agora como compreender a capacidade de seu website em termos de quanto tráfego ou número total de usuários ativos é um negócio tão complicado?
Para calcular seu número máximo de usuários simultâneos a partir de seu número máximo total de solicitações simultâneas, você também precisa saber
Você provavelmente já sabe 1) e 2) - em nosso exemplo, são 6 páginas e 5 minutos. Você pode facilmente contar as páginas que vê enquanto faz uma transação. Se você não souber o tempo médio de transação, o Google Analytics pode lhe dizer, ou você pode verificar seus logs do servidor web.
Para 3) e 4), o navegador Firefox pode ajudar. Clique com o botão direito em uma página de seu site, escolha Inspect Element, e a guia Network. Em seguida, pressione CTRL-SHIFT-R para atualizar completamente a página. Você verá os tempos de carregamento da rede para cada elemento da página da lista. Você quer ter certeza de que pode ver os tamanhos de transferência na coluna Transferido, caso contrário, os arquivos poderão ser ser servidos a partir de um cache que pode bagunçar seus cálculos. Você poderá ver alguns scripts e outros recursos vindos de outros servidores que não o seu site, assim você poderá digitar o nome do domínio de seu site na caixa de filtro à esquerda. Para ver a coluna Duração, clique com o botão direito do mouse em qualquer cabeçalho de coluna e selecione Timings -> Duration no menu pop up. Sua tela deve ser parecida com esta:
A aba Rede Firefox para esta página, mostrando Duração e número de Pedidos do queue-fair.com
Os arquivos usados na exibição de suas páginas podem vir de vários sites diferentes, então você também quer usar o filtro na parte superior esquerda para mostrar apenas aqueles de seu site - mas somente se você tiver certeza de que esses arquivos de outros sites não são a razão para o carregamento lento de páginas, ou parte de seu gargalo de gargalo.
Firefox conta as solicitações para você na parte inferior esquerda do visor, e mostra 36 solicitações HTTP para apenas esta página.
Você precisa fazer isso para cada página em seu fluxo de transações - contar o total e dividir pelo número de páginas para encontrar o número médio de solicitações HTTP para cada página, número 3) em nossa lista. Você pode ver agora porque o número de solicitações menores para cada página HTML é um fator tão importante para o tráfego que seu servidor web pode lidar.
Para o número 4), você precisa olhar para a coluna Duração e encontrar a média de todas as solicitações HTTP para todas as suas páginas. Se você não tiver certeza, suponha meio segundo - de qualquer forma, há muita incerteza nisso (veja abaixo).
Vamos dar alguns exemplos de números. Já dissemos que há seis páginas dinâmicas no fluxo do processo do servidor de exemplo, que é 1), e que o tempo médio de transação é de cinco minutos, que é 2). Vamos assumir 36 solicitações HTTP por página para 3), e meio segundo para o tempo de processamento do servidor para cada solicitação HTTP, que é 4).
Com esses números, um servidor que pode lidar com 500 solicitações simultâneas pode lidar com 500 / (0,5 segundos) = 1000 solicitações HTTP por segundo, que é 60.000 solicitações HTTP por minuto, quando está completamente esgotado.
Durante os cinco minutos de tempo de transação, ele pode lidar com 5 * 60.000 = 300.000 solicitações HTTP. Parece muito, certo?
Mas, para cada visitante, há seis páginas com uma média de 36 solicitações HTTP cada uma, ou seja, 6 * 36 = 216 solicitações
Assim, a capacidade de solicitação 300.000 HTTP pode , em teoria, lidar com 300.000 / 216 = 1.389 usuários simultâneos
Ei, isso é ótimo! Pensamos que só poderíamos ter uma taxa de fila de 100, mas 1.389 / 5 minutos = 278 visitantes por minuto, então podemos ter uma taxa de fila mais alta!
Bem, provavelmente não. Para um, seus visitantes não enviarão pedidos em intervalos de exatamente meio segundo, como supõe o cálculo acima. Mais importante ainda, você terá medido seus dados de entrada quando o site não estiver ocupado. O lixo entra, o lixo sai.
Quando o site está ocupado, o servidor leva mais tempo para processar solicitações - você terá notado isso em outros sites quando as coisas estão ocupadas, que você está esperando mais tempo pelas páginas. Isto aumenta o tempo médio que seu servidor leva para processar uma única solicitação HTTP (4), o que diminui a produção máxima. Portanto, pegue os 278 visitantes por minuto e reduza pela metade. Depois, reduza-o pela metade novamente. Você provavelmente está olhando realisticamente para cerca de 70 novos visitantes por minuto com carga máxima.
Outros fatores de confusão incluem o cache, o que significa que os navegadores de seus visitantes podem não precisar fazer cada solicitação para cada página - isto tende a significar que o servidor precisa de menos recursos e pode aumentar o número de novos visitantes por minuto que seu servidor pode lidar. Balanceadores de carga que distribuem carga por vários servidores, e servir conteúdo estático em vez de páginas dinâmicas também podem acelerar seu processo de servidor, já que cada servidor requer menos recursos.
Você também verá que nem todas as páginas levam o mesmo tempo para serem concluídas, pois algumas requerem menos recursos do que outras para produzir e servir. As buscas em bancos de dados, consultas de busca e atualizações são as que demoram mais tempo, então você terá um gargalo em algum lugar de seu processo onde as pessoas se amontoam, esperando que os detalhes do cartão de crédito sejam processados e os pedidos armazenados, ou esperando que a disponibilidade seja verificada. Cada fluxo de transação tem um passo mais lento, portanto sempre há um gargalo em algum lugar, e sempre há uma resposta de valor máximo para a pergunta de quantos usuários simultâneos um servidor web pode lidar - e pode haver vários limites envolvidos. Nesse caso, você quer definir sua taxa de fila suficientemente baixa para garantir que seu servidor tenha capacidade de tempo de processamento simultâneo de pessoas suficientes para a etapa mais lenta de seu processo, para que as pessoas não se amontoem lá em cima. Caso contrário, seu servidor web pode literalmente parar.
Nossa experiência é que, entrando em sua primeira venda, todos superestimam a capacidade de seus servidores para lidar com grandes volumes de tráfego.
A todos.
Identificar com precisão a duração média da sessão e o desempenho do usuário final durante o tráfego lento ou de pico não é para quem tem coração fraco. A melhor coisa a fazer é executar um teste de carga adequado, com clientes "falsos" realmente passando pelo processo de pedido durante o teste de carga exatamente como fariam na vida real, fazendo as mesmas solicitações HTTP na mesma ordem, com as mesmas esperas entre as páginas durante o teste de carga que você vê na vida real, e ficar de olho na carga do processador, na taxa de transferência de IO e nos tempos de resposta à medida que você aumenta o número de visitantes virtuais. Você pode usar o Apache JMeter para isso (também gostamos do K6 para cargas mais leves ou máquinas mais lentas), mas, seja qual for a ferramenta usada, é demorado e complicado imitar o comportamento de cada usuário exatamente da maneira correta (especialmente com as complexidades do armazenamento em cache). Mesmo assim, pegue seu número máximo e reduza-o pela metade.
Na ausência disso, é preciso ter cautela.
Você pode alterar facilmente a taxa de fila de qualquer fila do Queue-Fair a qualquer momento usando o portal do Queue-Fair. Comece com 10 visitantes por minuto ou com a sua taxa de transação em um dia mais normal, veja como isso se comporta por um tempo depois que os ingressos forem colocados à venda e, se tudo parecer bem, se a carga do processador estiver baixa, se o banco de dados sql estiver bom e (acima de tudo) se as páginas estiverem respondendo quando você pressionar CTRL-SHIFT-R, aumente a taxa em no máximo 20%, aguarde um pouco e repita. Você logo encontrará a taxa real de que precisa durante esse "balanceamento de carga" (viu o que fizemos aqui?) e lembre-se de que, do ponto de vista da experiência do cliente, não há problema em aumentar a taxa da fila, pois isso faz com que as esperas estimadas que os clientes na fila estão vendo sejam reduzidas, e todos ficam felizes em ver um tempo de resposta que oferece uma espera estimada menor.
O que você quer evitar é estabelecer a Taxa de fila muito alta e depois estar na posição de ter que baixá-la, pois isto a) significa que as pessoas que utilizam o site experimentam cargas lentas de páginas, e b) faz com que as esperas estimadas aumentem. Todas as pessoas em sua fila suspirarão!
Lembre-se, você terá um gargalo em algum lugar em seu processo de pedido - cada transação tem um passo mais lento - e você terá várias sessões empilhadas lá em cima. O que você não quer fazer é entrar um minuto em sua venda de ingressos, ver que a carga do processador do seu servidor está bem abaixo de seu número máximo e aumentar a tarifa. Seus visitantes provavelmente não chegaram tão longe quanto o botão "Compre agora". Você quer esperar até que seu banco de dados sql esteja relatando novos pedidos com a mesma taxa ou taxa similar à sua Taxa de fila e fazer suas medidas e testes de resposta então. Lembre-se que cada vez que você aumentar a taxa, levará o mesmo tempo para que os visitantes extras cheguem a seu gargalo, de modo que você não será capaz de avaliar com precisão o desempenho de seu servidor à nova taxa até que esse tempo tenha passado.
Já discutimos como é melhor aumentar gradualmente a taxa de fila, uma vez que sua fila tenha sido aberta. Você provavelmente sabe que seus servidores têm um limite que não pode ser excedido sem que o sistema falhe e pode até estar ciente de qual é o limite - mas o que você pode não saber é que como a carga está se aproximando deste limite, geralmente há muito pouco sinal - muitas vezes apenas alguns erros ou avisos, ou uma carga de processador acima de 80%.
Quando os serviços web falham, eles tendem a "estalar" ou se apoderar muito rapidamente. Isto é normalmente porque uma vez que seu sistema não pode mais processar solicitações tão rapidamente quanto elas chegam, as filas internas de processamento se acumulam. Seu sistema então tem que fazer o trabalho de processar, gerenciar e armazenar suas filas internas, bem como as solicitações, e é isso que deixa os servidores à beira do precipício. Muito rapidamente. Uma vez que isso aconteça, seus servidores poderão, por algum tempo, responder com uma página de erro, mas isso não o ajuda, pois os visitantes que o virem irão imediatamente atingir o Refresh, agravando a carga.
Mesmo antes disso, se estiver demorando mais de um segundo para os visitantes verem suas páginas, eles clicam em Atualizar. Quando um visitante pressiona Atualizar, o servidor da Web não sabe que o visitante não está mais aguardando a resposta à solicitação original. Se tanto a solicitação original quanto a de atualização forem recebidas, o servidor da Web processará as duas. Isso significa mais trabalho para o servidor da Web, respostas ainda mais lentas para todos os visitantes e mais pessoas pressionando a atualização, o que resulta em um ciclo vicioso que faz com que o servidor da Web seja interrompido antes mesmo de começar a enviar respostas de erro.
Portanto, não empurre seus servidores com mais força do que precisa. A busca por esses últimos 20% da capacidade de tempo cpu geralmente não vale o risco. Se o tamanho da fila mostrada no Portal Queue-Fair (o número amarelo de espera e a linha nos gráficos) estiver diminuindo ou até mesmo aumentando mais lentamente, minuto a minuto, e o tempo de espera mostrado for de 50 minutos ou menos, então você estará processando os pedidos com rapidez suficiente e a fila acabará esvaziando e parando de mostrar as Páginas de Fila automaticamente, sem que você tenha que fazer nada, e sem que você tenha que dizer ao seu chefe que o pressionou demais e o quebrou. Você chegará lá eventualmente, desde que a velocidade da Frente da Fila seja maior do que o número de Entradas a cada minuto (ambas mostradas no Portal Queue-Fair) - o ponto de virada é normalmente de pelo menos alguns minutos em cada evento. Se você estiver vendendo um produto de quantidade limitada, provavelmente venderá antes que o ponto de virada seja alcançado.
A boa notícia é que se você acidentalmente definir a Queue Rate muito alta e seus servidores estalarem, o Queue-Fair pode ajudá-lo a se levantar e operar rapidamente - basta colocar a fila em espera até que seus servidores estejam prontos para lidar com os visitantes novamente. No modo de espera, as pessoas na fila vêem uma página especial de espera que você pode projetar antes de seu evento on-line. Ninguém é deixado passar pela frente da fila quando ela está em Espera, mas novos visitantes da Internet ainda podem se juntar à fila de trás, para serem enfileirados justamente assim que o bloqueio for liberado, o que acontecerá muito rapidamente porque o Queue-Fair está protegendo seu site contra a demanda. A página Hold é uma experiência superior ao usuário para definir a Queue Rate realmente baixa, especialmente se você atualizá-la para dizer aos visitantes a que horas você espera que a Queue reabra, o que é fácil de fazer com o editor de páginas do Portal, mesmo quando centenas de milhares de pessoas já estão na fila - e no modo Hold você pode até mesmo deixá-las passar uma de cada vez com o botão exclusivo Admit One do Queue-Fair, se você precisar enquanto seu sistema se recupera de seu estalido.
Portanto, se você encontrar que seus servidores precisam fazer uma pausa durante seu evento, a página Hold é exatamente o que você precisa para isso, e ajudará seus servidores a se recuperarem mais rapidamente para inicializar.
Neste artigo, explicamos porque uma fila baseada em taxas é sempre o caminho a seguir, e demos dois métodos para calcular a taxa que você precisa, mas a menos que você tenha feito testes completos e precisos de carga de visitantes virtuais em todo o seu fluxo de transações, e esteja realmente super super certo sobre isso, nosso conselho é sempre o mesmo:
Se você estiver vendendo um produto em quantidade limitada, você também não precisa prestar atenção à etapa 7.
Isso é para sua primeira fila, quando você não sabe a taxa máxima real de fila que seu sistema pode suportar. Para as filas subseqüentes, uma vez que você tenha medido a Taxa de Fila que seu sistema pode realmente suportar, você pode ser capaz de usar o mesmo número novamente - mas somente se nada tiver mudado em seu sistema. Na prática, seu sistema provavelmente está em constante desenvolvimento e modificação, e você pode não saber como as mudanças recentes afetaram sua Taxa de Fila máxima - então por que não começar com a metade de seu número medido anteriormente e repetir o processo acima?
Portanto, é assim que você pode usar o Queue-Fair para tornar sua venda on-line agradável e segura, e lembre-se: é sempre melhor prevenir do que remediar.
2024 The Fair Queue People Ltd. - Todos os direitos reservados.
Parte da família ordenada de soluções de fila - OrderlyQ - OrderlyStats - WeQ4U
