Cloudflare a repensé la disposition mémoire de son résolveur 1.1.1.1 et a libéré environ 100 téraoctets de RAM sur son parc mondial.
Les ingénieurs, en Rust, ont réduit la taille par entrée de 953 à 420 octets, améliorant à la fois la capacité et la performance globale.
Réduction de l’empreinte : 250 milliards d’entrées, 1 octet coûte 250 Go
Le service Big Pineapple maintient en permanence plus de 250 milliards d’entrées en cache. À cette échelle, chaque octet gaspillé se traduit par des centaines de gigaoctets sur l’ensemble du parc. Les équipes ont ciblé la représentation en mémoire des enregistrements DNS pour obtenir des gains massifs sans modifier l’interface réseau.
Les optimisations ont fait passer la taille par entrée de 953 octets à 420 octets, soit une réduction de 56 %. Cette contraction représente une économie agrégée d’environ 100 To de RAM, équivalente à la mémoire installée dans une centaine de serveurs de génération courante.
Techniquement, les changements ont porté sur la suppression de padding, la compaction des métadonnées, l’utilisation de types entiers plus compacts et la fusion de champs redondants. Chaque modification vise la localité mémoire et la diminution des allocations dynamiques pour limiter la fragmentation.
Le déploiement a débuté le 18 mai 2026 et s’est achevé le 6 juillet 2026, période durant laquelle Cloudflare a observé l’impact sur la production sans interruption de service notable.
Performances : insertions +43 % et recherches −19 % de latence
En repensant l’organisation des entrées, les ingénieurs ont obtenu des gains de vitesse non négligeables. Le débit d’insertion est passé de 625 000 à 893 000 entrées/s, soit une hausse de 43 %, tandis que la latence de recherche a diminué de 19 %.
Ces améliorations s’expliquent par une réduction du nombre d’allocations et une meilleure localité mémoire, qui réduisent les cache misses CPU. Les opérations critiques sont restées lock-free autant que possible pour préserver le parallélisme sur des machines multi-socket.
Le choix de Rust a facilité l’écriture de code bas niveau sûr : l’équipe a pu manipuler des layouts mémoire compacts sans sacrifier la sûreté, ce qui a réduit les bugs liés à la gestion manuelle de la mémoire et accéléré le cycle d’itération.
Sur le terrain, cela se traduit par moins de requêtes montantes vers les serveurs autoritaires, un meilleur taux de hit et des économies en bande passante en amont, gains qui seront réinvestis pour augmenter la capacité effective du cache.
Cinq optimisations successives : détails techniques et impacts mesurables
Les changements ont été appliqués en cinq étapes cumulatives, chacune ciblant un goulot mémoire précis. Parmi elles : compaction des en-têtes, encodage variable des temps d’expiration, regroupement des petites structures en blocs contigus, élimination des pointeurs redondants et pool d’allocations réutilisables pour les réponses communes.
Avant/après, les métriques clés montrent une réduction des allocations par entrée de 1,1 KB à 461 octets, et une empreinte nette par entrée de 953 à 420 octets. Ces chiffres proviennent des benchmarks internes exécutés en conditions proches de la production.
Chaque étape a été validée par des tests de charge et par des déploiements progressifs canarisés. L’approche par petites itérations a permis d’isoler l’effet de chaque optimisation sur la latence et la stabilité, limitant le risque d’effets secondaires en production.
Cloudflare prévoit d’utiliser la marge mémoire récupérée pour augmenter le nombre d’entrées mises en cache, améliorant ainsi le taux de hit sans accroître la consommation de RAM globale, et explore d’autres optimisations pour réduire encore la mémoire et le coût opérationnel.
| Métrique | Avant | Après | Variation |
|---|---|---|---|
| Empreinte par entrée | 953 octets | 420 octets | -56 % |
| Allocations par entrée | 1,1 KB | 461 octets | -58 % |
| Insertions (entries/s) | 625 000 | 893 000 | +43 % |
| Latence de lookup | 828 ns | 670 ns | -19 % |
