Escolha da linguagem

A diferença mais prática entre as cinco linguagens em produção não está na sintaxe: está em como cada runtime percebe os limites de CPU e memória do container. Um runtime que acha que tem mais CPU ou memória do que tem é freado pelo sistema operacional, ou encerrado por falta de memória.

O que o runtime enxerga dentro do container

Os programas abaixo mostram, em cada linguagem, quantas CPUs e quanta memória o runtime acredita ter.

import os from "node:os";
import v8 from "node:v8";

const mb = (bytes: number) => Math.round(bytes / 1024 / 1024);

console.log("CPUs do host:          ", os.cpus().length);
console.log("paralelismo disponível:", os.availableParallelism());
console.log("limite de memória (MB):", mb(process.constrainedMemory()));
console.log("teto do heap V8 (MB):  ", mb(v8.getHeapStatistics().heap_size_limit));

import os
from pathlib import Path


def limite_cgroup(arquivo: str) -> str:
    caminho = Path("/sys/fs/cgroup") / arquivo
    return caminho.read_text().strip() if caminho.exists() else "indisponível"


print("CPUs do host:          ", os.cpu_count())
print("CPUs do processo:      ", os.process_cpu_count())
print("cota de CPU (cgroup):  ", limite_cgroup("cpu.max"))
print("limite de memória:     ", limite_cgroup("memory.max"))

package main

import (
	"fmt"
	"math"
	"runtime"
	"runtime/debug"
)

func main() {
	fmt.Println("CPUs do host:          ", runtime.NumCPU())
	fmt.Println("GOMAXPROCS:            ", runtime.GOMAXPROCS(0))

	limite := debug.SetMemoryLimit(-1) // -1 só consulta o valor atual
	if limite == math.MaxInt64 {
		fmt.Println("limite de memória do GC: nenhum (defina GOMEMLIMIT)")
	} else {
		fmt.Println("limite de memória do GC (MB):", limite/1024/1024)
	}
}

public class Recursos {
    public static void main(String[] args) {
        var runtime = Runtime.getRuntime();
        System.out.println("processadores:          " + runtime.availableProcessors());
        System.out.println("heap máximo (MB):       " + runtime.maxMemory() / 1024 / 1024);
    }
}

var memoria = GC.GetGCMemoryInfo();

Console.WriteLine($"processadores:          {Environment.ProcessorCount}");
Console.WriteLine($"memória disponível (MB): {memoria.TotalAvailableMemoryBytes / 1024 / 1024}");
Console.WriteLine($"GC de servidor:         {System.Runtime.GCSettings.IsServerGC}");

O resultado, num container com 1 CPU e 512 MB

Rodamos os cinco programas com docker run --cpus=1 --memory=512m, numa máquina com 8 CPUs:

Cada linha tem uma consequência prática:

• Python: frameworks que calculam o número de processos ou threads a partir de os.cpu_count() criam 8 numa máquina de 1 CPU. Defina o número de processos explicitamente.
• Go: com 2 threads numa cota de 1 CPU, o processo é freado. No nosso teste de carga, um servidor Go atendeu 7.000 pedidos por segundo com p99 de 84 ms sem ajuste, e 55.000 com p99 de 2 ms com GOMAXPROCS=1. Sem GOMEMLIMIT, o coletor de lixo não sabe que existe um limite, e o processo pode ser encerrado por falta de memória antes de coletar.
• Java: com 512 MB no container, o heap fica em 123 MB, e a aplicação pode falhar por falta de memória com três quartos do container livres. Com -XX:MaxRAMPercentage=75, o heap subiu para 371 MB no mesmo teste.

Configurar cada runtime para o container

No Kubernetes, o limite de CPU pode ser fracionado, como 500m (meia CPU). Runtimes que arredondam para cima, como o Go com mínimo de 2, ficam ainda mais distantes do limite real. Uma alternativa comum é definir só a requisição de CPU, sem limite rígido, para evitar o freio, e controlar o uso pela escala automática.

Medir com honestidade

Se a escolha da linguagem ou do framework depender de desempenho, meça com a sua carga, evitando as armadilhas que distorceram o nosso próprio teste:

Uma configuração mínima para comparar, com os números apresentados neste tópico:

# O servidor com 1 CPU e 512 MB, numa rede compartilhada com o gerador de carga
docker network create teste
docker run -d --name api --network teste --cpus=1 --memory=512m minha-api

# Aquecimento e depois a medição, com percentis
docker run --rm --network teste alpine sh -c \
  "apk add -q wrk && wrk -t2 -c50 -d30s http://api:3000/ >/dev/null && \
   wrk -t2 -c50 -d15s --latency http://api:3000/"

# Memória durante a carga
docker stats --no-stream api

Lista de revisão

Escolha

• A escolha considerou a equipe, as bibliotecas e o custo de operação, e não só desempenho?
• O modelo de concorrência da linguagem está claro para a equipe, com as armadilhas dele?
• Se há uma segunda linguagem, existe um motivo claro e um nicho definido?

Container

• O runtime enxerga o número certo de CPUs, ou foi configurado para isso?
• O limite de memória do runtime (heap, GOMEMLIMIT) está ajustado ao limite do container?
• O número de processos ou threads de trabalho foi definido explicitamente onde o runtime não detecta o limite?

Medição

• Comparações de desempenho usaram a carga real, com aquecimento e percentis altos?
• O servidor e o framework medidos são os mesmos de produção?