Optimierung der Netzwerklatenz für dedizierte Server

Warum dedizierte Infrastruktur immer noch Probleme mit der Latenz hat

Shared Hosting bringt einen Virtualisierungsaufwand zusätzlich zu den Netzwerk-Hops mit sich. Dedizierte Server machen die Virtualisierung überflüssig, aber die Physik der Signalausbreitung bleibt bestehen. Licht bewegt sich mit etwa 200.000 km/s durch Glasfaserkabel, was bedeutet, dass eine Hin- und Rückreise von Los Angeles nach Amsterdam mathematisch auf etwa 90 ms begrenzt ist, bevor die Anwendungsverarbeitung beginnen kann.

Diese Grundvoraussetzung ist wichtig. Wenn deine Nutzer auf der ganzen Welt verteilt sind, dein dedizierter Server aber in einem einzigen Rechenzentrum steht, werden einige von ihnen immer diese Roundtrip-Verzögerung spüren. Das Ziel ist nicht, die Physik zu besiegen, sondern alle kontrollierbaren Variablen darüber hinaus zu minimieren.

Schritt 1: Die Wahl des Rechenzentrums hängt von der Latenz ab

Die meisten Teams suchen sich ein Rechenzentrum nach Preis oder Verfügbarkeit aus und versuchen dann monatelang, ein geografisches Problem zu lösen. Such dir dein Rechenzentrum danach aus, wo der Großteil deines Produktionsdatenverkehrs herkommt – und mach einen Vergleichstest, bevor du dich festlegst.

InMotion Hosting hat Rechenzentren in Los Angeles und Amsterdam, die den Datenverkehr in Nordamerika und Europa abdecken. Wenn deine Anwendung hauptsächlich für Nutzer an der Westküste der USA gedacht ist, bietet die Anlage in LA deutlich geringere Latenzzeiten als jede Alternative an der Ostküste. Europäische Nutzer profitieren von den Peering-Beziehungen des Standorts Amsterdam zu den wichtigsten europäischen Internetknotenpunkten.

Tools, die du vor Vertragsunterzeichnung nutzen solltest:

• mtr (My Traceroute): Zeigt die Latenz pro Hop und den Paketverlust in Echtzeit an, nicht nur die endgültige RTT-Ping-Zeit.
• traceroute: Zeigt dir den Weg zwischen deinem Testrechner und der IP-Adresse des Rechenzentrums.
• iPerf3: Misst die tatsächliche Bandbreite und den Jitter unter Last, nicht die theoretischen Maximalwerte.

Mach diese Tests von Rechnern aus, die sich dort befinden, wo deine Nutzer tatsächlich sind – nicht von deinem eigenen Büro aus. Laut den Netzwerkleistungsdaten Cloudflare kann die geografische Nähe zu einem großen Internetknotenpunkt die RTT um 30 bis 50 ms reduzieren, verglichen mit dem Routing über einen weit entfernten Hub.

Schritt 2: CDN-Integration macht die Entfernung egal

Ein CDN macht deinen Server nicht schneller – es sorgt dafür, dass die Leute deinen Server weniger oft aufrufen müssen. Statische Assets (CSS, JS, Bilder, Videos), die von einem Edge-Knoten in 10 ms Entfernung statt von deinem dedizierten Server in 80 ms Entfernung bereitgestellt werden, bringen bei jedem Seitenaufruf eine Zeitersparnis von 70 ms, multipliziert mit jedem Asset auf der Seite.

Für Leute, die dedizierte Server betreiben, gibt's bei der CDN-Integration meistens zwei Möglichkeiten:

Vollständiges CDN-Proxying: Der ganze Datenverkehr läuft über die CDN-Ebene. Sowohl CloudflareEnterprise-Tarif als auch Fastly unterstützen dieses Modell. Dein dedizierter Server kümmert sich nur um Cache-Fehler und dynamische Anfragen. Cloudflare , dass richtig konfigurierte CDN-Bereitstellungen die Auslastung des Ursprungsservers um 60 bis 90 % reduzieren.

Teilweise Auslagerung: Du leitest nur bestimmte Subdomains oder Asset-Pfade über das CDN um, während API-Endpunkte und authentifizierte Routen direkt zu deinem Server weitergeleitet werden. Dieses Modell erfordert mehr Konfigurationsaufwand, bietet dir jedoch eine detaillierte Kontrolle darüber, was zwischengespeichert wird und was immer den Ursprungsserver erreichen muss.

Für Anwendungen, bei denen es auf kurze Latenzzeiten ankommt, sind die CDN-Origin-Verbindungseinstellungen echt wichtig. Stell sicher, dass das CDN über HTTP/2 (oder HTTP/3, wenn das unterstützt wird) mit deinem Server verbunden ist – das Multiplexing verhindert, dass die Verbindung zwischen dem CDN-Edge und deinem Server blockiert wird.

Schritt 3: Linux-TCP-Stack-Optimierung auf deinem dedizierten Server

Hier bieten dir dedizierte Server etwas, was VPS-Umgebungen normalerweise nicht haben: die Möglichkeit, Kernel-Parameter zu ändern. Verbinde dich per SSH mit deinem Server und schau dir deine aktuelle TCP-Konfiguration an:

