No contexto de proxy, o throughput mede o volume total de dados processados e transmitidos com sucesso pelo servidor proxy dentro de um determinado período. Ele quantifica a quantidade de dados que um proxy consegue manipular, refletindo sua capacidade de repassar requisições dos clientes e respostas dos servidores de origem de forma eficiente.
Entendendo o throughput de proxy
O throughput é uma métrica de desempenho crítica para qualquer serviço de proxy e impacta diretamente a experiência do usuário e a eficiência operacional da transferência de dados. Normalmente é medido em bits por segundo (bps), kilobits por segundo (Kbps), megabits por segundo (Mbps) ou gigabits por segundo (Gbps) para volume de dados. Para métricas orientadas a conexão, também pode ser expresso em requisições por segundo (RPS) ou conexões por segundo (CPS), que indicam a capacidade do proxy de lidar com operações simultâneas.
A capacidade de throughput de um proxy determina quantos clientes ele consegue atender simultaneamente e com que rapidez consegue mover dados entre clientes e servidores de origem. Throughput alto é essencial para aplicações que exigem transferência rápida de dados, como streaming de vídeo, download de arquivos grandes ou requisições de API em alto volume. Throughput baixo se manifesta como tempos de carregamento lentos, respostas atrasadas e degradação geral do serviço.
Fatores que influenciam o throughput de proxy
Vários fatores interdependentes determinam o throughput efetivo de um servidor proxy:
Infraestrutura de rede
A banda de rede subjacente é um determinante primário. Isso inclui a velocidade da conexão de internet do próprio servidor proxy (tanto upstream quanto downstream), os enlaces de rede até os servidores de origem e os caminhos de rede até os clientes. Um servidor proxy com uma interface de rede de 1 Gbps não consegue atingir mais de 1 Gbps de throughput, independentemente do seu poder de processamento. Congestionamento em qualquer ponto do caminho de rede pode reduzir o throughput efetivo.
Hardware do servidor proxy
Os recursos físicos do servidor proxy impactam diretamente sua capacidade de processamento:
* CPU: o poder de processamento é crucial para tarefas como criptografia/descriptografia SSL/TLS, parsing de requisições, manipulação de cabeçalhos, filtragem de conteúdo e gerenciamento de inúmeras conexões simultâneas. Gargalos de CPU ficam evidentes com altos volumes de tráfego SSL/TLS ou processamento complexo de conteúdo.
* RAM: memória suficiente é necessária para cachear conteúdo acessado com frequência, manter estados de conexão e sustentar processos worker. RAM insuficiente pode levar a I/O de disco excessivo (swapping) ou a taxas de acerto de cache reduzidas, e ambos degradam o desempenho.
* I/O de disco: para proxies com cache, a velocidade das operações de leitura/escrita em disco é vital. SSDs superam significativamente os HDDs nesse quesito, especialmente sob padrões de acesso altamente concorrentes. Logging persistente também consome I/O de disco.
* Placas de rede (NICs): a capacidade e a qualidade das NICs determinam a taxa máxima de dados que o servidor consegue processar. Múltiplas NICs podem ser usadas para redundância ou para agregar banda.
Configuração do software de proxy
A forma como o software de proxy é configurado afeta profundamente seu throughput:
* Configurações de concorrência: parâmetros como número máximo de processos/threads worker, número máximo de descritores de arquivo abertos e número máximo de conexões simultâneas limitam diretamente a capacidade do proxy de lidar com requisições paralelas.
* Políticas de cache: um cache eficaz reduz a carga sobre os servidores de origem e a rede, aumentando o throughput percebido ao servir conteúdo diretamente do proxy. Tamanho do cache, políticas de expulsão e configurações de time-to-live (TTL) são críticos.
* Offloading de SSL/TLS: handshakes SSL/TLS e criptografia/descriptografia consomem muita CPU. Transferir isso para hardware dedicado (aceleradores SSL) ou servidores separados libera a CPU principal do proxy para outras tarefas.
* Níveis de log: logging verboso consome CPU, I/O de disco e memória, o que pode reduzir o throughput.
* Filtragem e conjuntos de regras: regras de filtragem complexas ou extensas (por exemplo, regras de WAF, inspeção de conteúdo) exigem mais processamento por requisição, aumentando a latência e reduzindo o throughput geral.
* Suporte a protocolos: o tratamento eficiente de protocolos modernos como HTTP/2 ou HTTP/3 pode melhorar o throughput ao reduzir overhead e permitir multiplexação.
Desempenho upstream e downstream
O desempenho dos servidores de origem (upstream) e dos dispositivos/redes dos clientes (downstream) também afeta o throughput efetivo do proxy. Um proxy rápido não compensa um servidor de origem lento ou um cliente com banda limitada.
Características do tráfego
A natureza do próprio tráfego tem seu papel:
* Tamanho da requisição: muitas requisições pequenas (por exemplo, para inúmeros ativos pequenos) podem sobrecarregar mais a CPU devido ao estabelecimento/encerramento de conexões e ao processamento de cabeçalhos, enquanto poucas requisições grandes tendem a sobrecarregar a banda de rede.
* Persistência de conexão: usar HTTP keep-alive ou conexões persistentes (multiplexação HTTP/2) reduz o overhead de estabelecer novas conexões TCP a cada requisição, melhorando a eficiência.
* Overhead de protocolo: protocolos diferentes têm overheads distintos. Por exemplo, o HTTP/1.1 frequentemente exige múltiplas conexões, enquanto o HTTP/2 usa uma única conexão para múltiplos streams.
Medindo o throughput de proxy
A medição precisa do throughput de proxy envolve o monitoramento de várias métricas de sistema e de aplicação.
Monitoramento no nível do sistema
Ferramentas como top, htop, vmstat e iostat oferecem uma visão da utilização de CPU, memória e I/O de disco. Ferramentas de monitoramento de rede como iftop, nload ou vnstat acompanham o uso de banda da interface de rede.
# Monitorar CPU, memória e load average
top -bn1 | head -n 5
# Monitorar uso de banda de rede em uma interface específica (ex.: eth0)
iftop -i eth0
# Monitorar atividade de I/O de disco
iostat -xdm 1 5
Métricas no nível da aplicação
Os serviços de proxy costumam expor métricas específicas:
* Bytes de entrada/saída por segundo: medição direta da taxa de transferência de dados através do proxy.
* Requisições por segundo (RPS): indica a taxa com que o proxy processa as requisições dos clientes.
* Conexões ativas: número de conexões abertas que o proxy está gerenciando no momento.
* Taxa de acerto do cache: percentual de requisições atendidas a partir do cache, indicando a eficiência do cache.
* Taxas de erro: taxas de erro elevadas podem indicar um proxy sobrecarregado ou mal configurado, afetando o throughput efetivo.
Muitos servidores proxy oferecem páginas de status ou endpoints de API para essas métricas. Por exemplo, o módulo stub_status do NGINX ou a página de estatísticas do HAProxy fornecem dados de desempenho em tempo real.
Teste de carga
Para determinar o throughput máximo sustentado, ferramentas de teste de carga são indispensáveis. Ferramentas como Apache JMeter, k6, Locust ou wrk conseguem simular altos volumes de usuários e requisições simultâneas, medindo o desempenho do proxy sob estresse.
# Exemplo de uso do wrk para testar um proxy
wrk -t12 -c400 -d30s --latency http://your-proxy-ip:port/test-path
Esse comando executa 12 threads, mantém 400 conexões abertas e testa por 30 segundos, reportando estatísticas de latência.
Otimizando o throughput de proxy
Otimizar o throughput de proxy envolve uma combinação de upgrades de hardware, ajuste de software e considerações arquiteturais.
Escalonamento de hardware
- Upgrade de CPU: use CPUs com clocks mais altos e mais núcleos, especialmente para cargas pesadas em SSL/TLS.
- Expansão de memória: aumente a RAM para suportar caches maiores e mais conexões simultâneas.
- Armazenamento mais rápido: implante SSDs ou drives NVMe para cache e logging.
- Upgrades de rede: utilize NICs de maior banda (por exemplo, 10 Gbps, 25 Gbps, 40 Gbps) e garanta que a infraestrutura de rede suporte essas velocidades.
Configuração e tuning do software
- Tuning de parâmetros do kernel: ajuste os tamanhos de buffer TCP (
net.ipv4.tcp_rmem,net.ipv4.tcp_wmem), aumente os limites de descritores de arquivo (fs.file-max,ulimit -n) e otimize outros parâmetros de kernel relacionados à rede. - Tuning específico do proxy:
- Aumente os processos/threads worker para aproveitar os núcleos de CPU disponíveis.
- Otimize o cache: garanta tamanho de cache suficiente, cabeçalhos
max-ageapropriados e políticas de expulsão eficientes. - Habilite HTTP/2 ou HTTP/3 para multiplexação e menor overhead.
- Configure connection pooling para reutilizar conexões existentes com os servidores de origem.
- Minimize logging verboso em ambientes de produção.
- Simplifique listas de controle de acesso (ACLs) e regras de filtragem para reduzir o overhead de processamento.
- Otimização de SSL/TLS:
- Use suítes de cifras eficientes.
- Habilite cache de sessão SSL e session tickets TLS para reduzir o overhead de handshake.
- Considere servidores dedicados de terminação SSL/TLS ou offloaders de hardware.
Considerações arquiteturais
- Balanceamento de carga: distribua o tráfego de entrada entre múltiplas instâncias de proxy usando um balanceador de carga (por exemplo, DNS round-robin, balanceadores L4/L7). Isso escala o throughput horizontalmente.
- Distribuição geográfica: implante proxies em múltiplas localizações geográficas (edge proxies) mais próximos dos clientes e/ou dos servidores de origem para reduzir a latência e melhorar o throughput percebido.
- Redes de distribuição de conteúdo (CDNs): integre com CDNs para descarregar a entrega de conteúdo estático, reservando os recursos do proxy para tráfego dinâmico ou crítico.
Throughput vs. latência vs. banda
Embora relacionados, throughput, latência e banda são conceitos distintos:
| Característica | Throughput | Latência | Banda |
|---|---|---|---|
| Definição | Volume real de dados transferido por unidade de tempo. | Atraso para uma única unidade de dados trafegar. | Capacidade máxima de transferência de um caminho. |
| Unidades | bps, Kbps, Mbps, Gbps, RPS, CPS | Milissegundos (ms) | bps, Kbps, Mbps, Gbps |
| Impacto | Velocidade geral de transferência, capacidade de volume. | Responsividade, interação em tempo real. | Taxa máxima potencial de dados. |
| Analogia | Quanta água passa pelo cano por hora. | Quanto tempo uma única gota leva para sair. | A largura do cano. |
Uma conexão de alta banda oferece o potencial para throughput alto. No entanto, o throughput pode ser limitado por fatores como poder de processamento do servidor, congestionamento de rede ou overhead de protocolo, mesmo com banda alta. A latência, o atraso de tempo, afeta a rapidez com que requisições individuais são processadas; latência alta pode reduzir indiretamente o throughput efetivo ao atrasar o início das transferências de dados ou das confirmações. Um proxy bem dimensionado busca maximizar o throughput minimizando a latência.
Impacto das versões do protocolo HTTP
A evolução dos protocolos HTTP impactou significativamente a forma como os proxies lidam com throughput:
HTTP/1.1
- Modelo de conexão: normalmente uma conexão TCP por requisição, ou reutilização via
Keep-Alive. - Head-of-line blocking: requisições subsequentes precisam esperar se uma requisição anterior na mesma conexão estiver travada.
- Implicações para o throughput: pode exigir muitas conexões abertas para páginas complexas, aumentando o overhead e potencialmente limitando as requisições simultâneas. Os proxies muitas vezes precisam gerenciar um grande número de conexões.
HTTP/2
- Modelo de conexão: uma única conexão TCP para múltiplos streams simultâneos (multiplexação).
- Recursos: compressão de cabeçalhos, server push, priorização de streams.
- Implicações para o throughput: reduz o overhead de conexão, mitiga o head-of-line blocking (na camada de aplicação) e utiliza os recursos de rede com eficiência. Os proxies se beneficiam de menos handshakes TCP e melhor uso de recursos. Ainda assim, o overhead de SSL/TLS continua significativo, já que o HTTP/2 normalmente roda sobre TLS.
HTTP/3
- Modelo de conexão: baseado em QUIC (Quick UDP Internet Connections) sobre UDP.
- Recursos: TLS 1.3 embutido, multiplexação de streams sem head-of-line blocking (na camada de transporte), estabelecimento de conexão mais rápido (0-RTT/1-RTT), melhor recuperação de perdas.
- Implicações para o throughput: projetado para menor latência e melhor desempenho em redes instáveis. A natureza baseada em UDP pode resultar em transferência de dados mais eficiente e menor latência, o que se traduz em throughput efetivo maior, especialmente em ambientes móveis ou com alta perda. Os proxies precisam suportar UDP e QUIC para desempenho ideal.
