VPS-Ressourcenrechner

Nicht der Paketname, sondern das Verhalten der Last

Bei der VPS-Auswahl verführt der Name des Pakets leicht. „Basic“, „standard“, „premium“, „general purpose“… Sie klingen gut. Aber keiner dieser Namen sagt allein aus, wie viel RAM die Website fressen wird, wann sie die CPU ersticken oder an welchem Tag die Festplatte voll sein wird.

Eine statische Website und ein WooCommerce-Shop brauchen selbst bei gleicher Besucherzahl nicht denselben Server. Bei der einen werden fertige Dateien ausgeliefert; bei der anderen gibt es Warenkorb, Zahlung, Lagerbestand, Benutzersitzungen, Datenbankabfragen, Admin-Panel und manchmal auch Hintergrundwarteschlangen, die im Hintergrund laufen. Genau hier liegt der Unterschied.

Dieses Berechnungsmodell betrachtet den VPS über vier Hauptressourcen: vCPU, RAM, Festplatte und monatlicher Traffic. Aber es behandelt sie nicht als nackte Zahlen; es bewertet sie zusammen mit Anwendungstyp, Umgebungsstufe, Cache/CDN-Nutzung, laufenden Diensten auf demselben VPS, Logs, lokalen Backups und Wachstumspuffer.

Es gibt keine einzige „offizielle VPS-Formel“. Auch in den Dokumentationen großer Cloud-Anbieter wird das so angegangen: CPU, Speicher, Netzwerk und Storage werden zusammen betrachtet; Maschinenfamilien werden nach Workload unterschieden. Allgemeine Maschinen verhalten sich anders als compute-optimierte oder memory-optimierte. Auf der VPS-Seite gilt dieselbe Logik, nur in kleinerem Maßstab.

flowchart LR
  A["Uygulama tipi"] --> E["Kaynak tahmini"]
  B["Trafik ve cache"] --> E
  C["Veritabanı, worker, panel, Docker"] --> E
  D["Disk, log, yedek, büyüme payı"] --> E
  E --> F["vCPU"]
  E --> G["RAM"]
  E --> H["Disk"]
  E --> I["Aylık trafik"]

Der Satz, den ich bei solchen Berechnungen am meisten nicht mag, ist: „2 vCPU reichen.“ Wofür reichen sie? Für eine statische Website, für WooCommerce, für Odoo, für eine Node-API oder für eine gemischte Installation mit MySQL, Redis, Mail und Docker auf derselben Kiste?

Außerdem wird der Unterschied zwischen gemeinsam genutzter und dedizierter CPU übersehen. Bei kleinen VPS-Plänen wird die CPU oft geteilt. Für leichte Websites mag das kein Problem sein. Aber bei Systemen, die regelmäßig Worker laufen lassen, Spitzenverkehr bekommen, Berichte erzeugen oder die Datenbank stark beanspruchen, kann dieselbe vCPU-Zahl schwächer wirken als erwartet.

Daher ist das Ergebnis hier kein „finaler Plan“, sondern eine sichere Startschätzung. Es liefert ein gutes erstes Bild für die Ressourcenauswahl. In der Produktion haben letztlich die Metriken das letzte Wort: CPU-Auslastung, RAM-Verbrauch, Festplattenbelegung, Netzwerkverkehr, langsame Abfragen, Fehlerprotokolle, Worker-Warteschlange.

Das Papier ist das eine, der Server das andere.

Wo beginnen wir?

Die erste Unterscheidung in der Berechnung kommt vom Anwendungstyp. Denn nicht jede Anwendungsklasse hat dieselbe Grundlast.

Eine statische Website steht auf der leichtesten Seite. Als Basis-CPU wird 1 vCPU angenommen, als Basis-RAM 1 GB; der CPU-Faktor wird niedrig gehalten, bei 0.2. Das ist sinnvoll. Denn bei einer gut gecachten statischen Website liefert der Server die meiste Zeit fertige Dateien aus, die Anwendungsschicht arbeitet kaum.

Für WordPress / Blog steigt der Startwert: Basis-CPU 1.5 vCPU, Basis-RAM 2 GB, CPU-Faktor 1. WordPress hat eine PHP- und Datenbankbasis. Mit Theme, Plugins, Bildverarbeitung, Admin-Aktionen, Suche und Kommentaren verhält es sich nicht wie eine statische Website. Allerdings kann es mit sauberem Cache erheblich entlastet werden.

