Leistung und Zuverlässigkeit

Steal-Time ist der Prozentsatz der Zeit, in der Ihre virtuelle CPU bereit war, aber der Hypervisor den physischen Kern jemand anderem gegeben hat. Sie erscheint als "st"-Spalte in top. Alles konstant über 2–3 % bedeutet, dass Sie um den Kern konkurrieren, und ist die übliche Ursache für unerklärliche Latenzspitzen auf einer Instanz mit gemeinsam genutzter vCPU.

In der Reihenfolge der Wahrscheinlichkeit: Speichererschöpfung mit Swap-Thrashing, Festplatten-IO-Sättigung, CPU-Steal-Time auf geteilten Kernen, eine unoptimierte Datenbank oder Netzwerklatenz zu Ihren Benutzern. Prüfen Sie zuerst free -h und die st-Spalte in top – zusammen identifizieren sie die Ursache in etwa achtzig Prozent der Fälle.

Innerhalb einer Metropole unter 5 ms. Innerhalb eines Kontinents 10–40 ms. Über den Atlantik 70–90 ms. Europa nach Asien 150–200 ms. Antipodale Routen 250–320 ms. Licht in Glasfasern bewegt sich mit etwa zwei Dritteln der Lichtgeschwindigkeit, und reale Pfade sind etwa 1,35-mal so lang wie die Großkreis-Distanz, also etwa 1 ms pro 100 km pro Richtung als Untergrenze.

Eine gut konfigurierte Instanz mit 2 vCPU / 4 GB bedient eine statische Website mit Millionen monatlicher Besuche, eine gecachte WordPress-Website mit etwa 300.000 und eine ungecachte dynamische Anwendung mit vielleicht 30.000. Die dominante Variable ist Caching, nicht Hardware – dieselbe Instanz unterscheidet sich um zwei Größenordnungen je nachdem.

Messen Sie die drei Dinge, die tatsächlich variieren: Single-Thread-CPU mit sysbench, Festplatte mit fio bei 4K-Zufallslesen/-schreiben und Netzwerk mit iperf3 zu einem bekannten Endpunkt. Führen Sie jeden Test mehrere Male zu verschiedenen Stunden durch – ein einzelner Benchmark misst diese Minute, nicht den Server.

Etwa fünfmal so viele Zufalls-IOPS – ungefähr 500.000 gegenüber 90.000 – und etwa fünfmal geringere Latenz, unter 0,1 ms gegenüber etwa 0,5 ms. Der sequenzielle Durchsatz ist sechs- bis zehnmal höher. Für datenbankgestützte Anwendungen ist die Zufalls-IOPS-Lücke diejenige, die Sie tatsächlich spüren.

Unser SLA beträgt 99,99 % pro Instanz, was etwa 4,4 Minuten Ausfall pro Monat erlaubt; die beobachtete Verfügbarkeit über die gesamte Flotte lag in den letzten zwölf Monaten bei 99,993 %. Alles darüber hinaus erfordert Redundanz, die Sie selbst aufbauen müssen – eine einzelne Maschine, so gut sie auch sein mag, ist ein einzelner Fehlerpunkt.

Indirekt und messbar. Suchmaschinen bewerten nicht nach Serverland, aber sie messen die Seitengeschwindigkeit, und Distanz ist Latenz. Ein Server, der 200 ms von Ihren Nutzern entfernt ist, kostet echten Core-Web-Vitals-Punktwert. Verwenden Sie ein CDN, wenn Ihr Publikum global ist; platzieren Sie den Ursprung nahe Ihrem Publikum, wenn es regional ist.

DDoS-Schutz filtert Angriffsverkehr vorgelagert zu Ihrem Server, sodass legitime Anfragen weiterhin ankommen. Er muss dauerhaft aktiv sein, um nützlich zu sein – eine Abschwächung, die erst nach Beginn eines Angriffs aktiviert wird, hat Sie bereits ausfallen lassen. OnionVPS beinhaltet bis zu 12 Tbit/s L3/L4-Abschöpfung auf jeder Stufe, einschließlich des $4-Plans.

Die Isolierung ist stark: KVM erzwingt Trennung in Hardware, und das Entkommen ist ein ernsthaftes Forschungsniveau-Exploit. Das realistische Risiko ist nicht der Hypervisor – es ist Ihre Konfiguration. Passwort-SSH, ungepatchte Software und ein vergessener offener Dienst machen praktisch alle realen Kompromittierungen aus.

Eine geteilte vCPU wird gegen andere Mandanten geplant, sodass Ihr Prozess bei Auslastung wartet – sichtbar als Steal Time. Eine dedizierte vCPU ist ein physischer Thread, der für Sie reserviert ist, auf dem nichts anderes geplant ist. Geteilt ist für die meiste Zeit im Leerlauf befindliche Arbeit in Ordnung; dediziert ist für alles mit einer Latenzanforderung notwendig.