Ein Händler zeigt 80.000 Produktreferenzen an, davon 15.000 online aktiv. Die Anzeige der Kategorieseite dauert acht Sekunden. Die Agentur empfiehlt einen dedizierten Server mit 32 GB RAM. Außer, dass die Profilerstellung etwas anderes zeigt: eine vier Sekunden lange SQL-Abfrage, ein Filtermodul, das sechs Tabellen verknüpft, und einen deaktivierten Smarty-Cache, „um das Debuggen zu erleichtern“. Die eigentliche Einschränkung lag nicht in PrestaShop selbst, sondern in der Auflistungsarchitektur eines dichten Katalogs.
Dieses Szenario wiederholt sich in Geschäften, die nach und nach gewachsen sind. Zehntausende Datensätze werden im Backoffice korrekt angezeigt, was das Vertriebsteam beruhigt. Der Kunde konsultiert jedoch nicht die Verwaltung: Er durchsucht Kategorien, startet Suchvorgänge und vergleicht Varianten. Hier konzentriert sich die Last, lange bevor der Prozessor des Hosts seine Leistungsgrenze erreicht.
Die nützliche Frage lautet also nicht: „Wie viele Produkte unterstützt PrestaShop?“ ". Es ist konkreter: Welche Anfrage erwartet Ihr Besucher zuerst und was bremst ihn aus – die Datenbank, ein Modul, das Fehlen von Cache oder schließlich die Infrastruktur?
Wo die Grenze in der Praxis auftritt
In einem großen Katalog fallen die Engpässe in verschiedene Ebenen. Die MySQL-Datenbank leidet zunächst unter Produktlisten und -verwaltung, wenn Indizes fehlen oder die „ps_product*“-Tabellen ohne Wartung wachsen. Die native Suche wird zu Nachteilen, sobald die Facetten die Verknüpfungen vervielfachen. Wenn der Smarty- oder Objekt-Cache fehlt oder falsch ungültig gemacht wird, sorgt er für eine hohe Reaktionszeit, selbst wenn der Server verfügbar zu sein scheint.
Module von Drittanbietern verstärken das Problem: schlecht optimierte Facettenfilter, Marketingerweiterungen, die auf jeder Kategorieseite ausgeführt werden, synchrone CSV-Importe, die den Shop während der Geschäftszeiten blockieren. Bilder, die nicht von einem CDN bereitgestellt werden, können einen erheblichen Teil der Bandbreite verschlingen, ohne dass sie allein acht Sekunden Latenz verursachen, aber sie verschlechtern das wahrgenommene Erlebnis.
| Bereich | Symptom | Hebel |
|---|---|---|
| MySQL-Datenbank | Langsame Auflistung, Produktadministrator | Index, Bereinigung, Replikat-Lesung |
| Native Suche | Timeout oder langsame Suche | Elasticsearch, Algolia |
| Smarty / Cache | Konstant hohe Reaktionszeit | Seitencache, Redis |
| Facettierte Module | Prozessorspitze bei Kategorien | Refactor oder dedizierter Dienst |
| Bilder | Gesättigte Bandbreite | CDN, moderne Formate |
| CSV-Importe | Shop-Sperrung | Asynchrone Warteschlange, außerhalb der Hauptverkehrszeiten |
Ein großer Katalog enthüllt schlecht durchdachte Verknüpfungen – nicht die Marke PrestaShop selbst.
Hosting: über die Anzahl der Prozessorkerne hinaus
Der Vergleich von Hosts ausschließlich anhand der Anzahl der virtuellen Prozessoren verbirgt die Kriterien, die für PrestaShop wirklich wichtig sind. Festplatten-E/A bestimmt die Geschwindigkeit von Abfragen bei großen Tabellen: Lokaler NVMe-Speicher oder gleichwertiger Speicher ist besser als eine langsame gemeinsam genutzte Festplatte. Der RAM muss die Größe des MySQL-Pufferpools haben; Acht Gigabyte stellen oft die Komfortschwelle für einen umfangreichen Katalog mit aktivem Cache dar.
Redis bedient sowohl Sitzungen als auch Smarty oder Objektcache, wenn die Anwendung richtig konfiguriert ist. Streben Sie auf der PHP-Seite Version 8.1 oder höher an, aktivieren Sie OPcache und passen Sie „max_execution_time“ für geplante Importe an. Ein zuverlässiger Cron ist für die Indizierung, Cache-Bereinigung und Warteschlangen unerlässlich. Schließlich können Sie in einer Vorproduktionsumgebung Importe und Module testen, ohne die Produktion zu blockieren.
Shared eignet sich selten für einen umfangreichen Katalog mit erweiterten Filtern. Sobald die Einträge trotz optimierter Datenbank einige Sekunden überschreiten, ist ein VPS oder eine dedizierte Cloud für den Shop realistischer. Um geschäftsorientierte Angebote zu vergleichen, konsultieren Sie unser Hosting-Verzeichnis und den Leitfaden MySQL für dynamische Sites.
Anwendungsoptimierungen vor dem Wechsel ins Upmarket
Bevor Sie die Hosting-Rechnung erhöhen, prüfen Sie die häufigsten Anwendungsgewinne. Fehlende Indizes für gefilterte Attribute „id_category“ und „active“ führen manchmal dazu, dass eine Abfrage von sechs Sekunden zu einigen hundert Millisekunden dauert. Deaktivieren Sie die Auflistungsmodule nacheinander, indem Sie die Seitengenerierungszeit messen: Die Methode ist mühsam, identifiziert den Übeltäter jedoch oft innerhalb eines Morgens.
Aktivieren Sie den Cache mit einer dokumentierten Invalidierungsstrategie: Ohne eine klare Regel tauschen Sie Langsamkeit gegen veraltete Daten ein. Suche auslagern, sobald SQL-Listing-Abfragen trotz Indizes mehrere hundert Millisekunden überschreiten. Ein CDN für Produktbilder reduziert das wahrgenommene Gewicht der Seite – oft etwa siebzig Prozent des Gesamtgewichts. Planen Sie nächtliche Importe mit einem teilweisen Wartungsmodus, um eine Überlastung der Datenbank tagsüber zu vermeiden.
Wenn Sie zwischen E-Commerce-Stacks zögern, hilft Ihnen der Leitfaden Magento ist kein schweres WordPress dabei, PrestaShop im Vergleich zu anderen Kataloglösungen zu positionieren.
Signalisiert, dass der Host zur Decke geworden ist
Die Infrastruktur wird zum limitierenden Faktor, wenn die Anwendungsoptimierung bereits durchgeführt wurde und die Symptome weiterhin bestehen. Wenn der Prozessor zu weniger als 40 Prozent ausgelastet ist, während die Festplatten-E/A-Wartezeit dauerhaft hoch bleibt, deutet dies auf einen Festplattenengpass und nicht auf einen Prozessorengpass hin. Ein langsames MySQL-Abfrageprotokoll, das sich trotz korrekter Indizes füllt, deutet auf unzureichenden Arbeitsspeicher oder unzureichende Festplattengröße hin. Der Speicher ist durch einen zu kleinen Pufferpool voll und erzwingt wiederholte Festplattenlesevorgänge. Eine hohe Netzwerklatenz zu einer remote verwalteten Datenbank beeinträchtigt jede Seite.
In diesen Fällen ist es sinnvoll, nach oben zu wechseln oder Anwendung und Basis näher zusammenzubringen. Solange die Profilerstellung eine dominante SQL-Abfrage zeigt, zahlt ein leistungsfähigerer Server bei gleicher Langsamkeit nur mehr.
Der Gipfel: Der Katalog verrät die Schulden der Module
Magento und WooCommerce sind nicht die einzigen, die unter dem riesigen Katalog leiden. Theoretisch ist PrestaShop einfacher, reagiert aber in den Einträgen empfindlicher auf Module von Drittanbietern. Ein Vergleich mit anderen Stapeln macht nur dann Sinn, wenn Sie die gleiche Kategorieseite messen, nicht die gleiche Anzahl an Referenzen in der Basis.
Entscheide dich und gehe ohne blinden Fleck voran
Beginnen Sie mit der Profilierung einer repräsentativen Kategorieseite und der internen Suche mit denselben Filtern, die Ihre Besucher am häufigsten verwenden. Prüfen Sie dann die Module, die sich auf die Auflistung und die Facetten auswirken, möglichst in der Vorproduktion. Aktivieren Sie den Objektcache und Redis, falls Sie dies noch nicht getan haben, und passen Sie dann MySQL im Speicher und in den Indizes an, bevor Sie einen Hostwechsel in Betracht ziehen. Bauen Sie die Infrastruktur erst nach verschlüsseltem Nachweis auf: Abfragezeit, Prozessorlast, Festplattenwartezeit. Durchsuchen Sie E-Commerce-orientierte Hosts in unserem Verzeichnis und im Vergleich basierend auf diesen Metriken, nicht auf einer allgemeinen Empfehlung für „größere Server“.
Häufig gestellte Fragen
Wie viele Produkte kann PrestaShop verwalten?
Es gibt keine offizielle Obergrenze. Filialen verfügen bei angepasster Architektur über mehr als 100.000 Produktreferenzen. Ohne Cache, SQL-Indizes und optimierte Module beginnen Probleme häufig zwischen 5.000 und 20.000 aktiven Referenzen, insbesondere bei stark facettierten Filtern.
Welcher Mindest-RAM für einen großen Katalog?
Rechnen Sie mit 4 GB für einen durchschnittlichen, gut optimierten Shop und 8 GB oder mehr mit externer Suche, zahlreichen Modulen oder häufigen Importen. Das gemeinsame Teilen reicht selten über ein paar tausend Produkte mit erweiterten Filtern hinaus aus.
Ist Elasticsearch erforderlich?
Nein, aber die native SQL-Suche wird bei großen Katalogen mit Facetten langsam. Elasticsearch oder Algolia werden dann relevant, wenn Listungsabfragen trotz Indizierung mehrere hundert Millisekunden überschreiten.
Wie kann festgestellt werden, ob das Problem von den Modulen herrührt?
Deaktivieren Sie vorübergehend Marketing-, Filter- und SEO-Module in der Vorproduktion und vergleichen Sie dann die Zeit zum Erstellen einer Kategorieseite. Ein schlecht codiertes Modul in der Auflistung ist nach wie vor eine der häufigsten Ursachen in dichten Katalogen.
Bei 80.000 Referenzen ist die Frage nicht „Welcher Gastgeber?“ – es ist „Welche SQL-Abfrage erwartet Ihr Kunde zuerst?“ »