Optimisation des serveurs d'origine CDN pour les infrastructures dédiées

L'optimisation de ton serveur dédié en tant que serveur d'origine pour un CDN est une discipline différente de celle qui consiste à l'optimiser pour le trafic direct des utilisateurs. Le CDN gère la charge simultanée et la répartition géographique ; le serveur d'origine doit répondre de manière fiable aux requêtes de récupération du CDN en fournissant des en-têtes de cache corrects, des ressources compressées et un temps de réponse minimal jusqu'au premier octet.

En quoi les requêtes d'origine CDN diffèrent-elles des requêtes directes des utilisateurs ?

Lorsque le CDN est déployé en amont de ton serveur dédié, les habitudes de navigation des utilisateurs changent radicalement :

Trafic direct (sans CDN) : chaque requête utilisateur passe par ton serveur. Une forte concurrence implique de nombreuses connexions simultanées. Le temps de réponse a un impact direct sur l'expérience utilisateur.

Trafic acheminé via un CDN : les nœuds périphériques du CDN mettent les réponses en cache et les fournissent aux utilisateurs à partir de points de présence (PoP) géographiques. Ton serveur d'origine reçoit des requêtes de récupération du CDN — il s'agit principalement de manquements de cache pour du contenu nouveau ou périmé. La charge simultanée est moindre, mais les requêtes peuvent être moins prévisibles (l'expiration du cache entraîne des récupérations simultanées depuis plusieurs nœuds périphériques).

Les « tempêtes de cache miss » : lorsqu’une ressource très sollicitée arrive à expiration simultanément sur tous les nœuds du CDN, plusieurs nœuds périphériques demandent la même ressource en même temps. Si le serveur d’origine met du temps à répondre, les cache miss s’accumulent, ce qui peut entraîner la diffusion de contenu obsolète ou l’échec des requêtes pendant la fenêtre de rafraîchissement. Cloudflare ça l’« Origin Shield »: acheminer le trafic de la périphérie vers l’origine via un seul nœud intermédiaire réduit le nombre de requêtes simultanées vers l’origine pendant le rafraîchissement du cache.

Nginx pour optimiser les performances du serveur d'origine du CDN

Nginx sur ton serveur dédié nécessite des réglages différents selon qu'il s'agit du service d'origine ou du service destiné directement aux utilisateurs.

Processus de travail et connexions :

# /etc/nginx/nginx.conf

# Match worker count to CPU cores

worker_processes auto;

# Increase for origin serving high-traffic CDN pulls

events {

    worker_connections 4096;

    use epoll;

    multi_accept on;

}

# /etc/nginx/nginx.conf

# Match worker count to CPU cores

worker_processes auto;

# Increase for origin serving high-traffic CDN pulls

events {

    worker_connections 4096;

    use epoll;

    multi_accept on;

}

Maintien de connexion pour les connexions CDN : les nœuds périphériques du CDN envoient des requêtes répétées à ton serveur d'origine. Les connexions de maintien éliminent la surcharge liée à la négociation TCP à chaque requête :

http {

    # Keep connections to CDN alive

    keepalive_timeout 120s;

    keepalive_requests 1000;

    upstream origin_backend {

        server 127.0.0.1:8080;

        keepalive 64;  # Connection pool size

    }

}

http {

    # Keep connections to CDN alive

    keepalive_timeout 120s;

    keepalive_requests 1000;

    upstream origin_backend {

        server 127.0.0.1:8080;

        keepalive 64;  # Connection pool size

    }

}

Compression Gzip à la source : les nœuds du CDN mettent généralement en cache la version compressée et la servent directement. Configure Gzip à la source pour tous les types de fichiers compressibles :

gzip activé ;

gzip_vary activé ;

gzip_proxied any ;

gzip_comp_level 6 ;

gzip_min_length 1024 ;

gzip_types

    text/plain

    text/css

    text/javascript

    application/javascript

    application/json

    application/xml

    image/svg+xml

    font/woff2;

gzip on;

gzip_vary on;

gzip_proxied any;

gzip_comp_level 6;

gzip_min_length 1024;

gzip_types

    text/plain

    text/css

    text/javascript

    application/javascript

    application/json

    application/xml

    image/svg+xml

    font/woff2;

Le niveau 6 offre un bon compromis entre le taux de compression et la charge CPU. Les niveaux 7 à 9 apportent un gain de compression minime au prix d'une charge CPU importante — ce qui en vaut rarement la peine pour les ressources statiques.

En-têtes Cache-Control : la configuration d'origine la plus importante

Le comportement du CDN dépend presque entièrement des en-têtes Cache-Control envoyés par ton serveur d'origine. Le choix de ces en-têtes détermine si ton CDN met en cache de manière intensive (ce qui réduit la charge sur le serveur d'origine) ou s'il effectue des requêtes fréquentes (ce qui génère des requêtes inutiles vers le serveur d'origine).

