De quantas ligações de worker de proxy inverso precisam os carregamentos retomáveis?

Não existe um número universalmente seguro de ligações de trabalho para carregamentos retomáveis. Dimensione-o com base na maior procura simultânea de sockets que consiga reproduzir e, em seguida, acrescente uma margem medida.

Num servidor doméstico, um único carregamento visível pode manter uma ligação do cliente, uma ligação ao servidor upstream e períodos de inatividade entre blocos enquanto o navegador tenta novamente ou retoma o carregamento. Comece pelas contagens de ligações ativas durante o período normal de carregamentos mais intenso, compare-as com os limites do proxy e do sistema operativo e pare de aumentar a definição do proxy se os descritores de ficheiros, os trabalhadores upstream, a memória ou a aplicação falharem primeiro.

Meça a procura real de carregamentos antes de escolher um limite

Conte as ligações durante a carga de trabalho relevante, não enquanto o proxy está inativo. Inicie o mesmo número de carregamentos que o seu agregado familiar ou pequena equipa provavelmente fará, pause e retome várias transferências e inclua qualquer cliente móvel que volte a ligar-se depois de sair do modo de suspensão. Registe os sockets de cliente aceites, os sockets upstream estabelecidos e as ligações à espera de uma resposta upstream.

Um limite de trabalhadores é consumido por todas as ligações abertas tratadas por esse trabalhador, e não apenas pelos pedidos HTTP concluídos. Por isso, as ligações de servidor através de proxy têm de ser incluídas na medição juntamente com as ligações dos clientes.

Use o total máximo reproduzível como linha de base de trabalho. Se o total aumentar apenas durante picos de reconexões e baixar rapidamente, mantenha esse pico separado da procura sustentada. Se continuar a aumentar enquanto o débito dos carregamentos permanece estável, não considere esse número crescente uma capacidade legítima; analise a aplicação upstream, os tempos limite e as sessões paradas antes de aumentar qualquer valor.

Converta a procura de sockets em capacidade por trabalhador

Num proxy reverso, um carregamento ativo ocupa normalmente uma ligação do lado do cliente e uma ligação do lado upstream em simultâneo. As ligações HTTP persistentes, as verificações de estado, as sessões WebSocket e o tráfego administrativo consomem espaços adicionais. Considere duas vezes o número de carregamentos simultâneos como um modelo inicial, não como uma resposta final, porque o total de sockets medido é mais fiável do que uma regra geral.

Um limite visível de ligações por trabalhador pode rejeitar novos clientes mesmo enquanto as transferências estabelecidas continuam. Compare o trabalhador mais ocupado com o respetivo limite configurado e, em seguida, verifique o limite de ficheiros abertos do processo do serviço; um valor maior no proxy não pode criar descritores de ficheiros que o processo não tem autorização para abrir.

Escolha um objetivo acima do trabalhador mais ocupado de forma reproduzível, deixando espaço suficiente para o pico de novas tentativas observado e para o tráfego normal que não seja de carregamentos. Não multiplique pelo número de clientes e blocos possíveis se essas ligações nunca existirem em simultâneo. Se o limite do sistema operativo for inferior, alinhe primeiro essa camada ou mantenha o objetivo do proxy abaixo dele.

Teste o percurso de retoma original e interprete a falha

Repita exatamente o acionamento: inicie o conjunto completo de carregamentos, interrompa vários clientes e, em seguida, retome-os enquanto as restantes transferências estão ativas. Observe a aceitação de novas ligações, o momento das novas tentativas, o débito dos carregamentos, o texto dos erros do proxy, o tempo de resposta upstream e os descritores de ficheiros abertos. Um pedido sintético que nunca envia um corpo não testa o mesmo percurso de recursos.

Se o proxy indicar que as ligações dos trabalhadores se esgotaram no mesmo momento em que os novos carregamentos falham, o limite é um estrangulamento comprovado. Se os novos pedidos falharem com erros de tamanho do corpo, tempo limite, upstream indisponível ou fila da aplicação enquanto a utilização de ligações permanece abaixo do limite, uma definição de trabalhadores mais elevada não corrigirá a falha. Um cálculo do limite de ligações continua a ter de respeitar o limite de ficheiros abertos e os sockets dos dois lados do proxy.

Altere uma camada de cada vez. Aumente o limite de trabalhadores apenas depois de os registos e as evidências dos sockets o identificarem como causa, recarregue o proxy e repita o mesmo padrão de interrupção. Se o erro passar para o serviço upstream ou para o limite de descritores de ficheiros, pare; atingiu a restrição seguinte, em vez de provar que são úteis ainda mais ligações no proxy.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Mantenha uma margem suficiente e defina a condição de paragem

Mantenha uma margem entre o trabalhador mais ocupado observado e o limite configurado, mas defina-a com base na variação real. Um servidor pequeno com tráfego doméstico estável precisa de menos reserva especulativa do que um serviço público sujeito a picos imprevisíveis. Registe a linha de base, o objetivo, o número de trabalhadores, o limite de ficheiros do processo e o resultado máximo, para que a alteração seguinte possa ser comparada em vez de ser baseada em suposições.

A capacidade de ligações é apenas uma camada do percurso de carregamento. Quando um painel funciona, mas um percurso específico de sincronização ou carregamento falha, o endpoint e o método que estão a falhar continuam a ter de ser isolados antes de considerar o proxy saudável.

A alteração é bem-sucedida quando dois testes completos de retoma terminam, as novas ligações continuam a ser aceites, os registos de erros permanecem limpos e o trabalhador mais ocupado mantém uma margem estável. Reverta o aumento se a pressão sobre a memória ou a latência piorarem sem reduzir as falhas. Encaminhe a análise para a camada da aplicação ou do armazenamento quando a utilização de ligações estiver confortavelmente abaixo do limite, mas os carregamentos continuarem em fila, a exceder o tempo limite ou a corromper o respetivo estado de retoma.