Na realidade, não conseguimos encontrar nenhum prós para um fora, um dentro. Em resumo, o problema com essa abordagem é que quando os utilizadores são visitantes de websites, o servidor Web não sabe quantos utilizadores simultâneos tem em qualquer momento. É um showtopper. Eis o porquê.
Mais adiante neste artigo, também lhe dizemos como utilizar uma sala virtual baseada em taxas para proteger também o seu sítio.
Tradicionalmente, os servidores são provisionados para suportar um número máximo de utilizadores simultâneos, e a carga é muitas vezes definida desta forma. Há um problema com a utilização desta abordagem para gerir uma fila de espera para um website - um problema que resolvemos com taxas.
O problema surge porque os visitantes só estão a utilizar efectivamente o webserver enquanto o seu browser está a carregar cada página web.
Por exemplo, digamos que um site está a vender bilhetes. Desde o início da viagem do visitante até ao fim da viagem do visitante (a sessão do utilizador), existem seis páginas como o visitante
Todo o processo de transacção demora, em média, cinco minutos.
Digamos, mais uma vez, por exemplo, que 100 visitantes chegam para comprar bilhetes por minuto, e o tempo médio para completar o processo é de cinco minutos. Em qualquer momento, há 500 pessoas no processo de transacção ao mesmo tempo, e o servidor deve ser provisionado para suportar 500 utilizadores simultâneos.
Poder-se-ia pensar que se poderia criar um Contador de Utilizadores Concorrentes que é incrementado cada vez que um novo visitante chega à página inicial, e decrescido cada vez que um visitante completa a transacção, e que isto lhe diria quantos utilizadores um único servidor lida de cada vez, mas isto não vai funcionar.
Não vai funcionar porque nem todos os visitantes completam a transacção. As pessoas mudam de ideias, ou distraem-se, ou vão-se embora e voltam mais tarde. Porque o webserver só interage com os visitantes quando os seus navegadores estão a carregar páginas, o webserver não tem forma de saber quando isto aconteceu, ou a quem.
Em vez disso, para determinar que um visitante já não faz parte do processo de transacção, o servidor único tem de esperar para ver se não chegam mais pedidos de página desse visitante e, em seguida, parar a sessão desse visitante. Os intervalos de tempo devem ser sempre definidos para muito mais tempo do que o tempo médio de transacção (digamos 20 minutos neste exemplo), pois alguns visitantes demoram muito mais tempo do que outros a completar a sua transacção.
Poder-se-ia acrescentar a facilidade de diminuir também o contador de utilizadores simultâneos nocional de cada vez que uma sessão de visitantes sai desta forma, mas isto dá resultados muito fracos.
Se 10% dos 100 visitantes que chegam a cada minuto não completam a sua transacção, os que completam estarão activos em média durante cinco minutos e os que não completam serão sempre considerados activos durante pelo menos 20 minutos (na verdade, o tempo limite da sessão mais a duração média da sessão é mais provável quando se consideram várias sessões).
São 90 * 5 + 10 * 20 = 650, e o servidor irá reportar 650 utilizadores simultâneos, embora na realidade esteja menos ocupado!
Além disso, até 10 * 20 = 200 desses utilizadores simultâneos não estão de facto a utilizar o site e estão em processo de calendarização, o que representa mais de 30% dos utilizadores simultâneos reportados, embora sejam apenas 10% dos visitantes que não completam a transacção.
Agora digamos que se deseja adicionar uma fila a este website, controlada pelo nosso contador de utilizadores simultâneos. Uma vez que o sítio esteja na capacidade, então um indivíduo que esteja na frente da fila só será passado para o sítio quando o contador decretar. A isto chama-se uma fila de um-a-um-em-linha. O que vai acontecer é que 30% do tempo, uma pessoa na frente da fila estará à espera que alguém que não vai concluir a sua transacção não conclua a sua transacção.
Há também o trabalho adicional de integração técnica e carga no website de criação e funcionamento do balcão, e partilha dessa informação com o sistema de filas de espera. Se o mecanismo de partilha ou de contagem for abaixo ou quebrar, a fila de espera fica presa. Pior ainda, se o servidor único fica tão ocupado que não consegue actualizar o servidor da fila para dizer ao servidor da fila para deixar entrar a próxima pessoa, a fila também fica presa.
Todos estes problemas são fácil e simplesmente resolvidos enviando os visitantes da frente da fila a um ritmo constante e fixo - neste caso 100 visitantes por minuto.
Desta forma, não há necessidade de medir o número real de utilizadores simultâneos, e não há necessidade de integração complexa com o website de bilhética, e não há risco de a fila ficar presa.
Foi por isso que em 2004 inventámos e patenteámos a Sala de Espera Virtual baseada em taxas para sítios Web ocupados.
Se souber quantos utilizadores simultâneos um servidor web trata, e o tempo médio de transacção ou duração da visita, desde a primeira página do seu fluxo de transacções até à página de confirmação da encomenda, pode converter isto numa Taxa de Fila usando a Lei de Little dividindo o número de utilizadores pela duração, desta forma:
Taxa de fila = Utilizadores simultâneos / Tempo de transacção
Queue-Fair entregará visitantes ao seu website à tarifa que especificar - temos de longe a Fila AI mais precisa no negócio para assegurar que o número de visitantes que deseja a cada minuto é o número de visitantes que recebe a cada minuto, contabilizando automaticamente as pessoas que não estão presentes quando a sua vez é chamada, bem como as pessoas que regressam tarde.
Como é que isto se traduz no número de Utilizadores Concorrentes? Claro que nem todos os visitantes que chegam ao seu site levam o tempo médio exacto de transacção para completar a sua transacção, mas obterá um número muito constante de Utilizadores Concorrentes com Queue-Fair, por causa da Lei dos Grandes Números.
Por exemplo, digamos que tem uma taxa de fila de 100 visitantes por minuto. Enviaremos 100 visitantes para o seu site a cada minuto num fluxo constante - é isso que fazemos e somos espantosamente bons nisso. Digamos também que as pessoas utilizam o seu site durante uma média (média) de cinco minutos, sendo que 70% delas demoram entre 4 a 6 minutos desde o momento em que passam pela fila até ao momento em que fazem o seu último pedido de página (quer completem ou não uma transacção). Isto é um desvio padrão de um minuto de cada lado da média. Estatisticamente falando, isso significa que para cada visitante que demora cinco minutos e meio, vai haver outro que demora quatro minutos e meio, e estas variações na duração das visitas individuais ao longo de múltiplas sessões tendem, portanto, a cancelar um ao outro quando se está a contar muitos deles de qualquer forma. A Lei dos Grandes Números diz que este cancelamento se torna cada vez mais exacto quanto maior for o número de pessoas envolvidas.
Quão exacto, exactamente? Podemos trabalhar isso com um pouco de estatísticas. Há um tamanho de amostra de 5 * 100 = 500, que é o Grande Número envolvido aqui. É o número de pessoas que se está a contar. Isto significa que o Erro Padrão na Média para o tempo de transacçã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, o que dá um Erro Padrão na Média para o tempo de transacçã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 transacção de 5 minutos dar ou tirar um minuto por cada visitante individual, deverá esperar entre 495 e 505 utilizadores simultâneos no seu site cerca de 70% do tempo, pelo que a matemática diz que a utilização de uma fila baseada em taxas irá proporcionar uma carga muito estável nos seus servidores web, conforme desejado.
Mas será a matemática exacta? Há aqui algumas subtilezas - por exemplo, o tamanho da amostra que estamos a enraizar alegremente ao quadrado nem sempre é exactamente 500 cada vez que os Utilizadores Concorrentes são contados (ou seja, em qualquer momento), e também uma distribuição normal (gaussiana) pode dar tempos de transacção negativos que não ocorrem na vida real. Assim, utilizamos um simulador visitante por visitante, segundo por segundo, para fazer medições para verificar este tipo de cálculos, e isso diz-nos que com os números acima referidos, deverá esperar entre 493 e 507 visitantes 70% do tempo, por isso a matemática aguenta-se notavelmente bem! A medição dos dados também nos diz que o seu site terá 500 ± 15 utilizadores simultâneos, pelo menos 95% do tempo.
Isso é provavelmente mais estável do que a precisão com que o seu servidor web pode medir o número de pessoas que utilizam o seu site! Melhor ainda, o que aqui está realmente bem é que mesmo que não tenha ideia de qual é o tempo médio de transacção ou desvio padrão para os seus visitantes, estas quantidades matemáticas existem, quer as conheça ou não, e de qualquer forma obterá uma carga estável.
O resultado final é que Queue-Fair irá fornecer o número de visitantes por minuto que deseja com uma precisão praticamente perfeita, resultando num número muito constante de utilizadores simultâneos no seu site, e uma carga estável do servidor web sobre a qual tem controlo total.
Viva!
E agora um aviso. Vale a pena notar que a estabilidade do número de utilizadores simultâneos no seu site - e portanto a estabilidade da carga do seu servidor - depende de forma crítica da precisão com que o seu fornecedor de Sala de Espera Virtual lhe envia o número de visitantes que deseja a cada minuto, e este é portanto um factor chave quando escolhe uma plataforma de Sala de Espera Virtual. Porque fornecemos a Sala de Espera Virtual mais precisa do mundo, ninguém impede os seus servidores de inundar melhor do que Queue-Fair.
E se não souber com quantos utilizadores simultâneos um servidor pode lidar, ou Tempo de Transacção? Pode olhar para a página que provavelmente será o seu gargalo - geralmente a que é o resultado de clicar num botão "Buy Now" (Comprar agora). Use o Google Analytics para encontrar os visitantes únicos mensais dessa página, ou conte as suas encomendas mensais. Divida isto por 30 * 24 * 60 = 43,200 que é o número de minutos num mês (aproximadamente). É a sua média de visitantes por minuto ao longo de todo o mês. Multiplique isto por três. É o seu número médio de visitantes por minuto durante o horário de expediente (aproximadamente). Duplique isto. Este é provavelmente um valor seguro para a Taxa de Fila a utilizar.
Por exemplo, digamos que processa 100.000 encomendas por mês - são 100.000 cliques do botão "Comprar agora". Ou seja 100.000 / 43.200 = 2,31 encomendas por minuto. Seria de esperar que a maioria destas encomendas fosse durante o dia, e que os seus servidores fossem mais silenciosos à noite, por isso multiplique isto por 3 e são 7 encomendas por minuto como uma estimativa aproximada de quão ocupado está o seu servidor durante o horário comercial. Se o número resultante for inferior a 50: haverá picos e troughs na procura, portanto, se o seu servidor não for visivelmente lento nas horas de ponta, multiplique isto por 2 para obter 14 utilizadores activos por minuto. Se o número for superior a 50: os picos e troughs minuto a minuto serão mais pequenos em comparação, e não é seguro duplicar isto. O número com que acaba é provavelmente um número seguro para começar a Taxa de Fila e corresponde ao número de pedidos por segundo que pode gerir com segurança; pode sempre aumentá-lo se verificar que os seus sistemas ainda respondem ao desempenho do utilizador final a essa taxa.
Se as suas encomendas estiverem marcadas a tempo, também pode olhar para as encomendas máximas que recebeu num único minuto no último mês - mas use com cautela, pois não saberá quantas encomendas pode ter deixado cair durante este minuto devido à lentidão dos seus servidores, por isso reduza isto em 20%.
O resto deste artigo discute algumas outras formas de trabalhar a Taxa de Fila de Espera.
Vale a pena salientar que existem pelo menos duas definições de "Utilizadores simultâneos" no uso comum.
Utilizamos a definição, "o número de pessoas envolvidas num fluxo de transacções em qualquer altura". Este é o número chave que precisa de saber para definir a taxa de fila de espera. É o número de utilizadores que estão a visualizar o seu site neste momento. O número de sessões simultâneas é normalmente um pouco maior do que isto, porque algumas das sessões estão em processo de calendarização, aumentando a duração média das sessões.
Contraste isto com quantos pedidos simultâneos, que é o número de pedidos HTTP a serem processados pelo seu servidor web de cada vez. Muito confuso, muitas pessoas de tecnologia significarão quantos Pedidos Concorrentes quando disserem quantos Utilizadores Concorrentes.
Depois há Ligações Concorrentes (ou ligações TCP simultâneas a uma porta de servidor na sua placa de interface de rede), que é o número de Tomadas TCP/IP abertas na porta do seu servidor em qualquer altura. Ao fazer pedidos de página, os navegadores deixarão, por defeito, a ligação aberta no caso de qualquer outro pedido ser feito pela página, ou o utilizador vai para uma página diferente. Isto reduz o número de pedidos por segundo para abrir novas ligações TCP/IP. Os intervalos de tempo para estas ligações variam de acordo com o browser, desde 60 segundos até nunca fechar. O seu servidor também pode fechar automaticamente as ligações após um período de ausência de actividade. Nos servidores web Linux pode obter uma contagem de ligações simultâneas com este comando: netstat -aenp | grep ":80 |:443 " | wc -l
que pode tentar se estiver curioso. Mais uma vez, algumas pessoas também chamam a isto "Utilizadores Concorrentes".
De facto, se pedir ao seu fornecedor de alojamento para lhe dizer o número máximo de utilizadores simultâneos que o seu servidor Web trata (quanto tráfego de pico), eles provavelmente dar-lhe-ão um número de sessões simultâneas, pedidos simultâneos ou ligações simultâneas, pela simples razão de que não conhecem o seu tempo médio de transacção, número de páginas no seu fluxo de transacções, ou qualquer outra informação que lhes permita dizer quantos utilizadores simultâneos o seu servidor Web trata. Todos estes números têm valores diferentes.
Se estiver a pedir ao seu fornecedor de alojamento ou equipa técnica informações sobre os níveis máximos de tráfego, é super importante que esclareça se se trata de utilizadores simultâneos, sessões simultâneas, pedidos simultâneos ou ligações simultâneas.
Eis a razão. Cada página é um único pedido HTTP, mas todas as imagens, scripts e outros ficheiros que vêm da sua aplicação web que o navegador utiliza para exibir a página são também pedidos HTTP.
Imaginemos que a sua equipa técnica lhe tenha dito que o servidor suporta 500 Utilizadores Concorrentes, mas na realidade eles significam 500 Pedidos Concorrentes. Com o seu tempo de transacção de 5 minutos, utiliza a fórmula acima e assume que o seu site pode suportar 100 visitantes por minuto.
Será possível? Não.
À medida que as pessoas atravessam o fluxo de transacções, apenas fazem pedidos dos seus servidores enquanto cada página é carregada. Isto afecta o tráfego por segundo ou utilizadores activos que o seu servidor pode tratar. Do tempo de transacção de cinco minutos, isso é apenas alguns segundos para um utilizador médio. Pode, portanto, pensar que 500 pedidos simultâneos significa que pode tratar de muito mais Utilizadores simultâneos, mas pode muito bem estar errado. Consegue ver agora como compreender a capacidade do seu website em termos de quanto tráfego ou número total de utilizadores activos é um negócio tão complicado?
Para calcular o seu máximo de Utilizadores Concorrentes a partir do seu número máximo total de Pedidos Concorrentes, também precisa de saber
Provavelmente já sabe 1) e 2) - no nosso exemplo são 6 páginas e 5 minutos. Pode facilmente contar as páginas que vê enquanto faz uma transacção. Se não souber o tempo médio de transacção, o Google Analytics pode dizer-lhe, ou pode verificar os registos do seu servidor web.
Para 3) e 4), o navegador Firefox pode ajudar. Clique com o botão direito do rato numa página do seu site, escolha Inspect Element, e o separador Network. Depois carregue em CTRL-SHIFT-R para refrescar completamente a página. Verá os tempos de carregamento da rede para cada elemento da página da lista. Pretende certificar-se de que consegue ver os tamanhos de transferência na coluna Transferred, pois de outra forma os ficheiros poderão ser ser servidos a partir de uma cache que pode estragar os seus cálculos. Poderá ver alguns scripts e outros recursos vindos de outros servidores que não o seu site, pelo que poderá digitar o nome do domínio do seu site na caixa de filtro à esquerda. Para ver a coluna Duração, clique com o botão direito do rato em qualquer cabeçalho de coluna e seleccione Timings -> Duration no menu pop up. O seu ecrã deve ter o seguinte aspecto:
O separador Rede Firefox para esta página, mostrando Duração e número de Pedidos do queue-fair.com
Os ficheiros utilizados na exibição das suas páginas podem ser provenientes de vários sites diferentes, pelo que também quer utilizar o filtro no topo esquerdo para mostrar apenas os do seu site - mas apenas se tiver a certeza de que esses ficheiros de outros sites não são a razão para o carregamento lento de páginas, ou parte do seu congestionamento.
Firefox conta os pedidos para si no canto inferior esquerdo do visor, e mostra 36 pedidos HTTP para apenas esta página.
Tem de fazer isto para cada página do seu fluxo de transacções - contar o total e dividir pelo número de páginas para encontrar o número médio de pedidos HTTP para cada página, número 3) na nossa lista.
Para o número 4), precisa de olhar para a coluna Duração e encontrar a média de todos os pedidos HTTP para todas as suas páginas. Se não tiver a certeza, suponha meio segundo - de qualquer modo, há muita incerteza nisto (ver abaixo).
Vamos dar alguns exemplos de números. Já dissemos que há seis páginas no fluxo do exemplo, que é 1), e que o tempo médio de transacção é de cinco minutos, que é 2). Vamos assumir 36 pedidos HTTP por página para 3), e meio segundo para o tempo de processamento do servidor para cada pedido HTTP, que é 4).
Com esses números, um servidor que pode tratar 500 Pedidos Concorrentes pode tratar 500 / (0,5 segundos) = 1000 pedidos HTTP por segundo, que é 60.000 pedidos HTTP por minuto, quando está completamente esgotado.
Ao longo dos cinco minutos de tempo de transacção, pode tratar 5 * 60.000 = 300.000 pedidos HTTP. Parece muito, certo?
Mas, para cada visitante, há seis páginas com uma média de 36 pedidos HTTP cada, ou seja, 6 * 36 = 216 pedidos
Assim, a capacidade de 300.000 pedidos HTTP pode em teoria tratar 300.000 / 216 = 1.389 utilizadores simultâneos
Ei, isso é óptimo! Pensávamos que só podíamos ter uma taxa de fila de 100, mas 1,389 / 5 minutos = 278 visitantes por minuto, por isso podemos ter uma taxa de fila mais elevada!
Bem, provavelmente não. Para um, os seus visitantes não enviarão pedidos em intervalos de exactamente meio segundo, como supõe o cálculo acima. Mais importante ainda, terá medido os seus dados de entrada quando o site não estiver ocupado. O lixo entra, o lixo sai.
Quando o sítio está ocupado, o servidor leva mais tempo a processar pedidos - terá notado isto noutros sítios quando as coisas estão ocupadas, que está à espera de páginas mais longas. Isto aumenta o tempo médio que o seu servidor leva para processar um único pedido HTTP (4), o que diminui a produção máxima. Assim, pegue nos 278 visitantes por minuto e reduza-o para metade. Depois reduza-o novamente para metade. Provavelmente está a olhar de forma realista para cerca de 70 novos visitantes por minuto com carga máxima.
Outros factores de confusão incluem o cache, o que significa que os browsers dos seus visitantes podem não precisar de fazer cada pedido para cada página - isto tende a aumentar o número de novos visitantes por minuto que o seu servidor pode tratar.
Verá também que nem todas as páginas levam o mesmo tempo a completar. As pesquisas na base de dados, as consultas de pesquisa e as actualizações demoram mais tempo, pelo que terá um estrangulamento algures no seu processo onde as pessoas se acumulam, à espera que os detalhes do cartão de crédito sejam processados e as encomendas armazenadas, ou à espera que a disponibilidade seja verificada. Cada fluxo de transacções tem um passo mais lento, pelo que há sempre um engarrafamento algures. Nesse caso, pretende definir a sua taxa de fila suficientemente baixa para garantir que o seu servidor tem capacidade para processar um número suficiente de pessoas em simultâneo para o passo mais lento do seu processo, para que as pessoas não se amontoem lá em cima. Caso contrário, o seu servidor Web pode literalmente parar.
A nossa experiência é que, entrando na sua primeira venda, todos sobrestimam a capacidade dos seus servidores para lidar com grandes volumes de tráfego.
Toda a gente.
A identificação exacta da duração média da sessão e do desempenho do utilizador final durante o tráfego lento ou de pico não é para os fracos de coração. A melhor coisa a fazer é executar um teste de carga adequado, com clientes "falsos" a passarem pelo processo de encomenda enquanto testam a carga exactamente como fariam na vida real, fazendo os mesmos pedidos HTTP na mesma ordem, com as mesmas esperas entre páginas quando se faz o teste de carga como se vê na vida real, e manter um olho na carga do seu processador, no débito de IO e nos tempos de resposta à medida que aumenta o número de visitantes virtuais. Pode usar o Apache JMeter para isto (também gostamos de K6 para cargas mais leves ou máquinas mais lentas), mas qualquer que seja a ferramenta que utilize, é demorado e complicado imitar o comportamento de cada utilizador exactamente da forma correcta (especialmente com as complexidades do caching). Mesmo assim, pegue nos seus números e reduza-os para metade.
Na ausência disso, erra por precaução.
Pode alterar facilmente a taxa de fila para qualquer fila Queue-Fair em qualquer altura, utilizando o portal Queue-Fair. Comece com 10 visitantes por minuto, ou a sua taxa de transacção num dia mais normal, veja como isso acontece durante algum tempo após a venda dos seus bilhetes, e se tudo parecer bem, a carga do seu processador é baixa, a sua base de dados sql está bem e (acima de tudo) as suas páginas respondem quando atinge CTRL-SHIFT-R, duplique, espere um pouco, e repita. Em breve encontrará a taxa real que necessita durante este 'balanceamento de carga' (ver o que fizemos lá?), e lembre-se, do ponto de vista da experiência do cliente, não há problema em aumentar a Taxa de Fila de espera, uma vez que isto causa as esperas estimadas que os seus clientes na fila estão a ver para reduzir, e todos ficam satisfeitos por ver um tempo de resposta que proporciona uma espera estimada mais curta.
O que se pretende evitar é estabelecer uma taxa de fila demasiado alta e depois estar na posição de ter de a baixar, pois isto a) significa que as pessoas que utilizam o site experimentam cargas de páginas lentas, e b) faz com que as esperas estimadas aumentem. Todas as pessoas na sua fila suspiram!
Lembre-se, terá um estrangulamento algures no seu processo de encomenda - cada transacção tem um passo mais lento - e terá várias sessões a acumular-se ali. O que não quer fazer é entrar um minuto na sua venda de bilhetes, ver que a carga do processador do seu servidor está bem abaixo do seu número máximo, e aumentar a taxa. Os seus visitantes provavelmente não chegaram tão longe como o botão "Comprar agora". Quer esperar até que a sua base de dados sql comunique novas encomendas ao mesmo ritmo ou a um ritmo semelhante ao da sua Taxa de Fila de Espera e fazer então as suas medições e testes de resposta. Lembre-se de que cada vez que aumentar a taxa, levará o mesmo tempo para que os visitantes extra cheguem ao seu gargalo, pelo que não poderá avaliar com precisão o desempenho do seu servidor à nova taxa até que esse tempo tenha decorrido.
Já discutimos como é melhor aumentar gradualmente a Taxa de Fila de Espera assim que a sua fila for aberta. Provavelmente sabe que os seus servidores têm um limite que não pode ser ultrapassado sem que o sistema falhe e pode até estar ciente de qual é o limite - mas o que pode não saber é que à medida que a carga se aproxima deste limite, há normalmente muito pouco sinal - muitas vezes apenas alguns erros ou avisos, ou uma carga de processador acima de 80%.
Quando os serviços web falham, tendem a "estalar" ou a apreender muito rapidamente. Isto é normalmente porque uma vez que o seu sistema já não consegue processar pedidos tão rapidamente como eles chegam, as filas internas de processamento acumulam-se. O seu sistema tem então de fazer o trabalho de processamento, gestão e armazenamento das suas filas internas, bem como dos pedidos, e é isso que faz com que os servidores se desviem dos limites. Muito rapidamente. Uma vez que isso aconteça, os seus servidores poderão durante algum tempo responder com uma página de erro, mas isto não o ajuda porque os visitantes que o vejam irão imediatamente carregar em Refresh, agravando a carga.
Portanto, não empurre os seus servidores com mais força do que a necessária. Ir para esses últimos 20% da capacidade não vale normalmente o risco. Se o tamanho da fila mostrada no Portal Queue-Fair (a figura e linha de espera amarela nos gráficos) estiver a diminuir ou mesmo a aumentar mais lentamente, minuto a minuto, e o tempo de espera mostrado for de 50 minutos ou menos, então está a processar as encomendas com rapidez suficiente e a fila acabará por esvaziar e deixar de mostrar as Páginas de Fila automaticamente, sem ter de fazer nada, e sem ter de dizer ao seu chefe que o pressionou demasiado e o partiu. Acabará por chegar lá, desde que a velocidade da Frente da Fila seja superior ao número de Entradas em cada minuto (ambas mostradas no Portal Queue-Fair) - o ponto de viragem é normalmente de pelo menos alguns minutos em cada evento. Se estiver a vender um produto de quantidade limitada, provavelmente esgotará antes de se atingir o ponto de viragem.
A boa notícia é que se acidentalmente definir a Queue Rate demasiado alta e os seus servidores estalarem, Queue-Fair pode ajudá-lo a levantar-se e a funcionar rapidamente - basta colocar a fila em espera até que os seus servidores estejam novamente prontos para lidar com os visitantes. No modo de espera, as pessoas na fila vêem uma página especial de espera que pode desenhar antes do seu evento online. Ninguém é deixado passar pela frente da fila quando esta está em espera, mas novos visitantes podem ainda juntar-se à fila na parte de trás, para serem enfileirados de forma justa uma vez que o bloqueio seja eliminado, o que acontecerá muito rapidamente porque Queue-Fair está a proteger o seu site da procura. A Página em Espera é uma experiência de utilizador superior à definição da Taxa de Fila de Espera realmente baixa, especialmente se a actualizar para dizer aos visitantes a que horas espera que a Fila 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 de Espera pode mesmo deixá-las passar uma de cada vez com o botão único de Admissão Um do Queue-Fair, se precisar, enquanto o seu sistema recupera do seu estalido.
Assim, se achar que os seus servidores precisam de fazer uma pausa durante o seu evento, a página Hold é exactamente o que precisa para isso, e ajudará os seus servidores a recuperarem mais rapidamente para arrancar.
Neste artigo explicamos porque é que uma fila baseada em taxas é sempre o caminho a seguir, e dados dois métodos para calcular a taxa de que necessita, mas a menos que tenha feito testes completos e precisos de carga de visitantes virtuais em todo o seu fluxo de transacções, e que esteja realmente super super extra mega certo sobre isso, o nosso conselho é sempre o mesmo:
Se estiver a vender um produto em quantidade limitada, também não precisa de prestar atenção à etapa 7.
Isto é para a sua primeira fila, quando não sabe a taxa de fila máxima que o seu sistema pode suportar. Para as filas subsequentes, uma vez medida a Taxa de Fila de espera que o seu sistema pode realmente suportar, poderá ser capaz de utilizar novamente o mesmo número - mas apenas se nada tiver mudado no seu sistema. Na prática, o seu sistema está provavelmente em constante desenvolvimento e modificação, e poderá não saber como as mudanças recentes afectaram a sua Taxa de Fila máxima - então porque não começar com metade do seu valor medido anteriormente e repetir o processo acima?
Lembre-se, é sempre melhor estar seguro do que arrependido.
