veilletech.frCe qui se passe
Le prix de la RAM et des disques a fortement grimpé cette année. Cloudflare, qui exploite plusieurs produits de stockage massivement distribués, cherche donc de la capacité sans acheter de matériel. Le prototype s'appelle Cache Transcoding, construit pendant un stage du programme 1.1.1.1.
Le principe : quand une réponse éligible entre dans le cache, elle est encodée en Zstandard à l'intérieur de Pingora, avant écriture disque. Elle reste compressée tant qu'elle vit dans le cache et pendant ses déplacements entre centres de données via Tiered Cache, puis elle est décodée avant d'être servie au client.
Jusqu'ici, Cloudflare stockait un actif dans l'encodage fourni par l'origine : une réponse non compressée était écrite non compressée, et transférée telle quelle.
Ce qu'on compresse, et ce qu'on laisse
Le tri est la partie intéressante. Sur l'échantillon de trafic analysé :
| Type | Part des requêtes | Part des octets |
|---|---|---|
| Images, vidéo, polices | 21,4 % | 63,3 % |
| Texte compressible (HTML, JSON, CSS, JS) | 67,3 % | 22,3 % |
Les médias sont déjà compressés : les repasser à zstd brûlerait du CPU pour rien. Le texte, lui, arrive non encodé dans environ 71 % des cas et se compresse bien — facteur 2,834× mesuré sur le corpus de test.
L'asymétrie qui rend le calcul favorable
| Mesure | Valeur |
|---|---|
| Ratio de compression | 2,834× |
| Coût d'encodage | 4,31 ns/octet (~232 Mo/s), une fois par remplissage |
| Coût de décodage | 1,56 ns/octet (~641 Mo/s), à chaque service |
Encoder coûte presque trois fois plus cher que décoder, par octet — mais un actif est servi bien plus souvent qu'il n'est rempli. Le niveau 3 de zstd a été retenu comme point d'équilibre : l'essentiel du gain sans transformer les remplissages en goulot d'étranglement CPU. Pour situer zstd, Cloudflare rappelle ses mesures antérieures : 42 % plus rapide que Brotli à taille quasi identique, et 11,3 % plus petit que gzip à vitesse comparable.
Le résultat contre-intuitif
L'équipe a d'abord envisagé de ne transcoder que le contenu populaire, réutilisé plus souvent. Ça ne marchait pas. Le décodage se paie à chaque service, donc restreindre au contenu chaud réduisait le gain de stockage sans réduire le CPU d'autant. La politique simple l'a emporté : tout texte éligible d'au moins 4 KiB, ce qui capture presque tout le bénéfice mesuré en restant dans le budget CPU.
À retenir
- C'est un prototype, pas une fonctionnalité livrée. Le résultat annoncé est « des pétaoctets de capacité effective » contre quelques pour cent de CPU.
- Le raisonnement est transposable à n'importe quel cache applicatif : compter les lectures avant de choisir un niveau de compression.
- Une politique de sélection fine peut être moins bonne qu'un seuil unique — encore faut-il l'avoir mesuré.
Source : Cloudflare