Como utilizar a nossa fila online evita que um sítio e um sítio web falhem - quantos utilizadores simultâneos podem um servidor web gerir?

Porquê utilizar uma Sala de Espera Virtual baseada em taxas?

Com base na taxa ou um fora, um dentro? Pesamos os prós e os contras.

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 de comércio electrónico, o servidor Web não sabe quantos utilizadores simultâneos tem em qualquer momento. É um showtopper. Eis a razão.

Mais adiante neste artigo, também lhe dizemos como utilizar uma sala virtual baseada em taxas para proteger também o seu sítio.



A Sala de Espera Virtual mais bem avaliada do G2
G2 é o site de revisão SaaS mais visitado do mundo

O que dizem os nossos Clientes sobre Queue-Fair


teste de carga o http solicita quantos pedidos um servidor web tem sem recursos adicionais de servidor

Quantos utilizadores simultâneos pode um servidor web tratar?

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

Qual é a precisão de um sistema de filas de espera baseado em taxas?

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.

número máximo de recursos do sistema operativo do servidor web
cálculo do valor médio para utilizadores simultâneos com intervalo de confiança

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!


servers capacity can be exceeced with inaccurate queues 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.

Uma maneira fácil de calcular a taxa de fila

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.

calcular os níveis máximos de utilizadores activos para a sua aplicação web

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.

confusão sobre conexões simultâneas de utilizadores simultâneos sessões simultâneas e duração média das sessões

Erro #1: Utilizadores simultâneos vs Pedidos simultâneos vs Ligações simultâneas vs Sessões simultâneas

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 momento". 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 o número de ligações ou utilizadores simultâneos, porque algumas das sessões estão em processo de calendarização, aumentando a duração média da sessão.

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 simultâneas (ou ligações TCP simultâneas à mesma porta de servidor na sua placa de interface de rede), que é o número de Tomadas TCP/IP abertas na porta do seu servidor ou serviço backend 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, tornando o processo do servidor mais eficiente. Os intervalos de tempo para estas ligações simultâneas variam de acordo com o browser, de 60 segundos a nunca fechar. O seu servidor pode também 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 para a mesma porta do servidor 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", quando realmente significa conexões simultâneas.

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.

Se se enganar, pode estragar o seu sítio web!

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?

segurança primeiro para os recursos do seu servidor ao calcular quantos pedidos as suas páginas web podem obter para uma boa experiência para cada utilizador

Conversão de pedidos simultâneos para utilizadores simultâneos

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

  1. O número de páginas no seu fluxo de transacções
  2. O tempo médio de transacção do visitante desde a primeira página até à última página do seu fluxo
  3. Quantos pedidos compõem cada página, em média
  4. O tempo médio que o seu servidor leva para processar um único pedido HTTP

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:

google processa um nginx devidamente configurado com google analytics para carregamento de imagens

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. Pode ver agora porque é que o número de pedidos infantis para cada página HTML é um factor tão importante para o tráfego que o seu servidor web pode tratar.

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).

fazer as contas para calcular quantas sessões ao mesmo tempo, quantos utilizadores e quantos pedidos por segundo na sua aplicação web seja um único servidor ou conteúdo estático

Fazendo as contas

Vamos dar alguns exemplos de números. Já dissemos que existem seis páginas dinâmicas no fluxo do processo do servidor de 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

Erro #2: Servidores Web ficam mais lentos com a carga

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.

quanto mais pesada a carga do seu tráfego aumenta, mais lentas as máquinas se tornam

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 significar que o servidor precisa de menos recursos e pode aumentar o número de novos visitantes por minuto que o seu servidor pode tratar. 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 pode acelerar o processo do seu servidor, uma vez que cada servidor requer menos recursos.

Verá também que nem todas as páginas levam o mesmo tempo a completar, uma vez que algumas requerem menos recursos do que outras para produzir e servir. As pesquisas na base de dados, consultas de pesquisa e actualizações demoram mais tempo, pelo que terá um gargalo 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 estrangulamento algures, e há sempre uma resposta de valor máximo à pergunta de quantos utilizadores simultâneos pode um servidor web tratar - e pode haver vários limites envolvidos. Nesse caso, pretende definir a sua Taxa de Fila de espera suficientemente baixa para garantir que o seu servidor tem capacidade de 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.

incerteza sobre como estimar os recursos do servidor de capacidade dos servidores para cada utilizador

Então o que é que eu faço?

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 no seu número máximo e reduza-o 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!

Erro #3: Aumentar a taxa demasiado depressa após a abertura de uma fila

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.

retardar a decisão de consumir recursos do servidor
os servidores se agarram quando a capacidade dos servidores é excedida

Erro #4: A partir dos seus servidores

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. Atingir os últimos 20% da capacidade de tempo cpu 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 prontos para lidar novamente 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 da Internet ainda podem 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 Hold é 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 de 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.

Conclusão

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:

  1. Comece com uma taxa de fila definida para 10, ou com a sua taxa de transacção num dia mais normal.
  2. Observe a carga do seu processador e outros indicadores de desempenho.
  3. Aguarde até que novas encomendas estejam a ser registadas na sua base de dados sql ao mesmo ritmo ou a um ritmo semelhante ao da sua Taxa de Fila de Espera.
  4. Carregue em CTRL-SHIFT-R nas suas páginas para verificar a capacidade de resposta.
  5. Aumentar a taxa de fila de espera em não mais de 20%.
  6. Voltar ao passo 2, e esperar novamente.
  7. Uma vez que o tamanho da fila está a diminuir ou está a aumentar de forma menos rápida a cada minuto, e o tempo de espera mostrado é inferior a 50 minutos, não precisa de ir mais depressa.
  8. Sente-se e relaxe! O Queue-Fair tem-no coberto.

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.


Centenas de organizações líderes confiam nas nossas
soluções de fila

Customer 1 Customer 2 Customer 3 Customer 4 Customer 5 Customer 6

A solução simples para os seus picos de tráfego na Internet

Comece a trabalhar