Ein Shop, der im Alltag schnell reagiert, kann unter Kampagnenlast plötzlich zur Umsatzbremse werden. Die Frage „Welche Servergröße braucht mein Shop?“ entscheidet deshalb nicht über eine abstrakte CPU- oder RAM-Zahl, sondern über Ladezeiten, Conversion, Verfügbarkeit und die Handlungsfähigkeit Ihres Teams. Wer zu klein plant, riskiert Timeouts beim Checkout. Wer pauschal zu groß einkauft, bindet Budget, ohne die eigentlichen Engpässe zu lösen.
Die passende Servergröße entsteht aus dem Zusammenspiel von Shopsoftware, Datenmenge, Besucherverhalten und Betriebsanforderungen. Besonders bei Shopware-Projekten genügt es nicht, nur monatliche Besucherzahlen anzusehen. Relevant ist, was gleichzeitig passiert: Wie viele Menschen suchen, filtern, Warenkörbe aktualisieren oder Bestellungen abschließen? Und welche Prozesse laufen parallel im Hintergrund?
Welche Servergröße braucht mein Shop bei realer Last?
Die monatliche Besucherzahl ist ein grober Orientierungswert, aber keine belastbare Planungsgrundlage. 100.000 Besuche im Monat können gleichmäßig verteilt und technisch gut beherrschbar sein. Sie können sich aber auch auf wenige Stunden am Black Friday, nach einem Newsletter oder während einer TV-Kampagne konzentrieren. Für die Serverplanung zählt die Spitzenlast, nicht der Monatsdurchschnitt.
Ein weiterer Unterschied: Nicht jeder Seitenaufruf belastet die Infrastruktur gleich. Eine zwischengespeicherte Kategorieseite lässt sich oft schnell über nginx, Cache und CDN ausliefern. Eine personalisierte Suche, die Bestandsprüfung im Warenkorb oder ein Checkout mit Zahlungsanbieter erzeugen dagegen dynamische Anfragen. Sie benötigen Rechenleistung, Datenbankzugriffe und kurze Antwortzeiten - genau dann, wenn Kaufabsicht besteht.
Für eine belastbare Einschätzung betrachten wir daher mindestens vier Werte:
- gleichzeitige aktive Nutzer und erwartete Peaks
- Anzahl der Artikel, Varianten, Kategorien und Medien
- Anteil dynamischer Funktionen wie Suche, Filter, Kundenkonto und B2B-Preise
- Hintergrundprozesse wie Importe, Bildverarbeitung, Indexierung und ERP-Anbindung
Hinzu kommen externe Integrationen. Ein Shop mit wenigen tausend Artikeln kann mehr Ressourcen benötigen als ein größerer Katalog, wenn er Bestände in Echtzeit abgleicht, individuelle Preise berechnet oder mehrere Marktplätze bedient. Infrastruktur muss das Geschäftsmodell abbilden, nicht nur die Größe der Produktdatenbank.
Die Komponenten hinter der Servergröße
Eine Servergröße besteht nicht nur aus vCPU und Arbeitsspeicher. Für den Shopbetrieb müssen Webserver, PHP, Datenbank, Suchindex, Cache und Speicher-I/O zusammenpassen. Ein starker Prozessor hilft wenig, wenn die Datenbank auf langsamen Storage wartet. Viel RAM löst keine Engpässe, wenn die Suche zu wenig Ressourcen erhält oder Hintergrundjobs den Webprozess blockieren.
CPU: entscheidend für dynamische Prozesse
CPU-Leistung wird vor allem bei nicht cachebaren Seiten gebraucht. Dazu zählen Warenkorb, Checkout, Logins, personalisierte Inhalte, Regelwerke und komplexe Filter. Auch PHP-Worker benötigen ausreichend Kapazität, damit Anfragen nicht in Warteschlangen laufen. Bei Shopware ist eine ausreichende Zahl leistungsfähiger Kerne häufig sinnvoller als viele langsamere Kerne, weil Antwortzeit und Parallelität direkt aufeinander wirken.
Für kleinere Shops mit überschaubarem Katalog und planbarem Traffic kann ein Managed vServer ein sinnvoller Einstieg sein. Steigen gleichzeitige Nutzer, Integrationen und dynamische Vorgänge deutlich an, braucht es reservierte Ressourcen und eine Architektur, die einzelne Lastbereiche voneinander trennt.
RAM: Platz für Datenbank, Cache und Prozesse
Arbeitsspeicher wirkt im E-Commerce direkt auf die Reaktionsfähigkeit. MariaDB profitiert davon, häufig benötigte Daten im Speicher zu halten. Redis beschleunigt Sessions, Caches und bestimmte Anwendungsdaten. Elasticsearch benötigt ebenfalls ausreichend RAM für Indexe und Abfragen. Fehlt dieser Spielraum, muss das System häufiger auf den Datenträger ausweichen - mit spürbaren Folgen für Time to First Byte und Suchgeschwindigkeit.
Als grobe Einordnung gilt: Ein einfacher Shop benötigt eine andere RAM-Planung als ein Shop mit umfangreichem Katalog, Variantenlogik, Elasticsearch und mehreren Schnittstellen. Eine konkrete GB-Zahl ohne Blick auf diese Dienste wäre unseriös. Entscheidend ist die Speicherverteilung im laufenden Betrieb, einschließlich Reserven für Peaks und Wartungsarbeiten.
NVMe-Speicher: oft unterschätzt, im Alltag spürbar
Produktbilder, Datenbankabfragen, Suchindexe, Logs und Backups erzeugen laufend I/O-Last. NVMe-Speicher verkürzt Zugriffszeiten gegenüber klassischen Speicherlösungen deutlich und ist für datenbankintensive Shops ein relevanter Baustein. Dabei zählt nicht allein die Kapazität. Auch IOPS, Latenz und die Frage, welche Daten gleichzeitig verarbeitet werden, bestimmen die Wirkung.
Gerade während Importen oder Reindexierungen zeigt sich, ob Speicherleistung ausreichend eingeplant wurde. Läuft ein großer Produktimport zur gleichen Zeit wie eine Kampagne, darf der Shop nicht für echte Kunden langsam werden.
Shopware richtig dimensionieren
Shopware verbindet Frontend, Administration, Regelwerk, Suche, Caching und Hintergrundprozesse in einer anspruchsvollen Anwendung. Der Ressourcenbedarf wächst nicht linear mit der Artikelzahl. Viele Varianten, individuelle Erlebniswelten, mehrere Sales Channels, Sprachen oder kundenspezifische Preislogiken erhöhen die Komplexität überproportional.
Für einen Shopware-Shop sollte der Betrieb deshalb getrennt betrachtet werden: Webanfragen, Datenbank, Redis und Elasticsearch haben unterschiedliche Lastprofile. Bei kleineren Installationen können diese Dienste gemeinsam auf einer leistungsfähigen Umgebung laufen. Bei wachsenden Projekten ist die Trennung sinnvoll, damit etwa eine intensive Suche nicht den Checkout ausbremst.
Auch die Administration gehört in die Planung. Redakteure importieren Produkte, aktualisieren Kategorien oder erzeugen Medien, während Kunden bestellen. Wenn solche Aufgaben keine reservierten Ressourcen erhalten, entsteht ein Konflikt im Livebetrieb. Eine passende Umgebung schützt nicht nur die Shopseite, sondern auch die Arbeitsprozesse dahinter.
Von der Startgröße zur skalierbaren Architektur
Eine Startkonfiguration muss nicht jede denkbare Last dauerhaft vorhalten. Sie sollte jedoch so geplant sein, dass sie ohne riskante Umzüge und ohne Downtime wachsen kann. Das bedeutet: Reserven einplanen, Engpässe messbar machen und Skalierungswege vorab festlegen.
Bei mittleren bis hohen Anforderungen ist vertikale Skalierung häufig der erste Schritt: mehr CPU, RAM oder schnellerer Speicher. Sie ist unkompliziert, hat aber Grenzen. Bei umsatzkritischen Shops kommen zusätzliche Webknoten, ein Load Balancer, getrennte Datenbankressourcen, CDN, WAF und hochverfügbare Komponenten hinzu. Das ist kein Selbstzweck. Es reduziert das Risiko, dass ein einzelner Engpass den Verkauf stoppt.
Eine Zielverfügbarkeit von mindestens 99,9 Prozent und ein TTFB unter 200 Millisekunden sind sinnvolle Betriebsziele, sofern Anwendung, Caching und externe Dienste mitziehen. Verfügbarkeit entsteht nicht allein durch Servergröße. Sie braucht Monitoring, getestete Backups, Sicherheitsupdates, Alarmierung und einen klaren Ansprechpartner, der im Störungsfall Verantwortung übernimmt.
Messen statt raten: Diese Signale zeigen Handlungsbedarf
Eine neue Servergröße sollte auf Messwerten beruhen. Dauerhaft hohe CPU-Auslastung, zunehmende Datenbanklaufzeiten oder Swap-Nutzung sind klare Warnzeichen. Ebenso relevant sind Warteschlangen bei PHP-Prozessen, langsame Elasticsearch-Abfragen und steigende Antwortzeiten unter Last.
Nicht jede kurzfristige Spitze ist ein Problem. Eine Infrastruktur darf arbeiten. Kritisch wird es, wenn die Antwortzeiten bei wiederkehrenden Peaks steigen, Checkout-Anfragen fehlschlagen oder Redaktions- und Importprozesse den Verkauf beeinträchtigen. Dann ist nicht immer sofort ein größerer Server die Lösung. Möglicherweise fehlen Cache-Regeln, Datenbankoptimierungen oder eine Entkopplung von Hintergrundjobs.
Genau hier trennt sich Tarifdenken von Infrastrukturplanung. Hostingwerft betrachtet Anwendung, Lastprofil und Betriebsziel gemeinsam - damit Investitionen dort erfolgen, wo sie Verfügbarkeit und Performance tatsächlich verbessern.
Die sinnvollste nächste Frage lautet daher nicht: „Wie viele Kerne brauche ich?“ Sondern: „Welche Last muss mein Shop auch im wichtigsten Verkaufsfenster zuverlässig tragen?“ Wenn diese Antwort mit realen Daten, geplanten Kampagnen und Wachstumsszenarien unterlegt ist, wird aus Servergröße eine planbare Grundlage für Ihren Umsatz.