Maximizando a Escalabilidade do HyperServer
Como já sabemos, qualquer cluster HyperServer consiste em vários Nodes executando simultaneamente no espaço de processo do sistema operacional. Para cada instância HyperServer, o número de Nodes ativos é determinado pela configuração e pelo tráfego atual.
A partir da build 1608 você pode configurar o HyperServer para executar centenas ou até alguns milhares de Nodes. Isso significa que você pode ter centenas de Nodes executando sob uma única instância HyperServer sem enfrentar efeitos adversos no sistema. Algo que não era possível em builds anteriores do HyperServer.
Dito isso, deve-se ter em mente que o número máximo de Nodes (parâmetro max_nodes) deve ser aumentado com cautela. Mais Nodes nem sempre significam melhor desempenho ou melhor escalabilidade. Pelo contrário, Nodes desnecessários podem impor carga indesejada ao sistema e consumir recursos valiosos, como CPU, memória e threads. Portanto, aumente o número de Nodes quando realmente for necessário. O primeiro cenário que vem à mente é uma instância HyperServer que executa múltiplas HyperServer Applications. Por exemplo, se sua instância HyperServer executa 20 tipos de aplicações diferentes e você quer pelo menos 10 Nodes por aplicação, é óbvio que o número de Nodes ativos excederá facilmente 200.
Também é importante saber que aumentar o número de Nodes não tornará automaticamente sua aplicação mais escalável. Para obter benefício do HyperServer, sua aplicação deve ser projetada para lidar com carga aumentada em primeiro lugar. Ou seja, independentemente do número de sessões, sua aplicação e seu back-end de banco de dados também devem ser escaláveis. Por exemplo, se há um gargalo no back-end do banco de dados, sua aplicação também ficará mais lenta e deixará de responder quando a carga atingir determinado nível. Portanto, é muito importante que sua aplicação seja projetada considerando todas as regras de escalabilidade.
Existem alguns passos que, se seguidos, ajudarão a maximizar o número de Nodes concorrentes em seu cluster HyperServer e lidar com os cenários mencionados acima. Esses passos são especialmente importantes quando seu servidor hospeda múltiplas instâncias de HyperServer e cada instância HyperServer gerará muitos Nodes. Existem cenários extremos em que você precisa hospedar múltiplas instâncias de HyperServer no mesmo servidor e cada instância atende múltiplas HyperServer applications. Isso pode levar a uma situação em que centenas (ou até milhares) de HyperServer Nodes coexistam no mesmo servidor. Os passos abaixo ajudarão a garantir que seu cluster não sofra limites impostos pelo SO nesses cenários. É desnecessário dizer que o passo primário é garantir que seu servidor esteja equipado com recursos de hardware suficientes, como núcleos de CPU, memória física e espaço de armazenamento.
Crie suas Node applications como aplicações de console (ou converta seus Nodes existentes para aplicações de console)
No Windows existe um limite imposto pelo SO chamado Desktop Heap. Compilar suas apps como Console Applications garantirá que esse limite nunca seja atingido e que sua instância HyperServer possa gerar centenas (ou até milhares) de Nodes sem atingir o limite do Desktop Heap.
Artigo principal: https://unigui.com/doc/online_help/compiling-nodes-as-console-app.htm
Use Named Pipe transport em vez de HTTP transport (Atualmente disponível para Windows)
Outro limite/recurso imposto pelo sistema é o intervalo dinâmico de portas TCP. Se muitas conexões TCP ativas forem criadas e destruídas em certo período de tempo, há a chance de o sistema enfrentar uma condição chamada "port exhaustion". Esse problema pode ser parcialmente resolvido aumentando o intervalo dinâmico de portas, mas isso não erradicará completamente o problema, pois você ainda pode enfrentar "port exhaustion" sob tráfego intenso.
Existe também outro limite relacionado ao TCP. Números de porta são palavras de 16 bits por design. Isso significa que o número máximo da porta não pode exceder 65535. Então, se você tem muitas instâncias HyperServer no mesmo servidor e cada instância deve atender centenas de Nodes, pode ter dificuldade em encontrar um intervalo de portas exclusivo para atribuir a cada instância. Como os canais de transporte HTTP são implementados sobre TCP, todas as desvantagens acima também se aplicam aos canais de transporte HTTP que o HyperServer usa por padrão.
Named pipes não sofrem desses limites. O número de servidores e clientes de named pipe é limitado apenas pelos recursos do sistema. Portanto, você pode aproveitar melhor a escalabilidade mudando para canais de transporte named pipe, que podem ser configurados no arquivo CFG do HyperServer.
Artigos relacionados:
https://unigui.com/doc/online_help/more-on-transport-channels.htm
https://unigui.com/doc/online_help/additional-network-settings.htm
Use contas Windows personalizadas e pools separados
Se você planeja hospedar múltiplas instâncias HyperServer no mesmo PC, em vez de usar a conta LocalSystem integrada, crie e use contas Windows personalizadas para cada instância. Observe que essas contas devem ser criadas com privilégios administrativos.
Se você estiver usando o IIS como método de implantação, também certifique-se de usar um pool diferente para cada instância HyperServer.
Siga as instruções na seção HyperServer ISAPI Module Mode para configurar corretamente pools e aplicações ISAPI: https://unigui.com/doc/online_help/hyperserver-isapi-module-mode.htm
Se você estiver usando Windows Service como método de implantação, você também pode alterar a conta padrão e usar uma conta Windows personalizada com privilégios administrativos.
(Opcional) Instale a ferramenta de configuração uniGUI HyperServer em todos os servidores do cluster
Esta etapa é opcional. Se sua instância HyperServer não for uma master HyperServer —e— estiver usando named pipe transports —e— todos os seus Nodes forem compilados como aplicações de console, você pode pular esta etapa.
Já discutimos dois diferentes limites impostos pelo SO: Desktop Heap e o intervalo dinâmico de portas (que pode levar à port exhaustion).
Esta ferramenta foi projetada para realizar modificações nas configurações do sistema, portanto ambos os limites serão aumentados até certa magnitude.
Em resumo:
Esta ferramenta aumentará o limite do intervalo dinâmico de portas de 16384 para 32768, o que reduzirá muito a chance de enfrentar a condição chamada "port exhaustion". (Isso se aplica apenas a canais de transporte HTTP.)
Esta ferramenta também aumentará o limite do Desktop Heap de
Nota: Esta ferramenta pode ser baixada a partir do portal do cliente.
Artigos relacionados:
https://unigui.com/doc/online_help/additional-network-settings.htm
https://unigui.com/doc/online_help/hyperserver-system-configurati.htm