Langues disponibles:

Fiber : La Performance plutôt que la Pureté « Idiomatique »

Ce post a été initialement écrit en anglais. La traduction peut ne pas refléter 100% des idées originales de l'auteur.

Je peux déjà entendre les puristes de Go aiguiser leurs fourches. « Utilise la bibliothèque standard », scandent-ils. « Les frameworks sont un anti-pattern », hurlent-ils.

Je m’en moque.

Je n’utilise pas Fiber parce que je suis paresseux. Je ne l’utilise pas parce qu’il ressemble à Express.js. Je l’utilise parce que j’ai une addiction pathologique à la vitesse, et net/http, que bénie soit son âme sûre et compatible, est tout simplement trop poli pour la violence que je veux infliger à mon CPU.

Le Goulot d’Étranglement « Standard »

La bibliothèque standard de Go est fantastique. Elle est robuste. Elle est compatible HTTP/2. Mais elle est aussi conçue pour être « sûre » et polyvalente. Elle alloue de la mémoire comme si c’était gratuit. Chaque requête crée de nouveaux objets, de nouveaux tampons, générant du travail pour le Garbage Collector.

Dans mon monde, le Garbage Collector est l’ennemi. Chaque milliseconde que le CPU passe à balayer vos déchets est une milliseconde où il ne sert pas une requête.

Entrez Fasthttp

Fiber n’est pas juste un wrapper, c’est une implémentation de fasthttp.

Pour ceux qui ne connaissent pas, fasthttp est le cousin rebelle de net/http. Il triche. Il utilise des pools de workers. Il réutilise les objets de manière agressive. Il effectue zéro allocation mémoire dans les chemins critiques.

Il dit essentiellement au Garbage Collector d’aller prendre une pause café parce qu’il n’y a rien à nettoyer.

Est-ce qu’il casse certaines conformités aux cas limites du HTTP ? Oui. Est-ce qu’il utilise des pointeurs unsafe ? Absolument. Est-ce qu’il gère 10 fois plus de requêtes par seconde que la bibliothèque standard ? Vous pariez que oui.

Zéro Allocation est Roi

Regardez ça. Il ne s’agit pas de sucre syntaxique, il s’agit d’efficacité brute.

app.Get("/", func(c *fiber.Ctx) error {
    return c.SendString("Hello, World!")
})

Lorsque ce gestionnaire s’exécute, Fiber n’alloue pas une nouvelle chaîne sur le tas si ce n’est pas nécessaire. Il réutilise le contexte. Il découpe des tableaux d’octets existants. Il traite la mémoire comme une ressource rare, pas comme un buffet à volonté.

Donc…

…Je suis un homme simple. Je vois une barre de graphique de benchmark monter, et mon cerveau libère de la dopamine.

Si vous construisez une API bancaire qui doit supporter chaque en-tête HTTP obscur défini en 1999, utilisez net/http. Mais si vous voulez saturer votre carte réseau avant même que votre CPU ne se réveille, arrêtez de vous soucier d’être « idiomatique » et commencez à vous soucier du débit.

Les bits consomment de l’énergie. Utiliser plus de cycles CPU que nécessaire est moralement offensant. Fiber respecte le matériel.

À bientôt dans le prochain article.