WooCommerce / E-Commerce ist eine andere Klasse. In diesem Modell werden Basis-CPU 2.5 vCPU, Basis-RAM 4 GB und CPU-Faktor 2 angenommen. Meiner Meinung nach ist diese Unterscheidung für E-Commerce unerlässlich. Denn WooCommerce legt auf WordPress Warenkorb, Zahlung, Bestellung, Lagerbestand und Mitgliedschaftsebene. Außerdem sind einige Seiten nicht vollständig cachefähig. Die Produktseite kann aus dem Cache kommen, aber bei Warenkorb und Zahlung ändert sich das Spiel.

Für Laravel / PHP-Anwendung und Node.js / API gelten Basis-CPU 2 vCPU, Basis-RAM 3 GB, CPU-Faktor 1.2. Hier hängt der tatsächliche Bedarf stark vom Code ab. Eine einfache API kann sehr leicht laufen; eine Anwendung, die mit externen Diensten spricht, ständig Daten verarbeitet und Warteschlangen nutzt, kann in derselben Klasse deutlich schwerer sein.

Für kleine SaaS gelten Basis-CPU 3 vCPU, Basis-RAM 4 GB, CPU-Faktor 1.8. Benutzersitzungen, Hintergrundjobs, Benachrichtigungen, Berichte und Datenbankverkehr kommen meist zusammen. Die Besucherzahl mag gering erscheinen, aber es gibt viele In-App-Operationen. Wenn man es wie eine Website betrachtet, wählt man das falsche Paket.

Odoo / ERP-ähnliche Systeme sind auf der schweren Seite: Basis-CPU 4 vCPU, Basis-RAM 8 GB, CPU-Faktor 3. Bei Odoo-Installationen werden Worker- und Speicherplanung ohnehin separat betrachtet. Berichte, Benutzersitzungen, Module, Datenbankoperationen und lang laufende Aufgaben unterscheiden diese Klasse von einer normalen Blog-Website.

Für Game-Server gelten Basis-CPU 3 vCPU, Basis-RAM 4 GB, CPU-Faktor 2.5; für Bot / Worker werden Basis-CPU 2 vCPU, Basis-RAM 2 GB, CPU-Faktor 1.5 angenommen. Besonders bei Worker-Aufgaben kann die Besucherzahl irreführend sein. Selbst wenn niemand die Website betritt, werden im Hintergrund Daten verarbeitet.

Die Umgebungswahl wird wie ein Faktor auf den Basiswert aufgeschlagen. Test / Hobby-Umgebung wird mit 0.75, kleine Produktion mit 1, Produktion mit 1.25 und Vorbereitung auf hohe Verfügbarkeit mit 1.6 berücksichtigt. „Vorbereitung auf hohe Verfügbarkeit“ bedeutet nicht, dass ein einzelner VPS jetzt HA ist; es bedeutet nur, eine großzügigere Ressourcenreserve zu lassen. Echte HA erfordert eine eigene Architektur.

Der Wachstumspuffer kommt ganz am Ende dazu. Standardmäßig 30 Prozent. Ich halte das für vernünftig. Ein guter Bereich, um ein Wachstum von 3–6 Monaten abzudecken. Man könnte 300 Prozent eintragen, aber wenn ein solches Wachstum nicht wirklich erwartet wird, wird die Rechnung zur Angst-Rechnung.

Traffic-Berechnung: Der Monatsdurchschnitt täuscht ein wenig

Die monatliche Besucherzahl ist die erste Kennzahl, die man ansieht, aber für die endgültige Entscheidung ist sie schwach. Zwei Websites mit 100.000 Besuchern können nicht dieselbe Last erzeugen. Die eine zeigt 1,5 Seiten pro Besucher bei 1 MB Seitengröße, und der CDN funktioniert gut. Die andere zeigt 4 Seiten pro Besucher bei 3 MB Seitengröße und hat viele dynamische Bereiche. Gleiche Besucher, völlig andere Serverlast.