Ressources statiques (CSS, JS, images, polices) : définis une durée de validité maximale longue avec des URL à empreinte digitale. Lorsque le contenu du fichier change, le nom du fichier change aussi (hachage du contenu par Webpack, etc.), donc tu peux mettre en cache sans crainte :

location ~* \.(css|js|woff2|woff|ttf|jpg|jpeg|png|gif|ico|svg)$ {

    expires 1y;

    add_header Cache-Control "public, max-age=31536000, immutable";

    add_header Vary "Accept-Encoding";

}

location ~* \.(css|js|woff2|woff|ttf|jpg|jpeg|png|gif|ico|svg)$ {

    expires 1y;

    add_header Cache-Control "public, max-age=31536000, immutable";

    add_header Vary "Accept-Encoding";

}

La directive « immutable » indique au CDN et aux navigateurs de ne jamais revalider cette URL : le contenu ne changera jamais à cette adresse.

Pages HTML : mise en cache courte ou inexistante. Le contenu HTML change à chaque mise à jour et ne doit pas être mis en cache de manière intensive, sauf si tu as mis en place un mécanisme d'invalidation de cache approprié :

location / {

    add_header Cache-Control "public, max-age=300, stale-while-revalidate=60";

}

location / {

    add_header Cache-Control "public, max-age=300, stale-while-revalidate=60";

}

stale-while-revalidate=60 permet au CDN de servir une réponse HTML légèrement périmée tout en récupérant une nouvelle copie en arrière-plan — ça réduit les requêtes vers le serveur d'origine sans pour autant servir de contenu périmé aux utilisateurs pendant plus de 60 secondes.

Réponses API : généralement sans mise en cache ou avec un TTL court :

location /api/ {

    add_header Cache-Control "private, no-store";

}

location /api/ {

    add_header Cache-Control "private, no-store";

}

Configuration d'Origin Shield

Un « origin shield » est une fonctionnalité CDN qui achemine tout le trafic entre la périphérie et la source via un seul point de présence (PoP) régional, plutôt que de laisser tous les nœuds périphériques du monde entier récupérer directement les données depuis ta source. L'avantage concret : au lieu que 50 nœuds périphériques demandent chacun le même élément lorsque le cache expire, un seul nœud « shield » effectue la requête et distribue la réponse mise en cache aux autres nœuds périphériques.

Le cache à plusieurs niveauxCloudflare met en œuvre cette fonctionnalité sous la forme d'une topologie de cache intelligent à plusieurs niveaux qui sélectionne automatiquement le point de présence intermédiaire le plus adapté en fonction de tes schémas de trafic. Active-la dans le Cloudflare , sous Mise en cache > Cache à plusieurs niveaux.

Pour les serveurs d'origine situés dans le centre de données d'InMotion à Los Angeles, le niveau « West US » Cloudflareoffre la latence la plus faible entre le pare-feu et le serveur d'origine. Pour le centre de données d'Amsterdam, le niveau « Western Europe » est le plus adapté.

Diffusion de ressources statiques depuis NVMe: configuration des E/S

NVMe de ton serveur dédié fournissent les ressources statiques aux nœuds périphériques du CDN. Le débit NVMe est rarement le facteur limitant pour la diffusion de fichiers statiques : NVMe généralement la bande passante réseau NVMe atteint ses limites avant NVMe . Mais la configuration du système de fichiers a une incidence sur la vitesse de diffusion :

Cache des fichiers ouverts : Nginx les descripteurs de fichiers et les résultats de stat() pour les fichiers fréquemment servis :