sysctl net.core.somaxconn

sysctl net.ipv4.tcp_max_syn_backlog

sysctl net.ipv4.tcp_congestion_control

Ein paar Einstellungen beeinflussen direkt die Anwendungslatenz bei gleichzeitiger Belastung:

TCP-Überlastungskontrollalgorithmus: Der Linux-Kernel nutzt standardmäßig Cubic für die Überlastungskontrolle. BBR (Bottleneck Bandwidth and Round-trip propagation time), entwickelt von Google, ist bei Verbindungen mit hoher Latenz und mäßigem Paketverlust deutlich besser als Cubic. So aktivierst du es:

echo „net.core.default_qdisc=fq” >> /etc/sysctl.conf

echo „net.ipv4.tcp_congestion_control=bbr” >> /etc/sysctl.conf

sysctl -p

TCP-Puffergrößen: Die Standard-Kernel-Puffergrößen wurden für eine andere Ära der Netzwerkgeschwindigkeiten festgelegt. Bei Verbindungen mit 1 Gbit/s+ werden zu kleine Puffer zu einer Durchsatzgrenze:

echo „net.core.rmem_max=134217728” >> /etc/sysctl.conf

echo „net.core.wmem_max=134217728” >> /etc/sysctl.conf

echo „net.ipv4.tcp_rmem=4096 87380 67108864” >> /etc/sysctl.conf

echo „net.ipv4.tcp_wmem=4096 65536 67108864” >> /etc/sysctl.conf

sysctl -p

TCP_NODELAY für APIs mit geringer Latenz: Wenn deine App eine API nutzt, bei der Latenz wichtiger ist als Durchsatz, schalte TCP_NODELAY auf der Socket-Ebene in deinem App-Code ein. Das deaktiviert den Nagle-Algorithmus, der kleine Pakete bündelt – das ist gut für Massenübertragungen, aber nicht so toll für Request-Response-APIs, bei denen jede Antwort sofort gesendet werden soll.

Schritt 4: Überprüfe, was du geändert hast

Optimierung ohne Messung ist nur Raten. Bevor du irgendwelche Einstellungen änderst, solltest du mit echten Zahlen eine Basis schaffen:

• Zeit bis zum ersten Byte (TTFB): Miss das von verschiedenen Orten aus mit WebPageTest. Versuch, für die Hauptnutzerregion unter 200 ms zu bleiben.
• Latenzzeiten von p95 und p99: Die durchschnittliche Latenzzeit verdeckt die Spitzen, über die sich die Nutzer eigentlich beschweren. Deine Überwachung muss Perzentile erfassen.
• Netzwerkschnittstellenstatistik: netstat -s | grep -i retransmit zeigt die Anzahl der TCP-Neuübertragungen an – hohe Zahlen deuten auf Paketverluste hin, die deine Latenzzeit erhöhen.

Mach die gleichen Tests nochmal, nachdem du die Änderungen gemacht hast. Bei unterkonfigurierten Servern kann man durch TCP-Optimierung allein oft eine Verbesserung der TTFB um 20 bis 40 ms erreichen. Studien zur Web-Performance zeigen immer wieder, dass jede Reduzierung der TTFB um 100 ms zu messbaren Verbesserungen der Konversionsraten bei E-Commerce-Anwendungen führt.

Schritt 5: Bandbreitenstufe und Burstability

Die dedizierten Server von InMotion kommen mit einer Burstable-Bandbreite von 10 Gbit/s. Für die meisten Aufgaben reicht das völlig aus. Für Anwendungen, die regelmäßig einen hohen Durchsatz brauchen – wie Videoübertragung, große Dateiübertragungen oder API-Antworten mit hoher Frequenz –, kann ein Upgrade auf garantierte unbegrenzte 10 Gbit/s verhindern, dass es bei Spitzenauslastung zu Bandbreitenkonflikten kommt, die deine Latenzwerte beeinträchtigen könnten.

Bandbreitensättigung führt zu Warteschlangen, und Warteschlangen sorgen für Verzögerungen. Wenn dein iftop oder nethogs eine konstante Auslastung nahe dem Spitzenwert anzeigt, ist die Bandbreitenstufe und nicht die TCP-Einstellungen die eigentliche Einschränkung.

Netzwerklatenz ist ein Thema für die Infrastrukturplanung, nicht für die Fehlerbehebung.

Die Teams, die dedizierte Server mit der geringsten Latenz betreiben, sehen die geografische Lage, die CDN-Konfiguration und die Kernel-Einstellungen als wichtige Infrastrukturentscheidungen und nicht als Nebensache. Sie suchen das richtige Rechenzentrum für ihre Nutzerverteilung aus, schieben statische Assets an den Rand und passen den Kernel an die Bandbreite an, für die sie bezahlen.

Die gute Nachricht: Mit einem gut konfigurierten dedizierten Server in den RechenzentrenInMotion Hostingin Los Angeles oder Amsterdam hast du die besten Voraussetzungen, um diese Ziele zu erreichen. Die Konfiguration kannst du ganz nach deinen Wünschen gestalten.

Weiterführende Literatur: Überwachung der Serverressourcen und Leistungsoptimierung | DDoS-Schutzstrategien für dedizierte Infrastruktur