Die Verkehrsberechnung betrachtet Besucherzahl, Seiten/Sitzungen und durchschnittliche Seitengröße zusammen. Dann wird der Cache-Effekt abgezogen, der Wachstumspuffer addiert und das Ergebnis in GB umgerechnet. Der Endwert wird auf 50-GB-Stufen gerundet; selbst in sehr kleinen Szenarien werden mindestens 50 GB Traffic angezeigt.

Die Annahmen auf der Cache-Seite sind: ohne Cache beträgt die Ersparnis 0, Basis-Cache 35 Prozent, Seiten- + Objekt-Cache 60 Prozent, CDN + starker Cache 75 Prozent. Das sind keine offiziellen Garantiewerte. Bei NGINX-Cache oder CDN wird erwartet, dass die Last auf dem Ursprungsserver sinkt; die tatsächliche Ersparnis hängt jedoch von der Cache-Trefferquote, der Seitenstruktur und den dynamischen Bereichen ab.

Besonders bei WooCommerce ist das zu beachten. Nur weil ein CDN da ist, werden Warenkorb- und Zahlungsseite nicht plötzlich kostenlos. Bei personalisierten Inhalten, Sitzungen, Admin-Aktionen, Zahlungsabläufen und Lagerbestandskontrolle ist der Cache begrenzter. Cache ist eine gute Bremse; er ersetzt nicht den Motor.

Der Spitzenstunden-Faktor kommt noch hinzu. Monatlicher Traffic ist nicht gleichmäßig verteilt. Kampagnentag, Newsletter, Social-Media-Beitrag, plötzliche Peaks bei Nachrichtenseiten … Während der Durchschnitt ruhig aussieht, kann der Server für eine Stunde schwitzen. In dieser Berechnung wird der Spitzen-RPS ungefähr ermittelt, indem monatliche Besucher × Seiten/Sitzung × Spitzenstunden-Faktor durch die Anzahl der Sekunden von 30 Tagen geteilt wird. 30 Tage sind 2.592.000 Sekunden.

Der Einfluss des Traffics auf die CPU ist noch interessanter. Die Besucherzahl wird ins Verhältnis zu 50.000 gesetzt, mit dem CPU-Faktor multipliziert, der Spitzenstunden-Faktor addiert und die Hälfte des Cache-Effekts auf der CPU-Seite abgezogen. Das heißt: Cache reduziert den Traffic deutlich, aber der CPU-Effekt wird vorsichtiger reduziert. Ich halte das für den richtigen Ansatz; denn nicht jede Anfrage kommt aus dem Cache.

Im Test mit einer statisch gecachten Website bleiben bei 100.000 monatlichen Besuchern, 1,5 Seiten/Sitzung, 1 MB Seitengröße, Spitzenstunden-Faktor 2, CDN + starkem Cache und 20 Prozent Wachstumspuffer das Ergebnis bei 1 vCPU, 2 GB RAM, 40 GB Festplatte und 50 GB monatlichem Traffic. Es gibt Traffic, aber die Last ist gering.

Im E-Commerce-Beispiel gibt es diesen Komfort nicht. Bei 200.000 monatlichen Besuchern, 4 Seiten/Sitzung, durchschnittlich 3 MB Seitengröße, Spitzenstunden-Faktor 5, Seiten- + Objekt-Cache und 50 Prozent Wachstumspuffer steigt der monatliche Traffic auf 1450 GB. Die CPU-Empfehlung liegt bei 32 vCPU. Das mag auf den ersten Blick hoch erscheinen; aber wenn man die Zahlen übereinanderlegt, wird das Bild härter: mehr Besucher, mehr Seiten, größere Seiten, schwerere Workloads, höherer Peak.

Die Seitengröße ist ein eigenes Problem. Zu sagen „Die Website ist leicht“ reicht nicht, man muss es messen. Große Bilder, Schriften, Drittanbieter-Skripte, Werbecodes, Analytics-Tags, unnötige JS-Dateien blähen den Traffic auf. Dass sie im Browser schnell lädt, bedeutet nicht, dass die Datenübertragung gering ist.

Wer läuft auf derselben Kiste?

Bei kleinen VPS entsteht der eigentliche Kampf oft hier. Der Webserver steht nicht allein. MySQL ist auch da, Redis auch, das Panel auch, vielleicht noch der Mail-Dienst. Wenn dann noch Docker-Container und Worker-Prozesse dazukommen, wird es eng für 2 GB RAM.

