Een handelaar toont 80.000 productreferenties, waarvan 15.000 actief online. Het duurt acht seconden om de categoriepagina weer te geven. Het bureau beveelt een speciale server met 32 GB RAM aan. Behalve dat de profilering iets anders laat zien: een SQL-query van vier seconden, een filtermodule die zes tabellen met elkaar verbindt, en een uitgeschakelde Smarty-cache "om het debuggen te vergemakkelijken." De echte beperking was niet PrestaShop zelf; het was de listingarchitectuur in een compacte catalogus.
Dit scenario herhaalt zich in winkels die geleidelijk zijn gegroeid. De backoffice geeft tienduizenden records correct weer, wat het verkoopteam geruststelt. De klant raadpleegt echter de administratie niet: hij bladert door categorieën, start zoekopdrachten, vergelijkt varianten. Dit is waar de belasting wordt geconcentreerd, lang voordat de processor van de host zijn plafond bereikt.
De nuttige vraag is dus niet “hoeveel producten ondersteunt PrestaShop?” ". Het is concreter: welk verzoek verwacht uw bezoeker als eerste, en wat vertraagt hem: de database, een module, de afwezigheid van cache of uiteindelijk de infrastructuur?
Waar in de praktijk de grens verschijnt
In een grote catalogus vallen de knelpunten uiteen in verschillende lagen. De MySQL-database heeft het eerst te lijden onder de productvermeldingen en het beheer wanneer indexen ontbreken of de ps_product*-tabellen groeien zonder onderhoud. Native search wordt strafbaar zodra de facetten de joins vermenigvuldigen. De Smarty- of objectcache laat, indien afwezig of onjuist ongeldig gemaakt, een hoge responstijd achter, zelfs als de server beschikbaar lijkt.
Modules van derden versterken het probleem: slecht geoptimaliseerde facetfilters, marketingextensies die op elke categoriepagina worden uitgevoerd, synchrone CSV-importen die de winkel tijdens kantooruren blokkeren. Afbeeldingen die niet door een CDN worden geleverd, kunnen een aanzienlijk deel van de bandbreedte opslokken zonder op zichzelf acht seconden latentie te veroorzaken, maar ze verslechteren wel de waargenomen ervaring.
| Gebied | Symptoom | Hendel |
|---|---|---|
| MySQL-database | Trage vermelding, productbeheerder | Indexeren, opschonen, replica lezen |
| Native zoekopdracht | Time-out of langzaam zoeken | Elasticsearch, Algolia |
| Slim / cache | Consistent hoge responstijd | Paginacache, Redis |
| Gefacetteerde modules | Processorpiek op categorieën | Refactor of speciale service |
| Afbeeldingen | Verzadigde bandbreedte | CDN, moderne formaten |
| CSV-import | Winkelblokkering | Asynchrone wachtrij, daluren |
Een grote catalogus legt slecht doordachte verbindingen bloot – niet het merk PrestaShop zelf.
Hosting: meer dan het aantal processorkernen
Door hosts uitsluitend te vergelijken op basis van het aantal virtuele processors, worden de criteria verborgen die er echt toe doen voor PrestaShop. Schijf I/O bepaalt de snelheid van queries op grote tabellen: lokale NVMe-opslag of gelijkwaardig is beter dan een langzame gedeelde schijf. Het RAM moet de MySQL-bufferpool groot maken; acht gigabytes vertegenwoordigen vaak de comfortdrempel voor een zware catalogus met actieve cache.
Redis bedient zowel sessies als Smarty- of objectcache wanneer de applicatie correct is geconfigureerd. Aan de PHP kant, richt je op versie 8.1 of hoger, activeer OPcache en pas max_execution_time aan voor geplande imports. Een betrouwbare cron is essentieel voor indexering, cache-opschoning en wachtrijen. Ten slotte kunt u met een pre-productieomgeving imports en modules testen zonder de productie te blokkeren.
Gedeeld is zelden geschikt voor een zware catalogus met geavanceerde filters. Een VPS of een cloud speciaal voor de winkel is realistischer zodra de vermeldingen ondanks een geoptimaliseerde database een paar seconden overschrijden. Om bedrijfsgerichte aanbiedingen te vergelijken, raadpleegt u onze overzicht en de MySQL voor dynamische site gids.
Applicatie-optimalisaties voordat we naar de hogere markt gaan
Voordat u de hostingrekening verhoogt, moet u de meest voorkomende applicatiewinsten controleren. Ontbrekende indexen op gefilterde attributen, id_category en active veranderen een zoekopdracht van zes seconden soms in een paar honderd milliseconden. Schakel de lijstmodules één voor één uit door de generatietijd van de pagina te meten: deze methode is omslachtig, maar identificeert de boosdoener vaak binnen een ochtend.
Schakel de cache in met een gedocumenteerde invalidatiestrategie: zonder een duidelijke regel ruilt u traagheid in voor verouderde gegevens. Zoekopdrachten uitbesteden zodra SQL-zoekopdrachten ondanks indexen meerdere honderden milliseconden overschrijden. Een CDN voor productafbeeldingen vermindert het waargenomen gewicht van de pagina – vaak rond zeventig procent van het totale gewicht. Plan nachtelijke import met een gedeeltelijke onderhoudsmodus om te voorkomen dat de database overdag verzadigd raakt.
Als u twijfelt tussen e-commerce-stacks, helpt de gids Magento is geen zware WordPress om PrestaShop te positioneren in vergelijking met andere catalogusoplossingen.
Signalen dat de gastheer het plafond is geworden
Infrastructuur wordt de beperkende factor wanneer applicatie-optimalisatie al is uitgevoerd en de symptomen aanhouden. Een processor die minder dan veertig procent wordt gebruikt terwijl de schijf-I/O-wachttijd permanent hoog blijft, duidt op een schijfknelpunt, niet op een processorknelpunt. Een langzaam MySQL-querylogboek dat ondanks correcte indexen wordt gevuld, duidt op onvoldoende geheugen of schijfgrootte. Geheugen vol door een te kleine bufferpool dwingt herhaalde schijflezingen af. Een hoge netwerklatentie naar een op afstand beheerde database bestraft elke pagina.
In deze gevallen is het zinvol om naar een hogere markt te gaan of de applicatie en de basis dichter bij elkaar te brengen. Zolang de profilering een dominante SQL-query laat zien, betaalt een krachtigere server alleen maar meer voor dezelfde traagheid.
De top: de catalogus onthult de schulden van de modules
Magento en WooCommerce zijn niet de enigen die lijden onder de enorme catalogus. PrestaShop is in theorie lichter, maar gevoeliger voor modules van derden bij vermeldingen. Vergelijking met andere stapels heeft alleen zin als je dezelfde categoriepagina meet, en niet hetzelfde aantal referenties in de basis.
Beslis en ga vooruit zonder blinde vlek
Begin met het profileren van een representatieve categoriepagina en interne zoekopdrachten, met dezelfde filters die uw bezoekers het meest gebruiken. Controleer vervolgens de modules die van invloed zijn op de lijst en de facetten, indien mogelijk in pre-productie. Activeer de objectcache en Redis als u dat nog niet hebt gedaan, en pas vervolgens de grootte van MySQL in het geheugen en de indexen aan voordat u een verandering van host overweegt. Bouw alleen infrastructuur na versleuteld bewijs: querytijd, processorbelasting, schijfwachttijd. Blader door op e-commerce gerichte hosts in onze overzicht en de vergelijking op basis van deze statistieken, niet op basis van een generieke “grotere server”-aanbeveling.
Veelgestelde vragen
Hoeveel producten kan PrestaShop beheren?
Er is geen officieel plafond. Winkels werken met meer dan 100.000 productreferenties wanneer de architectuur wordt aangepast. Zonder cache, SQL-indexen en geoptimaliseerde modules beginnen problemen vaak tussen de 5.000 en 20.000 actieve referenties, vooral bij zware facetfilters.
Welk minimaal RAM-geheugen voor een grote catalogus?
Reken 4 GB voor een gemiddelde, goed geoptimaliseerde winkel, en 8 GB of meer met extern zoeken, talrijke modules of frequente importen. Gedeeld delen is zelden voldoende als je verder gaat dan een paar duizend producten met geavanceerde filters.
Is Elasticsearch vereist?
Nee, maar native SQL-zoekopdrachten worden traag in grote catalogi met facetten. Elasticsearch of Algolia worden relevant wanneer zoekopdrachten ondanks indexering meerdere honderden milliseconden overschrijden.
Hoe kan ik vaststellen of het probleem door de modules wordt veroorzaakt?
Schakel marketing, filters en SEO-modules tijdelijk uit in de pre-productie en vergelijk vervolgens de tijd om een categoriepagina te genereren. Een slecht gecodeerde module in de lijst blijft een van de meest voorkomende oorzaken in dichte catalogi.
Met 80.000 referenties is de vraag niet “welke host?” — het is "welke SQL-query verwacht uw klant als eerste?" »