Fiber: Performance Acima da Pureza “Idiomática”
Já posso ouvir os puristas do Go afiando seus forcados. “Use a biblioteca padrão”, eles entoam. “Frameworks são um antipadrão”, eles gritam.
Eu não me importo.
Não estou usando Fiber porque sou preguiçoso. Não estou usando porque se parece com o Express.js. Estou usando porque tenho um vício patológico por velocidade, e o net/http, abençoado seja seu coração seguro e compatível, é simplesmente educado demais para a violência que quero infligir na minha CPU.
O Gargalo “Padrão”
A biblioteca padrão do Go é fantástica. É robusta. É compatível com HTTP/2. Mas também é projetada para ser “segura” e de propósito geral. Ela aloca memória como se fosse de graça. Cada requisição cria novos objetos, novos buffers, gerando trabalho para o Coletor de Lixo.
No meu mundo, o Coletor de Lixo é o inimigo. Cada milissegundo que a CPU gasta varrendo a sua bagunça é um milissegundo que ela não está servindo uma requisição.
Entra em Cena o Fasthttp
O Fiber não é apenas um wrapper, é uma implementação do fasthttp.
Para quem não sabe, fasthttp é o primo rebelde do net/http. Ele trapaceia. Ele usa pools de workers. Ele reutiliza objetos agressivamente. Ele realiza zero alocação de memória em caminhos críticos (hot paths).
Ele essencialmente diz ao Coletor de Lixo para fazer uma pausa para o café porque não há nada para limpar.
Ele quebra algumas conformidades de casos extremos do HTTP? Sim.
Ele usa ponteiros unsafe? Absolutamente.
Ele lida com 10x mais requisições por segundo do que a biblioteca padrão? Pode apostar que sim.
Zero Alocação é Rei
Olhe para isso. Isso não é sobre açúcar sintático, é sobre eficiência bruta.
app.Get("/", func(c *fiber.Ctx) error {
return c.SendString("Hello, World!")
})
Quando este handler é executado, o Fiber não aloca uma nova string no heap se não for necessário. Ele reutiliza o contexto. Ele fatia arrays de bytes existentes. Ele trata a memória como um recurso escasso, não como um buffet infinito.
Então…
…sou um homem simples. Vejo a barra de um gráfico de benchmark subir, e meu cérebro libera dopamina.
Se você está construindo uma API bancária que precisa suportar todo cabeçalho HTTP obscuro definido em 1999, use net/http. Mas se você quer saturar sua placa de rede antes mesmo da sua CPU acordar, pare de se preocupar em ser “idiomático” e comece a se preocupar com vazão (throughput).
Bits consomem energia. Usar mais ciclos de CPU do que o necessário é moralmente ofensivo. O Fiber respeita o hardware.
Nos vemos no próximo post.