Wenn die Datenbank auf demselben VPS liegt, kommt eine RAM-Zusatzlast in das Modell. Die Datenbankgröße wird durch 20 geteilt; das Ergebnis wird auf mindestens 1 GB und höchstens 8 GB begrenzt. Zum Beispiel werden selbst für eine 5-GB-Datenbank 1 GB RAM reserviert. Für eine 30-GB-Datenbank entsteht eine Zusatzlast von etwa 1,5 GB. Auf der CPU-Seite werden für die Datenbank 0,5 vCPU hinzugefügt.

Diese Werte sind keine Datenbank-Tuning-Berechnung. Wenn die Indizes schlecht sind, Abfragen lang sind oder Tabellensperren auftreten, reichen 0,5 vCPU nicht. Aber für die erste Planung ist es besser, als die Datenbank als „Nullkosten“ zu betrachten.

Wenn Redis / Objekt-Cache auf demselben VPS liegt, kommen 0,5 GB RAM hinzu. Redis arbeitet im Speicher; wenn man das vergisst, sieht man merkwürdige Verlangsamungen auf kleinen Servern. Es wurde eingerichtet, um die Cache-Leistung zu verbessern, ja, aber es selbst braucht auch RAM.

Es gibt drei Stufen des Verwaltungspanels: keines, leichtes Panel, vollwertiges Panel wie cPanel / Plesk. Ein leichtes Panel fügt 0,3 GB RAM und 0,15 vCPU hinzu. Ein vollwertiges Panel fügt 1 GB RAM und 0,3 vCPU hinzu. Es ist keine gute Idee, Systeme wie cPanel oder Plesk auf einem VPS mit 1 GB RAM zu installieren und dann Leistung von der Anwendung zu erwarten. Das Panel bietet Komfort; man bezahlt es mit Ressourcen.

Die Anzahl der Worker / Warteschlangen ist direkt wirksam. Für jeden Worker werden 0,5 GB RAM und 0,5 vCPU hinzugefügt. Das mag etwas hoch erscheinen, ist aber sinnvoll, wenn die Hintergrundarbeiten ernsthaft sind. Bildverarbeitung, Berichtserstellung, Datenabruf von externen APIs, E-Mail-Warteschlangen leeren, Aufgaben nach der Zahlung … Wenn der Worker nicht idle ist, braucht er Ressourcen.

Wenn der E-Mail-Dienst auf demselben VPS läuft, kommen 0,5 GB RAM und 0,3 vCPU hinzu. Abgesehen von den Ressourcen ist der Mail-Dienst auch operativ aufwendig. DNS, SPF, DKIM, DMARC, Spam, Warteschlange, Zustellbarkeit. Diese Berechnung sieht nur den Ressourcenanteil; sie berechnet keine Kopfschmerzen.

Für Docker / Container-Nutzung werden 0,5 GB RAM und 0,2 vCPU hinzugefügt. Docker bringt Ordnung, ist aber nicht kostenlos. Wenn Speicherlimit, Swap-Verhalten und CPU-Anteil von Docker nicht richtig eingestellt sind, kann ein einzelner Container die gesamte Maschine unter Druck setzen. „Wir haben Container gemacht, jetzt sind wir entspannt“ ist nicht immer der richtige Satz.

Der Kern der CPU-Berechnung ist: Es wird der größere Wert aus Basis-CPU und Traffic-CPU-Bedarf genommen, die Service-CPU-Lasten werden addiert und der Umgebungsfaktor sowie der Wachstumspuffer angewendet. Bei RAM werden Basis-RAM und Service-RAM addiert, wiederum mit Umgebung und Wachstumspuffer. Dann wird das Ergebnis auf praktische Paketstufen gerundet: bei CPU 1, 2, 4, 6, 8, 12, 16, 24, 32, 64; bei RAM 1, 2, 4, 8, 16, 32, 64, 128 GB.

Es gibt keine Welt mit Nachkommastellen. Wenn ein Bedarf von 5,3 GB RAM herauskommt, schaut man auf 8 GB. Bei 3,1 vCPU sind 4 vCPU sinnvoll. In der Produktionsumgebung führt eine millimetergenaue Berechnung dazu, dass man bei kleinen Schwankungen an die Wand gedrückt wird.

