Optimierung von CDN-Ursprungsservern für dedizierte Infrastruktur

Die Optimierung deines dedizierten Servers als CDN-Origin unterscheidet sich von der Optimierung für den direkten Nutzerverkehr. Das CDN kümmert sich um Parallelität und geografische Verteilung; der Origin muss zuverlässig auf CDN-Pull-Anfragen reagieren – mit korrekten Cache-Headern, komprimierten Assets und einer minimalen Zeit bis zum ersten Byte.

Wie sich CDN-Origin-Anfragen von direkten Nutzeranfragen unterscheiden

Wenn ein CDN vor deinem dedizierten Server eingesetzt wird, ändern sich die Zugriffsmuster der Nutzer grundlegend:

Direkter Datenverkehr (ohne CDN): Jede Nutzeranfrage wird direkt an deinen Server gesendet. Eine hohe Parallelität bedeutet viele gleichzeitige Verbindungen. Die Antwortzeit wirkt sich direkt auf das Nutzererlebnis aus.

Über ein CDN geleiteter Datenverkehr: CDN-Edge-Knoten speichern Antworten im Cache und stellen sie den Nutzern über geografische PoPs bereit. Dein Ursprungsserver erhält CDN-Abrufanfragen – meist Cache-Fehltreffer für neue oder abgelaufene Inhalte. Die Parallelität ist geringer, aber die Anfragen sind möglicherweise weniger vorhersehbar (das Ablaufen des Cache-Caches führt zu gleichzeitigen Abrufen von mehreren Edge-Knoten).

Cache-Miss-Stürme: Wenn eine stark frequentierte Ressource gleichzeitig auf allen CDN-Knoten abläuft, fordern mehrere Edge-Knoten dieselbe Ressource auf einmal an. Ein Origin-Server mit langsamer Antwortzeit führt dazu, dass sich Cache-Misses stauen, was dazu führen kann, dass veraltete Inhalte ausgeliefert werden oder Anfragen während des Aktualisierungsfensters fehlschlagen. Cloudflare dies „Origin Shield“ – das Leiten des Datenverkehrs vom Edge zum Origin über einen einzigen Zwischenknoten reduziert die Anzahl der gleichzeitigen Abrufe vom Origin während der Cache-Aktualisierung.

Nginx für die Leistung des CDN-Origins

Die Nginx auf deinem dedizierten Server erfordert unterschiedliche Einstellungen für den Ursprungsdienst und den direkten Benutzerdienst.

Worker-Prozesse und Verbindungen:

# /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;

}

Keepalive für CDN-Verbindungen: CDN-Edge-Knoten senden wiederholt Anfragen an deinen Origin-Server. Keepalive-Verbindungen vermeiden den Overhead des TCP-Handshakes bei jeder Anfrage:

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

    }

}

Gzip-Komprimierung am Ursprungsserver: CDN-Knoten speichern in der Regel die komprimierte Version im Cache und stellen sie direkt bereit. Konfiguriere Gzip am Ursprungsserver für alle komprimierbaren Dateitypen:

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;

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;

Stufe 6 sorgt für ein ausgewogenes Verhältnis zwischen Komprimierungsrate und CPU-Belastung. Die Stufen 7–9 bieten nur geringfügig mehr Komprimierung bei erheblichem CPU-Aufwand – was sich bei statischen Assets selten lohnt.

Cache-Control-Header: Die wichtigste Origin-Konfiguration

Das Verhalten des CDN hängt fast ausschließlich von den Cache-Control-Headern ab, die dein Ursprungsserver sendet. Ob diese richtig eingestellt sind, entscheidet darüber, ob dein CDN Inhalte intensiv zwischenspeichert (was die Belastung des Ursprungsservers verringert) oder häufig Daten abruft (was unnötige Anfragen an den Ursprungsserver verursacht).

Statische Ressourcen (CSS, JS, Bilder, Schriftarten): Lege für URLs mit Fingerabdruck einen langen „max-age“-Wert fest. Wenn sich der Inhalt der Datei ändert, ändert sich auch der Dateiname (Webpack-Inhalts-Hash usw.), sodass eine aggressive Zwischenspeicherung unbedenklich ist:

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";

}

Die Anweisung „immutable“ weist das CDN und die Browser an, diese URL niemals erneut zu validieren – der Inhalt unter dieser URL wird sich nie ändern.

HTML-Seiten: Kurze oder keine Cache-Dauer. HTML-Seiten ändern sich bei Inhaltsaktualisierungen und sollten nicht aggressiv zwischengespeichert werden, es sei denn, du hast eine ordnungsgemäße Cache-Invalidierung implementiert:

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 ermöglicht es dem CDN, eine leicht veraltete HTML-Antwort auszuliefern, während im Hintergrund eine aktuelle Kopie abgerufen wird – das reduziert die Anzahl der Origin-Anfragen, ohne dass den Nutzern länger als 60 Sekunden veraltete Inhalte angezeigt werden.

API-Antworten: In der Regel „no-cache“ oder kurze TTL:

location /api/ {

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

}

location /api/ {

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

}

Konfiguration von Origin Shield

Ein Origin Shield ist eine CDN-Funktion, die den gesamten Datenverkehr vom Edge zum Origin über einen einzigen regionalen PoP leitet, anstatt zuzulassen, dass alle globalen Edge-Knoten Daten direkt von deinem Origin abrufen. Der praktische Vorteil: Anstatt dass 50 Edge-Knoten jeweils dasselbe Asset anfordern, wenn ein Cache abläuft, stellt ein Shield-Knoten die Anfrage und verteilt die zwischengespeicherte Antwort an die anderen Edge-Knoten.

