Türkei (Türkisch)
Germany (German)
Worldwide (English)
Kataloggröße
Mehr Produkte und Varianten vergrößern Indizes, Such-/Filterarbeit, Imports und Datenbankvolumen.
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
CPU-, RAM- und NVMe-Bedarf aus Kataloggröße, Traffic, Bestellungen und Kampagnenspitzen berechnen.
Monatlicher Traffic allein reicht nicht. Kataloggröße, Bestelllast, Lastspitzen, Integrationen und Cache-Architektur werden gemeinsam bewertet.
Das Ergebnis ist eine Startdimensionierung vor dem Kauf. Produktionskapazität muss mit Lasttests und Messwerten wie p95-Latenz, PHP-Worker-Auslastung, RAM-Spitzen, Datenbankabfragen und Queue-Tiefe validiert werden.
Paketpreise können sich ändern; der Rechner fixiert daher keine Preise. Aktuelle Preise finden Sie auf der VPS-Seite.
WooCommerce und andere Shopsysteme veröffentlichen keine offizielle Tabelle „X CPU / Y GB RAM“ nach Produktanzahl. Der Rechner beginnt daher mit unterstützten Software-Baselines und addiert Kapazität für Katalog, dynamischen Checkout-Traffic, Integrationen und Spitzenlast.
Mehr Produkte und Varianten vergrößern Indizes, Such-/Filterarbeit, Imports und Datenbankvolumen.
Warenkorb, Checkout und Konto sind kundenspezifisch und profitieren nicht von generischem Full-Page-Caching.
Bestellungen, E-Mails, Webhooks, Bestandssync, Feeds und Queues können bei Kampagnen gleichzeitig Ressourcen belegen.
Monatsdurchschnitte verstecken die stärkste Stunde; Kampagnenspitzen werden separat modelliert.
Ziel ist nicht 100% Dauerauslastung, sondern Reserve für Lastspitzen.
Die aktuellen WooCommerce-Empfehlungen nennen WordPress 6.9+, PHP 8.3+, MySQL 8.0+ oder MariaDB 10.6+, HTTPS und mindestens 256 MB WordPress Memory Limit. Das sind unterstützte Software-Baselines, keine Kapazitätsgarantie.
Aktuelle WooCommerce-Empfehlung
Moderne unterstützte Basis
WordPress-Limit pro PHP-Prozess, nicht gesamter VPS-RAM
Grundlage für sichere Sitzungen und Checkout
Der WooCommerce-Hosting-Leitfaden 2026 hebt dedizierte PHP-Worker hervor und nennt 5–10 dedizierte Worker als sinnvollen Startpunkt. Die tatsächliche Zahl muss am realen Speicherbedarf von Theme, Plugins und Requests gemessen werden.
WooCommerce empfiehlt, Cart, Checkout und My Account wegen kundenspezifischer dynamischer Daten vom Full-Page-Cache auszunehmen.
Object Caching kann wiederholte Datenbankzugriffe reduzieren; ein CDN entlastet den Origin bei statischen Assets und cachebaren Antworten.
HPOS ist seit WooCommerce 8.2 bei neuen Installationen standardmäßig aktiv und verwendet eigene Bestelltabellen für ein skalierbareres Datenmodell.
Große Imports, häufige Bestands-/Preissynchronisierung, Feeds und Marketplace-APIs erzeugen CPU-, RAM-, I/O- und Queue-Last, die reine Traffic-Zahlen nicht zeigen.
Keine festen Regeln, sondern Beispiele für das Kapazitätsmodell des Rechners.
| Szenario | Katalog | Traffic | Bestellungen | Startziel |
|---|---|---|---|---|
| Kleines WooCommerce | ≤ 1.000 Produkte | ≤ 50 Tsd./Monat | ≤ 100/Tag | 4 vCPU · 4–6 GB RAM |
| Wachsender Shop | 10–50 Tsd. Produkte | 50–250 Tsd./Monat | 100–500/Tag | 4 vCPU · 8–12 GB RAM |
| Starker Onlineshop | 50 Tsd.+ Produkte | 250 Tsd.+/Monat | 500+/Tag | 8+ vCPU · 16–32+ GB RAM |
| Kampagne / ERP-intensiv | Groß, viele Varianten | 4×–8× Peak | hoch | 8–12+ vCPU · 32–64+ GB RAM |
Kategorie → Produkt → Warenkorb → Checkout testen, nicht nur die Startseite.
Gleichzeitige Sessions und Request-Rate der Kampagnenspitze statt Monatsdurchschnitt annähern.
p95-Latenz, 5xx, Timeouts und Checkout-Fehler gemeinsam überwachen.
Aktive Worker, Queue-Wartezeit und lang laufende Requests messen.
Slow Queries, Locks, Buffer-Verhalten und Disk-I/O prüfen, nicht nur CPU.
Wenn normale Peak-Last CPU/RAM vollständig belegt, fehlt Reserve für die nächste Kampagne.
Die Kapazitätsformel ist ein Planungsmodell von Eka Sunucu. Softwareversionen und Plattformverhalten basieren auf den folgenden offiziellen Quellen.
Es gibt keinen universellen Wert. Theme/Plugins, Produktanzahl, gleichzeitige Nutzer, PHP-Worker, Datenbanklast und Cache-Architektur sind gemeinsam entscheidend. 4 GB können für einen kleinen Produktionsshop ein praktischer Startpunkt sein; größere Shops müssen per Lasttest dimensioniert werden.
Bei optimierten Katalogen kann es funktionieren, aber Varianten, Filter, XML-Sync, schwere Plugins und Checkout-Traffic können die Reserve schnell aufbrauchen. Produktzahl allein reicht für die Planung nicht.
Nein. Ein persistenter Object Cache kann bei dynamischen, datenbankintensiven Shops helfen, ersetzt aber keine guten Queries, korrekte Cache-Regeln oder ausreichende PHP-Kapazität.
Nicht als generischer Full-Page-Cache. WooCommerce empfiehlt, Cart, Checkout und My Account wegen kundenspezifischer dynamischer Inhalte auszunehmen.
Kleine Shops können auf hochwertigem Managed Hosting starten. Wenn PHP-Worker-Limits, Ressourcenlimits, Imports, Cron/Queue oder Kampagnen-Peaks zum Engpass werden, bietet ein VPS isoliertere Ressourcen und mehr Kontrolle.
Nein. Es grenzt die Startkapazität ein. Produktionsdimensionierung muss per Lasttest und Monitoring validiert werden, da Code, Plugins, Queries, Cache-Hit-Rate und externe APIs die Leistung stark verändern.
CPU-, RAM- und NVMe-Ziel aus dem Rechner übernehmen und aktuelle Eka-Sunucu-VPS-Pakete vergleichen. Bei großen Katalogen, ERP-Sync oder Kampagnen-Peaks helfen wir bei der Validierung.