Recentemente, testamos a escalabilidade do NGINX para o balanceamento de carga de conexões WebSocket. Mesmo com 50.000 conexões WebSocket ativas, o NGINX exigiu menos de 1 GB de memória e menos de 1 núcleo de CPU. Quando submetido a conexões com tráfego muito intenso, o uso de memória permaneceu estável e aumentou mais lentamente do que o tamanho das mensagens. O desempenho no seu ambiente dependerá da natureza da sua aplicação, mas os resultados desses testes podem dar uma ideia da quantidade de recursos que você pode esperar que o NGINX utilize.
Ambiente de teste
As seguintes máquinas foram usadas para estes testes:
- Gerador de carga – thor em um Xeon EX5645 de 6 núcleos a 2,40 GHz, 48 GB de RAM
- NGINX – Versão 1.7.0, x86_64 com 6 workers em um Xeon E5645 de 6 núcleos a 2,40 GHz, 48 GB de RAM
- Backend WebSocket – servidor de eco Node.js em um Xeon E5-2660 0 de 4 núcleos a 2,20 GHz, 8 GB de RAM
Testes
Realizamos dois conjuntos de testes.
O primeiro conjunto de testes simulou conexões de longa duração e que permaneciam ociosas na maior parte do tempo. O número de conexões variou de 1.000 a 50.000, o tamanho das mensagens, de 10 a 4.096 bytes, e o intervalo entre as mensagens, de 0,1 a 10 segundos (uma frequência que consideramos baixa).
Os resultados mostram que a memória total necessária para as conexões WebSocket depende do número de conexões e que a memória usada por conexão permanece constante. A utilização da memória não é afetada pelo tamanho nem pela frequência das mensagens. A utilização da CPU acompanha basicamente o número de conexões e, mesmo com 50.000 conexões, não chegou a usar um núcleo completo da CPU. A utilização da CPU apresentada aqui é normalizada para um único núcleo, somando-se a utilização da CPU em todos os núcleos. Os gráficos a seguir mostram os resultados desse conjunto de testes:
O segundo conjunto de testes simulou conexões de curta duração, mas altamente ativas. O número de conexões simultâneas foi mantido constante em 500, com 50 mensagens por conexão e sem intervalo entre as mensagens. O tamanho das mensagens variou de 1 a 4096 bytes.
Os resultados mostram que, com um número fixo de conexões simultâneas, a utilização total da memória depende do tamanho da mensagem, assim como a memória usada por conexão. No entanto, em ambos os casos, a quantidade de memória varia pouco e de forma sublinear, aumentando menos de 15%.
Resumo
Durante esses testes, o NGINX apresentou um desempenho previsível e escalável ao atuar como proxy para servidores WebSocket. Esses testes foram sintéticos e não necessariamente representam uma aplicação real; portanto, os resultados de testes realizados em outros sistemas podem ser diferentes. Para obter mais informações, consulte:
- NGINX como proxy WebSocket
- Proxy de WebSocket (nginx.org)
- Comparação de recursos do NGINX e do NGINX Plus
- Especificações técnicas do NGINX Plus
Sobre o autor
Publicações relacionadas no blog
Como o F5 NGINX One aprimora o gerenciamento e a observabilidade
Descubra como o F5 NGINX One aprimora o gerenciamento e a observabilidade de ambientes híbridos e multicloud ao oferecer um console web centralizado baseado em SaaS, com insights em tempo real, conformidade automatizada e gerenciamento simplificado de configurações.
Do OpenAPI ao NGINX como gateway de API usando uma API declarativa
Descubra como transformar uma definição de esquema OpenAPI em uma configuração NGINX totalmente funcional, operando como um API Gateway com a segurança de um Web Application Firewall e um Portal do Desenvolvedor, usando uma abordagem declarativa de API.
Como gerenciar picos repentinos de tráfego e sobrecarga do servidor
Picos de tráfego e sobrecarga de servidores são preocupações sérias para varejistas online em qualquer época, mas especialmente durante a “Cyber Season” de compras de fim de ano. Detalhamos como você pode aproveitar as soluções de entrega de aplicações de nível de produção da NGINX para se preparar para aumentos repentinos de tráfego.
Distribuição segura de chaves privadas SSL com o NGINX
Descrevemos três maneiras progressivamente mais seguras de proteger chaves privadas SSL ao configurar o NGINX para processar tráfego HTTPS: permitir acesso de leitura apenas ao usuário root, criptografar as chaves com senhas armazenadas separadamente e distribuir as senhas a partir de um repositório central.
Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX
O módulo JavaScript do NGINX lançado com o NGINX Plus R15 oferece suporte a subsolicitações, possibilitando uma classe totalmente nova de casos de uso para o NGINX Plus. Este exemplo completo também usa a API do NGINX Plus e os módulos de chave-valor para converter solicitações de API dos clientes em solicitações separadas para as APIs dos microsserviços que compõem um aplicativo.
Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus
Confira dicas para evitar o esgotamento de portas efêmeras com ajustes no kernel do Linux, conexões keepalive e conexões vinculadas dinamicamente a endereços IP locais.