Benchmarking de Servidores HTTP em Go, Rust e CSharp: Desempenho e Consumo de Memória

O Desafio da Concorrência em Servidores HTTP Modernos

Quando construímos aplicações web de alto tráfego, o servidor HTTP é a primeira linha de defesa contra lentidões e quedas. Em termos simples, um servidor HTTP precisa escutar uma porta de rede, aceitar conexões simultâneas de milhares de usuários, ler requisições, processar lógica e devolver respostas rapidamente. O gargalo clássico deixou de ser o processador e passou a ser a forma como o sistema gerencia a memória e as esperas por dados vindos da rede, um conceito conhecido como I/O assíncrono. Linguagens modernas resolvem esse problema de maneiras radicalmente diferentes, criando um cenário perfeito para testes de desempenho, ou benchmarks.

Fazer benchmarking significa colocar softwares sob estresse controlado para descobrir quem atende mais requisições por segundo e quem consome menos memória RAM. No entanto, números crus de laboratório raramente contam a história inteira de um sistema em produção. Fatores como picos de tráfego, tempo de resposta sob estresse e o comportamento do coletor de lixo — o faxineiro automático de memória da aplicação — mudam drasticamente o custo operacional. Vamos analisar três pesos-pesados da engenharia de software atual: Go, Rust e CSharp, entendendo suas promessas e limitações reais.

Go: Concorrência Nativa e Simplicidade Operacional

Criado pelo Google, o Go nasceu com o propósito explícito de simplificar a criação de serviços de rede eficientes. A grande estrela do Go são as goroutines, que são linhas de execução leves gerenciadas pelo próprio runtime da linguagem, custando apenas alguns poucos quilobytes de memória cada. Na prática, você pode abrir dezenas de milhares de conexões simultâneas sem esmagar o sistema operacional com threads pesadas. O pacote nativo net/http oferece um servidor HTTP robusto e pronto para produção sem que o desenvolvedor precise instalar bibliotecas externas complexas.

O calcanhar de Aquiles histórico de Go tem sido seu coletor de lixo concorrente, que precisa pausar brevemente as operações para limpar objetos órfãos da memória. Embora o Google tenha investido anos otimizando esse mecanismo para reduzir as pausas para a casa dos microssegundos, aplicações com alocações de memória extremamente agressivas ainda sofrem picos de uso de RAM. O código abaixo demonstra a simplicidade assustadora de criar um servidor web básico em Go:

package main

import (
    "fmt"
    "net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Servidor HTTP em Go rodando com sucesso!")
}

func main() {
    http.HandleFunc("/", handler)
    http.ListenAndServe(":8080", nil)
}

Em cenários de benchmark, Go costuma entregar uma das melhores relações entre velocidade de desenvolvimento e desempenho bruto. Ele consome um pouco mais de memória que o Rust devido à sua camada de runtime e ao coletor de lixo, mas compensa permitindo que equipes entreguem sistemas estáveis e fáceis de manter em prazos curtos.

Rust: Controle Total de Hardware e Zero Garbage Collector

Rust é a linguagem que conquistou o coração dos engenheiros obcecados por desempenho extremo e segurança de memória em tempo de compilação. Diferente de Go ou CSharp, Rust não possui um coletor de lixo. A responsabilidade de liberar a memória recai sobre o próprio código gerado pelo compilador, que insere instruções precisas de limpeza assim que uma variável sai do escopo. Isso significa que o consumo de memória de um servidor Rust é incrivelmente previsível, plano e livre de pausas inesperadas para limpeza.

O ecossistema web de Rust gira em torno de frameworks altamente otimizados como Actix-web ou Axum, construídos sobre o Tokio, um motor de I/O assíncrono extremamente rápido. O trade-off dessa eficiência é a complexidade de desenvolvimento. O rigoroso sistema de empréstimos e referências do compilador — conhecido como borrow checker — exige que o desenvolvedor pense profundamente sobre a vida útil de cada dado antes mesmo de rodar o programa pela primeira vez. Veja como um servidor web assíncrono se parece utilizando o framework Axum:

use axum::{routing::get, Router};

#[tokio::main]
async fn main() {
    let app = Router::new().route("/", get(|| async { "Servidor HTTP em Rust!" }));
    let listener = tokio::net::TcpListener::bind("127.0.0.1:8080").await.unwrap();
    axum::serve(listener, app).await.unwrap();
}

Em testes de carga extrema, o Rust frequentemente coroa a tabela de desempenho, atingindo taxas altíssimas de requisições por segundo com o menor consumo de memória por conexão da categoria. No entanto, o custo inicial de engenharia e a curva de aprendizado íngreme tornam essa escolha viável principalmente para serviços críticos onde cada milissegundo e cada megabyte importam.

CSharp: A Revolução do Desempenho Moderno com .NET

Muitos profissionais associam o CSharp exclusivamente ao ecossistema Windows corporativo tradicional, mas a plataforma .NET moderna mudou completamente de patamar. Hoje, o .NET Core é multiplataforma, de código aberto e figura consistentemente entre os ambientes de execução mais rápidos do mundo para servidores web, frequentemente superando linguagens tradicionalmente consideradas mais leves em benchmarks oficiais da indústria. O segredo dessa reviravolta reside em décadas de otimização contínua do compilador Just-In-Time (JIT) e na introdução recente do Native AOT, que compila o código CSharp diretamente em código de máquina nativo.

O CSharp equilibra a produtividade de uma linguagem de alto nível com recursos de baixo nível, como manipulação segura de ponteiros e estruturas de dados alocadas diretamente na pilha de memória (stack), evitando a pressão sobre o coletor de lixo. O código abaixo mostra a concisão dos Minimal APIs introduzidas nas versões recentes do .NET:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () => "Servidor HTTP em CSharp com .NET!");

app.Run("http://localhost:8080");

record WeatherForecast(DateOnly Date, int TemperatureC, string Summary);

Em termos de consumo de memória, o .NET consome mais RAM na largada do que Rust e Go devido ao peso de seu ecossistema e runtime, mas seu rendimento sob carga pesada é formidável. Quando o Native AOT é ativado, o consumo de memória cai drasticamente, aproximando-o dos concorrentes compilados diretamente.

Metodologia de Teste e Comparativo Prático

Para comparar essas três tecnologias de forma justa, configuramos um cenário de laboratório simulando tráfego real. Cada servidor foi executado em um ambiente isolado com recursos de hardware limitados, processando uma rota simples que retorna texto puro. Utilizamos a ferramenta de teste de carga oq/wrk para disparar dezenas de conexões concorrentes durante sessões de sessenta segundos, medindo a latência média, o desvio padrão e o uso de memória RAM no pico do teste.

Como mostra a tabela, o Rust lidera em eficiência pura de recursos e vazão máxima, seguido de perto pelo CSharp moderno em capacidade de processamento bruto, enquanto o Go mantém uma vantagem incontestável na facilidade de implementação e manutenção diária do código por equipes multidisciplinares.

Considerações Finais sobre a Escolha Tecnológica

A escolha entre Go, Rust e CSharp para construir servidores HTTP concorrentes não deve se basear apenas em milissegundos extraídos em benchmarks sintéticos. Cada linguagem resolve um conjunto diferente de restrições de engenharia e custos organizacionais. Se a sua prioridade é velocidade de entrega de microsserviços confiáveis com excelente ecossistema nativo, Go continua sendo uma escolha formidável. Se você precisa esrever componentes de infraestrutura de missão crítica onde cada byte de RAM e ciclo de CPU conta, o Rust justifica amplamente seu custo de desenvolvimento. Por fim, se a sua empresa já investe no ecossistema .NET, as versões recentes do CSharp oferecem desempenho de ponta sem exigir reescritas radicais de arquitetura.