Der Tiered CacheCloudflare setzt dies als „Smart Tiered Cache“-Topologie um, die anhand deiner Traffic-Muster automatisch den besten Zwischen-PoP auswählt. Aktiviere diese Funktion im Cloudflare unter „Caching > Tiered Cache“.

Bei Ursprungsservern im Rechenzentrum von InMotion in Los Angeles bietet die Region „West US“ Cloudflaredie geringste Latenz zwischen dem Shield und dem Ursprungsserver. Für das Rechenzentrum in Amsterdam ist die Region „Westeuropa“ geeignet.

Bereitstellung statischer Assets über NVMe: I/O-Konfiguration

NVMe deines dedizierten Servers stellen statische Inhalte an CDN-Edge-Knoten bereit. NVMe Durchsatz ist selten der limitierende Faktor bei der Bereitstellung statischer Dateien – in der Regel stößt die Netzwerkbandbreite zuerst an ihre Grenzen, bevor NVMe . Die Konfiguration des Dateisystems wirkt sich jedoch auf die Bereitstellungsgeschwindigkeit aus:

Dateicache öffnen: Nginx Dateideskriptoren und stat()-Ergebnisse für häufig ausgelieferte Dateien zwischen:

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;

Dadurch entfallen wiederholte open()- und stat()-Systemaufrufe für dieselben Dateien – eine messbare Verbesserung bei der Bereitstellung statischer Inhalte mit hoher Anfragerate.

Sendfile: Nutze den Systemaufruf sendfile() des Kernels anstelle von read()+write() für die Dateiübertragung. Datenübertragung ohne Kopieren:

sendfile on;

tcp_nopush on;  # Batch-sendfile-Aufrufe für mehr Effizienz

tcp_nodelay on; # Nagle-Algorithmus deaktivieren, nachdem die Daten gesendet wurden

sendfile on;

tcp_nopush on;  # Batch sendfile calls for efficiency

tcp_nodelay on; # Disable Nagle after data is sent

AIO für große Dateien: Für Videodateien, große Downloads oder andere Dateien über 1 MB:

aio on;

directio 512;  # Direkte E/A für Dateien mit mehr als 512 Byte verwenden

output_buffers 2 128k;

aio on;

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

output_buffers 2 128k;

Überwachung der Origin-Leistung aus Sicht des CDN

Die Standard-Serverüberwachung zeigt die Ressourcenauslastung deines Servers an. Die Leistung des Ursprungsservers aus Sicht des CDN erfordert eine Überwachung auf CDN-Ebene.

Cloudflare zeigt die Antwortzeit des Ursprungsservers (die Zeit vom CDN-Edge zu deinem Server und zurück), die Cache-Trefferquote und die Fehlerraten an. Ziel:

• Cache-Trefferquote: über 85 % bei inhaltsreichen Websites, über 95 % bei Websites mit vielen statischen Elementen
• Antwortzeit des Ursprungsservers (TTFB am Edge): unter 100 ms für zwischengespeicherte Antworten, unter 500 ms für Abrufe vom Ursprungsserver
• Fehlerquote auf der Ursprungsseite (5xx): unter 0,1 %

Die AnalyseNginx zeigt, was das CDN tatsächlich von deinem Origin anfordert. Eine hohe Anzahl von Anfragen für dieselbe URL deutet auf ein Caching-Problem hin – entweder wird die URL nicht zwischengespeichert oder der Cache läuft zu oft ab:

# Die am häufigsten aufgerufenen URLs finden (potenzielle Cache-Fehlgriffe)

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

Wenn dieselben dynamischen URLs immer wieder auftauchen, sind sie entweder nicht zwischenspeicherbar (was bei API-Endpunkten korrekt ist) oder es fehlen die Cache-Control-Header (was behoben werden kann).

WordPress CDN-Ursprungsserver

WordPress laufen häufig über ein CDN, wobei ein dedizierter Server als Ursprungsserver dient. WP Rocket, W3 Total Cacheund LiteSpeed Cache unterstützen alle die CDN-Integration und verwalten Cache-Control-Header automatisch für WordPress Inhaltstypen.

Wichtige WordPress für die Bereitstellung über ein CDN:

• Aktiviere das Objekt-Caching mit Redis (verkürzt die Ladezeit dynamisch generierter Seiten und verbessert die TTFB des Ursprungsservers)
• Stelle die TTL des Seitencaches für nicht angemeldete Benutzer auf 30–60 Minuten ein
• Admin-URLs, Warenkorb-, Kasse- und Kontoseiten vom Caching ausschließen
• Aktiviere die CDN-Integration im Caching-Plugin, um die URLs der Assets in CDN-Hostnamen umzuschreiben

Der „Premier Care“-Tarif InMotion Hostingumfasst Beratungszeit von InMotion Solutions für Teams, die zum ersten Mal eine CDN-Integration einrichten. Diese monatliche Beratungsstunde kann für die Überprüfung und Optimierung der CDN-Konfiguration genutzt werden.

Weiterführende Literatur: Optimierung der Netzwerklatenz für dedizierte Server | Überwachung von Serverressourcen und Leistungsoptimierung