Bei der Festplatte sind es manchmal die unsichtbaren Dinge

Weil der Code-Ordner klein ist, hält man den Speicherbedarf für gering. Das ist ein häufiger Rechenfehler, den wir oft sehen. Die Anwendung hat 3 GB, Medien 10 GB; man sagt: „20 GB Festplatte reichen.“ Dann kommen Logs, Datenbank, lokales Backup, Systemdateien, Container-Images, temporäre Dateien.

Die Festplattenberechnung erfolgt mit Anwendungsdateien, Medien/Uploads, Datenbankgröße, täglichen Logs, Aufbewahrungstagen und lokalen Backup-Kopien. Wenn die Datenbank nicht auf demselben VPS liegt, fließt sie nicht in die Festplattenberechnung ein. Liegt sie auf demselben VPS, fließt sie ein.

Zuerst wird eine Zwischensumme der Festplatte gebildet: Anwendungsdateien + Mediendateien + (falls auf demselben VPS) Datenbank + tägliches Log × Aufbewahrungstage. Dann wird die Anzahl der lokalen Backup-Kopien berücksichtigt. Ein lokales Backup vergrößert den Datensatz ungefähr um das Doppelte. Dazu werden 15 GB Systemanteil addiert, 20 Prozent Sicherheitspuffer angewendet und der Wachstumspuffer hinzugefügt. Das Ergebnis wird auf 10-GB-Stufen gerundet und es werden mindestens 20 GB empfohlen.

15 GB Systemanteil sollte man nicht unterschätzen. Betriebssystem, Pakete, Update-Reste, temporäre Dateien, Dienstprotokolle, Docker-Images, temporäre Datenbankdateien nehmen dort Platz. In der Produktion ist die Festplatte nicht nur dein Upload-Ordner.

Logs sind auch heimtückisch. 0,5 GB Log pro Tag und 14 Tage Aufbewahrung ergeben 7 GB. 2 GB Log pro Tag und 30 Tage Aufbewahrung ergeben 60 GB. Sie wachsen leise. Die Festplatte übersteigt 80 Prozent, dann 90, dann kommt bei einem Deploy der berühmte Fehler: no space left on device.

Lokale Backups erfordern ebenfalls Aufmerksamkeit. Ein Backup auf derselben Festplatte ist im Katastrophenfall keine volle Sicherheit; wenn die Festplatte weg ist, ist auch das Backup weg. Aber für eine schnelle Wiederherstellung kann eine lokale Kopie nützlich sein. Das Modell bezieht das in die Ressourcenberechnung ein. Entscheidungen wie entferntes Backup, Objektspeicher, separater Backup-Server sollten separat geplant werden.

Im WordPress-Produktionstest werden bei 5 GB Anwendungsdateien, 10 GB Medien, 5 GB Datenbank, 0,5 GB täglichem Log, 14 Tagen Aufbewahrung, 1 lokalem Backup und 30 Prozent Wachstumspuffer 90 GB Festplatte empfohlen. Auf den ersten Blick zu viel. Aber wenn man Logs, Backup, Systemanteil und Sicherheitspuffer hinzufügt, ist es nicht zu viel, sondern eher vorsichtig.

Auf der E-Commerce-Seite wächst die Sache: 10 GB Anwendungsdateien, 80 GB Medien, 30 GB Datenbank, 2 GB tägliches Log, 30 Tage Aufbewahrung, 1 lokales Backup und 50 Prozent Wachstumspuffer. Die resultierende Festplatte beträgt 480 GB. Wenn Produktbilder, Bestelldaten, Logs und Backups auf derselben Kiste liegen, ist dieses Ergebnis nicht überraschend.

Bei der Festplatte zu sparen ist eine schlechte Angewohnheit. Wenn die CPU nicht reicht, sieht man Verlangsamung. Wenn der RAM nicht reicht, beginnt Swap. Wenn die Festplatte voll ist, können Dienste manchmal viel härter ausfallen: Die Datenbank kann nicht schreiben, Logs werden nicht erstellt, Sitzungsdateien können nicht geöffnet werden, Deploys bleiben unvollständig. Schlimmer noch, der Fehler erklärt sich nicht immer klar.