open_file_cache max=10000 inactive=30s;

open_file_cache_valid 60s;

open_file_cache_min_uses 2;

open_file_cache_errors on;

open_file_cache max=10000 inactive=30s;

open_file_cache_valid 60s;

open_file_cache_min_uses 2;

open_file_cache_errors on;

Ça évite d'avoir à répéter les appels système open() et stat() pour les mêmes fichiers — une amélioration notable pour la diffusion de contenu statique avec un taux de requêtes élevé.

Sendfile : utilise l'appel système sendfile() du noyau à la place de read()+write() pour le transfert de fichiers. Transfert de données sans copie :

sendfile on;

tcp_nopush on;  # Regroupe les appels sendfile pour plus d'efficacité

tcp_nodelay on; # Désactive Nagle une fois les données envoyées

sendfile on;

tcp_nopush on;  # Batch sendfile calls for efficiency

tcp_nodelay on; # Disable Nagle after data is sent

AIO pour les fichiers volumineux : pour les fichiers vidéo, les téléchargements volumineux ou tout autre fichier de plus de 1 Mo :

aio activé ;

directio 512 ;  # Utilise l'E/S directe pour les fichiers de plus de 512 octets

output_buffers 2 128k ;

aio on;

directio 512;  # Use direct I/O for files over 512 bytes

output_buffers 2 128k;

Suivi des performances du serveur d'origine du point de vue du CDN

La surveillance standard des serveurs affiche l'utilisation des ressources de ton serveur. Pour évaluer les performances à la source du point de vue du CDN, il faut effectuer une surveillance au niveau du CDN.

Cloudflare affiche le temps de réponse de l'origine (le temps nécessaire pour aller de la périphérie du CDN à ton serveur et revenir), le taux de réussite du cache et les taux d'erreur. Cible :

• Taux de réussite du cache : plus de 85 % pour les sites riches en contenu, plus de 95 % pour les sites riches en ressources statiques
• Temps de réponse de l'origine (TTFB à la périphérie) : moins de 100 ms pour les réponses mises en cache, moins de 500 ms pour les requêtes vers l'origine
• Taux d'erreur à la source (5xx) : inférieur à 0,1 %

L'analyse du journalNginx montre ce que le CDN demande réellement à ton serveur d'origine. Un volume élevé de requêtes pour la même URL indique un problème de mise en cache : soit l'URL n'est pas mise en cache, soit le cache expire trop souvent :

# Trouver les URL les plus consultées (éventuels échecs de mise en cache)

awk '{print $7}'nginx.log | sort | uniq -c | sort -rn | head -20

# Find most frequently requested URLs (potential caching misses)

awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Si les mêmes URL dynamiques apparaissent à plusieurs reprises, c'est soit qu'elles ne peuvent pas être mises en cache (ce qui est normal pour les points de terminaison d'API), soit qu'il leur manque des en-têtes Cache-Control (ce qui peut être corrigé).

WordPress source CDN

WordPress fonctionnent généralement via un CDN avec un serveur dédié comme serveur d'origine. WP Rocket, W3 Total Cacheet LiteSpeed Cache prennent tous en charge l'intégration d'un CDN et gèrent automatiquement les en-têtes Cache-Control pour les types de contenu WordPress.

WordPress essentiels pour la diffusion depuis l'origine via un CDN :

• Active la mise en cache des objets avec Redis (ça réduit le temps de génération des pages dynamiques et améliore le TTFB du serveur d'origine)
• Définis la durée de vie du cache de page (TTL) entre 30 et 60 minutes pour les utilisateurs non connectés
• Exclure de la mise en cache les URL d'administration, le panier, la page de paiement et les pages de compte
• Active l'intégration du CDN dans le plugin de mise en cache pour réécrire les URL des ressources en noms d'hôte du CDN

InMotion HostingPremier Care InMotion Hostingcomprend une heure de consultation avec InMotion Solutions pour les équipes qui mettent en place l'intégration d'un CDN pour la première fois ; cette heure de consultation mensuelle peut être utilisée pour vérifier et optimiser la configuration du CDN.

À lire aussi: Optimisation de la latence réseau pour les serveurs dédiés | Surveillance des ressources serveur et optimisation des performances