Vom „zähen“ Shop zur skalierbaren Performance – wie nuonic Digital neu durchstartet

Ich bin Alex, Gründer und Partner bei nuonic Digital. Wir sind eine E-Commerce-Agentur mit Standorten in Fürstenfeldbruck bei München und Hamburg. Seit 10 Jahren arbeiten wir mit Shopware, weshalb unser Fokus auf individueller Entwicklung mit Shopware 6 und modernen Technologien im E-Commerce liegt.

Eigentlich sind wir schon länger mittwald Kunde im Kundencenter. Doch im Oktober 2025 haben wir den ersten Server im mStudio gestartet und intensiv getestet.

Ausschlaggebend war damals ein Performance-Problem bei einem Kundenprojekt seitens des alten Hosters. Dem sind wir auf den Grund gegangen: Der Shopware-6-Shop lief auf einem vServer mit 2vCPU und 8 GB RAM. Auf den ersten Blick sah alles gut aus: geringe CPU-Last, nur etwa 51 % RAM-Auslastung. Das sah alles entspannt aus.

Die Prozesse wirkten weiterhin träge. Also haben wir genauer geschaut: 1,44 GB von 2 GB Swap waren belegt. Und das war das Problem: Der Server wirkte stabil, hat aber im Hintergrund massiv geswappt. OpenSearch, MySQL, Redis, PHP-FPM und RabbitMQ auf 8 GB – das war einfach zu knapp. Die Folge war eine spürbar „zähe“ Performance unter Last.

Das war der Moment, in dem wir gesagt haben: Wir brauchen langfristig eine bessere Lösung.

Wir wollten nicht einfach wechseln, sondern verstehen, was passiert. Also haben wir zunächst sauber evaluiert. Das Gesamtkonzept inklusive der Technik hat uns bei mittwald überzeugt. Wir können auf einem Server mehrere Projekte sauber betreiben – das ist für uns ein wichtiger wirtschaftlicher Faktor.

Der konkrete Auslöser blieb aber die Performance. Und daher wussten wir: Wir müssen handeln. Und zwar nicht nur für das eine Projekt, sondern perspektivisch für mehrere Kunden. Daher sind wir gerade dabei, weitere E-Commerce-Kunden umzuziehen.

Wir arbeiten im mStudio mit einem vServer mit derzeitig 4 vCPU, 16 GiB RAM und 100 GiB Speicher. Zusätzlich haben wir einen kleineren Server für Staging-Umgebungen.

Und diese mehr RAM waren der Gamechanger. Wir haben das Swap-Problem gelöst. Die Performance ist da. Kein Vergleich zu vorher.

Gleichzeitig profitiert unser Team von der Architektur des Servers und dem mStudio: Die Container-Isolation ist für uns wichtig – jedes Projekt läuft sauber getrennt. Da kann kein anderes Projekt plötzlich Ressourcen ziehen und alles verlangsamen.
Auch beim Setup selbst gab es keine Reibung: Der komplette Software-Stack war direkt verfügbar – OpenSearch, RabbitMQ, PHP-FPM. Wir mussten nichts umbauen.

On top habt ihr einen hilfreichen Support – wenn es wirklich brennt, haben wir auch schon samstags jemanden erreicht. Das ist nicht selbstverständlich.

Alles in allem kann ich sagen, wir haben eine deutlich bessere Performance bei gleichzeitig geringeren Kosten. Bei euch können wir Ressourcen effizient nutzen und bekommen trotzdem mehr Leistung als auf vielen dedizierten Setups.

Messt eure Performance – vor dem Wechsel und danach. 
Ohne Benchmarks hätten wir das Swap-Problem nie sauber quantifiziert. Wir hätten wahrscheinlich noch Monate gedacht: ‚Ist halt ein bisschen langsam.‘ 
Schaut euch eure Server daher wirklich im Detail an: htop, Swap-Nutzung – nicht nur die Oberfläche. Ein System kann gesund aussehen und trotzdem kämpfen.

Zum Thema Messung: Wir haben unser Benchmark-Tool als Open Source veröffentlicht. Damit kann jede*r Hosting-Setups vergleichen: 

• Store API
• Admin API
• Frontend TTFB
• Lasttests mit konfigurierbarer Concurrency

Wie das im echten Projekt aussieht, zeigt die Case Study zu GHS Shop und Wäscherutsche – mit denselben Kennzahlen aus der Praxis.