Beim Übersetzen des Ergebnisses in ein Paket

Die Ausgabe enthält vier Hauptwerte: CPU, RAM, Festplatte und monatlicher Traffic. Werfen Sie sie nicht in denselben Topf. Jeder zeigt eine andere Grenze.

CPU ist die momentane Rechenleistung. PHP-Anfrage, Node.js-API-Antwort, Datenbankabfrage, Worker-Aufgabe, Verarbeitung nach der Zahlung … Das alles berührt die CPU. Wenn der Traffic steigt, kann die CPU steigen; Cache kann das reduzieren, aber nicht vollständig entfernen.

RAM ist der Raum für laufende Dienste. MySQL, Redis, PHP-FPM, Node.js-Prozesse, Panel, Docker-Container, Mail-Dienst, Worker. Wenn der RAM knapp wird, kann das System in den Swap fallen. Es tut so, als würde es funktionieren, wird aber langsamer. Besonders bei dynamischen Anwendungen spürt man diesen Unterschied schnell.

Festplatte ist der dauerhafte Speicher. Anwendungsdateien, Medien, Datenbank, Logs, Backups und Systemdateien schauen dorthin. Bei der Festplattenberechnung sollte man nicht mit der heutigen Größe, sondern mit der Ansammlung in einigen Monaten denken.

Monatlicher Traffic ist der Datentransfer. CDN, Cache und Seitenoptimierung reduzieren ihn. Die Verkehrspolitik des Anbieters sollte separat geprüft werden: Gibt es ein Kontingent, eine Überschreitungsgebühr oder eine Geschwindigkeitsreduzierung? Die Berechnung liefert den GB-Bedarf; sie liefert nicht die kommerzielle Bedingung des Anbieters.

In diesem Modell werden die rohen Werte auf praktische Paketstufen gerundet. Wenn ein Rohbedarf von 3,4 vCPU besteht, werden 4 vCPU empfohlen. Bei 9 GB RAM kann man auf 16 GB gehen. Die Festplatte wird auf 10-GB-Stufen aufgerundet. Diese Rundung lässt das Ergebnis manchmal größer erscheinen, aber VPS-Pakete werden ohnehin nicht mit Nachkommastellen verkauft.

Und noch etwas: 4 vCPU verhalten sich nicht bei jedem Anbieter gleich wie 4 vCPU. CPU-Generation, gemeinsam genutzte/dedizierte Struktur, Virtualisierungsschicht, Festplattentyp, Netzwerkqualität, Nachbarmaschinen – all das macht einen Unterschied. In den Dokumenten zur Planauswahl von Anbietern wie DigitalOcean wird die Unterscheidung zwischen gemeinsam genutzter und dedizierter CPU nicht umsonst betont.

Daher sollte diese Berechnung wie eine technische Prüfung vor dem Kauf-Button betrachtet werden. Wenn Sie ein bestehendes System haben, legen Sie es neben echte Metriken: CPU-Grafik, RAM-Auslastung, Festplattenbelegung, Netzwerkausgang, langsame Abfragen, 5xx-Fehler, Warteschlangenwartezeit. Wenn Sie ein neues System aufsetzen, testen Sie ein paar Szenarien.

Was passiert ohne Cache? Wie stark sinkt der Traffic mit CDN? Entspannt sich der RAM, wenn man die Datenbank vom VPS trennt? Wohin geht die CPU, wenn die Anzahl der Worker von 0 auf 4 steigt? Wie stark vergrößert eine lokale Backup-Kopie die Festplatte?

Die Paketwahl ergibt sich manchmal aus den Antworten auf diese Fragen, nicht aus einer einzelnen Ergebniszeile.

Wenn ich es wäre, würde ich mir besonders drei Werte noch einmal ansehen: den Spitzenstunden-Faktor, ob die Datenbank auf demselben VPS liegt und die lokale Backup-Kopie. Denn im echten Leben bringen diese die Rechnung am meisten durcheinander. Der Traffic staut sich auf eine Stunde, MySQL braucht auf derselben Kiste mehr RAM als erwartet, Backups füllen die Festplatte. Dann ärgert man sich über das CPU-Paket.

Manchmal liegt die Schuld nicht an der CPU.