Türkei (Türkisch)
Germany (German)
Worldwide (English)
Aktuelle WooCommerce-Empfehlungen nennen 256 MB oder mehr WordPress-Memory-Limit. Das ist nicht der gesamte Server-RAM, sondern ein Anwendungslimit.
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
WooCommerce Hosting/VPS anhand Checkout-Parallelität, PHP-Worker, HPOS, Action Scheduler, Object Cache, DB und NVMe wählen.
Aktuelle WooCommerce-Empfehlungen nennen 256 MB oder mehr WordPress-Memory-Limit. Das ist nicht der gesamte Server-RAM, sondern ein Anwendungslimit.
WooCommerce nutzt HPOS als skalierbare Order-Storage-Architektur; 2026 wurden deutliche Query-Reduktionen für HPOS-Order-APIs dokumentiert.
Ein Katalog mit 50.000 Produkten kann mit Cache leicht sein; ein 500-Produkt-Shop mit vielen gleichzeitigen Checkouts, Webhooks und Scheduled Actions deutlich schwerer.
Zu messen sind Peak-Dynamic-Requests, Cart/Checkout-Parallelität, PHP-FPM-Queue, DB-Latenz und Background-Action-Backlog.
Die 256-MB+-Empfehlung ist ein Anwendungslimit, nicht Server-RAM. Viele PHP-Worker plus MySQL, Redis und OS können 4 GB VPS trotzdem überfordern.
WP_MEMORY_LIMIT zu erhöhen erzeugt keinen physischen RAM, sondern ändert nur das erlaubte Limit.
Nicht cachebare Cart-, Checkout-, Account- und Admin-AJAX-Requests verbrauchen PHP-Worker. Sind alle belegt, entstehen Queues auch ohne 100% CPU. Bei Shared Hosting Worker-/Entry-Process-Limits beachten.
HPOS speichert Bestelldaten in dedizierten Tabellen statt posts/postmeta. Das verbessert Indizes und reduziert Contention, löst aber nicht schlechte Plugins, wenig RAM oder langsames Storage.
WooCommerce 10.7 reduzierte Query-Zahlen bei Order API und Checkout; mit Object Cache sind manche Effekte stärker. Aktuelle Version und HPOS-Kompatibilität gehören zum Sizing.
Renewals, Webhooks, E-Mail, Stock-Sync, Imports und Plugin-Jobs können sich in Scheduled Actions stauen. Viele pending/failed Actions erfordern Prüfung von Cron, WP-CLI und DB.
WooCommerce System Status zeigt completed/pending/failed Actions. Wächst die Queue dauerhaft, ist mehr RAM nicht automatisch die Lösung.
Gutes Hosting mit Cache, genügend PHP-Workern, Object Cache und schneller DB kann für kleine/mittlere Shops besser sein als eigener VPS.
VPS/VDS wird sinnvoll bei wiederholten Limits, Custom-Daemons/Queues, hoher Checkout-Parallelität oder mehr DB-/Cache-Kontrolle.
Kleiner optimierter Shop: gutes Hosting oder 2-4 vCPU/4-8 GB VPS. Mittlerer Shop: 4-8 vCPU/8-16 GB, Redis, NVMe. Kampagnenlast: 8+ starke Kerne, 16-32+ GB und ggf. separate DB/Managed-Stack.
wp wc status 2>/dev/null || truewp action-scheduler action list --status=pending --per-page=20 2>/dev/null || truefree -hmysqladmin status| Shop-Typ | Startansatz | Metrik |
|---|---|---|
| Klein/gecacht | Managed Hosting oder 2-4 vCPU | TTFB + PHP-Queue |
| Mittel aktiv | 4-8 vCPU / 8-16 GB | Checkout p95 + DB |
| Hohe Kampagnenlast | 8+ Kerne / 16-32+ GB | Worker + Action Scheduler + DB |
Mindestanforderungen nicht mit Produktionskapazität verwechseln. Peak-Workload, Backup, Wachstumsreserve, Ressourcenpolitik und Recovery-Plan gemeinsam bewerten.
Nein. Gutes Managed Hosting kann kleine/mittlere Shops tragen. VPS anhand gemessener Ressourcen- und Kontrollbedürfnisse wählen.
Für kleinen optimierten Shop möglich; viele PHP-Worker, MySQL, Redis und Background Jobs können schnell an die Grenze führen.
CPU, RAM, Storage, Netzwerk und Betrieb gemeinsam bewerten; ein größeres Paket ohne Engpassanalyse ist selten eine dauerhafte Lösung.