Türkei (Türkisch)
Germany (German)
Worldwide (English)
Tägliche Besucherzahl allein ist keine CPU/RAM-Sizing-Metrik. 100.000 Besuche können bei Cache-Content und WooCommerce völlig unterschiedliche Last erzeugen.
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
CPU/RAM für WordPress, WooCommerce, PHP und APIs anhand Parallelität, Worker, Cache, DB und Request-Kosten statt nur Besucherzahlen planen.
Tägliche Besucherzahl allein ist keine CPU/RAM-Sizing-Metrik. 100.000 Besuche können bei Cache-Content und WooCommerce völlig unterschiedliche Last erzeugen.
Richtiges Sizing berücksichtigt parallele Requests, Cache-Hit-Rate, Worker, RAM/CPU pro Request, DB-Kosten und Background Jobs.
Eine Million Monatsbesuche können leicht sein, wenn Traffic verteilt und 95% gecacht sind. Ein kleinerer Shop mit vielen dynamischen Checkouts in einer Minute kann deutlich härter sein.
Zuerst Peak Requests/s, aktive Nutzer, Worker-Queues und p95-Response messen.
Gesamt-RAM wird von OS, Webserver, DB-Buffer, Redis, PHP-FPM, Monitoring und Filesystem-Cache geteilt. Bei dauerhaftem Swap muss der Verbraucher identifiziert werden.
Wenn PHP-FPM-Worker 80-200 MB nutzen, können 20 Worker etwa 1,6-4 GB nur für PHP benötigen. Reale RSS-Werte der eigenen Anwendung messen.
free -hps --sort=-rss -eo pid,comm,rss,%mem | head -20vmstat 1 10Ein Request mit 20 ms CPU ist völlig anders als einer mit 400 ms. Formeln wie 10.000 Besucher = 4 Cores sind ohne Profiling/Loadtest unzuverlässig.
Single-Thread-Leistung ist ebenfalls wichtig. Mehr Kerne erhöhen Parallelität, beschleunigen aber nicht automatisch einen langsamen einzelnen Request.
Full-Page-Cache kann PHP/DB-Ausführung vermeiden und CPU/DB-Last stark senken. Redis reduziert Query-Wiederholungen, braucht aber RAM. CDN entlastet statische Bandbreite.
2 GB Hosting und 2 GB VPS sind nicht direkt vergleichbar. Hosting kann Dienste auslagern/optimieren, während VPS alles im selben RAM-Budget betreibt.
Die Werte sind keine Garantie, sondern Startpunkte: kleines gecachtes WordPress etwa 1-2 vCPU/2-4 GB, WooCommerce 2-4 vCPU/4-8 GB, dynamische/API-Workloads 4+ vCPU/8+ GB. Entscheidend ist Messung.
Keine unkontrollierte Last auf Produktion erzeugen. Staging/Wartungsfenster nutzen, reale Nutzerflüsse modellieren und Cache-Hit von Checkout/API trennen.
Ziel ist zu sehen, bei welcher Parallelität p95/p99 schlechter wird und welche Ressource sättigt, nicht nur wann der Server abstürzt.
VPS/VDS wird sinnvoll bei wiederholten Limits, Worker-Queues, Docker/Custom-Daemons oder mehr DB/Cache-Kontrolle. Ein einzelner CPU-Spike reicht nicht.
| Workload | Start-CPU | Start-RAM | Wichtigste Messung |
|---|---|---|---|
| Gecachtes WordPress | 1-2 vCPU | 2-4 GB | TTFB + Worker Queue |
| WooCommerce | 2-4 vCPU | 4-8 GB | Dynamic p95 + DB |
| API / Heavy PHP | 4+ vCPU | 8+ GB | CPU/Request + Parallelität |
Kaufentscheidungen nicht anhand eines einzelnen Benchmarks, Port-Labels oder CPU-Markennamens treffen. Tests zu verschiedenen Zeiten wiederholen, keine destruktiven Storage-Tests auf Produktionsdaten durchführen und Ressourcen-/Fair-Use-Policies schriftlich prüfen.
Allein aus Besucherzahl nicht berechenbar. Peak-Parallelität, Cache-Hit, Request-RAM und DB-Last messen.
Für eine kleine optimierte Seite als Start möglich; DB, Panel, Mail und Plugins teilen denselben RAM.
Software, Parallelität, Storage-/DB-Last und Zielregion angeben; Serverklasse nach realem Engpass statt nur RAM/Core wählen.