Catalogus met 100.000+ producten — Magento performance aanpak

Catalogus met 100.000+ producten — Magento performance aanpak

100.000 producten in Magento is niet het probleem. Het probleem is 100.000 producten in Magento zonder de juiste indexing-strategie, zonder ElasticSearch-tuning en met een naïeve import-aanpak.

Wij beheren meerdere Magento-installaties met catalogi in dit formaat. Dit zijn de architectuurkeuzes die het verschil maken tussen een shop die laadt in 1,2 seconden en een shop die iedereen frustreert.

Wat je leert in dit artikel

• Hoe Magento's indexing-architectuur werkt bij grote catalogi
• Flat tables: wanneer ze helpen en wanneer niet
• ElasticSearch-configuratie voor grote catalogi
• Import-optimalisatie voor bulk-operaties
• Caching strategie voor hoge SKU-aantallen

Indexing begrijpen bij grote catalogi

Magento heeft meerdere indexers. Bij grote catalogi zijn dit de meest kritieke:

Indexeringsmodus: realtime vs gepland

Magento kent twee indexeringsmodi: "Update on Save" (realtime) en "Update by Schedule" (gepland).

Voor catalogi boven de 10.000 producten: zet alle indexers op "Update by Schedule". Realtime indexering bij elke productwijziging kost te veel tijd en blokkeert de admin.

# Zet alle indexers op scheduled
php bin/magento indexer:set-mode schedule

# Of per indexer
php bin/magento indexer:set-mode schedule catalog_product_price catalogsearch_fulltext

# Bekijk de huidige modus
php bin/magento indexer:info

Gedeeltelijke reindex

Bij "Update by Schedule" legt Magento een changelog bij: welke producten zijn gewijzigd. Alleen die producten worden bij de volgende cron-run herindexeerd. Dit is een reductie van uren naar minuten bij grote catalogi.

-- Bekijk de changelog-tabel voor prijsindexer
SELECT COUNT(*) FROM catalog_product_price_cl;

-- Hoeveel versies wachten op verwerking
SELECT MAX(version_id) FROM catalog_product_price_cl;
SELECT version_id FROM indexer_state WHERE indexer_id = 'catalog_product_price';

Als de changelog-tabel honderdduizenden rijen bevat zonder verwerkt te worden, is je cron-configuratie incorrect.

Flat tables

Flat tables zijn een Magento-mechanisme waarbij product- en categoriedata wordt gedenormaliseerd naar één tabel per store view. Dit reduceert JOIN-queries op de frontend.

# Flat tables inschakelen
php bin/magento config:set catalog/frontend/flat_catalog_product 1
php bin/magento config:set catalog/frontend/flat_catalog_category 1
php bin/magento indexer:reindex catalog_product_flat catalog_category_flat

Wij zien in de praktijk dat ElasticSearch flat tables grotendeels overbodig maakt voor zoek- en categoriepagina's. De meeste frontend-weergave gaat via de ElasticSearch index, niet via de catalog-tabellen.

ElasticSearch-configuratie

ElasticSearch is bij grote catalogi niet optioneel — het is de reden dat Magento überhaupt schaalbaar is op het gebied van zoeken.

Index-instellingen tunen

// elasticsearch.json configuratie voor grote catalogus
{
  "index": {
    "number_of_shards": 5,
    "number_of_replicas": 1,
    "refresh_interval": "30s",
    "max_result_window": 500000
  },
  "analysis": {
    "analyzer": {
      "dutch_analyzer": {
        "type": "standard",
        "stopwords": "_dutch_"
      }
    }
  }
}

Batch-indexering

Bij een volledige reindex van 100.000+ producten is batchgrootte bepalend voor de duur.

// In app/etc/env.php
'system' => [
    'default' => [
        'catalog' => [
            'search' => [
                'elasticsearch7_index_prefix' => 'magento2',
                'elasticsearch_batch_size' => 1000,
            ]
        ]
    ]
]

Een batchgrootte van 1.000 is een goed startpunt. Groter verhoogt het geheugengebruik per batch. Kleiner verlengt de totale duur door meer HTTP-verzoeken naar ElasticSearch.

Import-optimalisatie

Bij grote catalogi is importsnelheid een operationeel vraagstuk. Als een nachtelijke productimport acht uur duurt, heb je overdag verouderde data.

Magento's native import

# Import via CLI met profiling
time php bin/magento import:validate --entity=catalog_product --behavior=append import.csv
time php bin/magento import:run --entity=catalog_product --behavior=append import.csv

# Import met meer geheugen
php -d memory_limit=4G bin/magento import:run --entity=catalog_product import.csv

Native import verwerkt gemiddeld 500-2.000 producten per minuut, afhankelijk van het aantal attributes en de serverspecificaties.

Optimalisaties voor import

Schakel indexers uit tijdens import en herindexeer daarna:

# Zet indexers op "manual" mode tijdens import
php bin/magento indexer:set-mode schedule
# Stel indexers in op idle (worden niet automatisch getriggerd)
php bin/magento indexer:reset

# Importeer
php bin/magento import:run --entity=catalog_product products.csv

# Herindexeer daarna
php bin/magento indexer:reindex

Disable FPC en block cache tijdens import:

php bin/magento cache:disable full_page block_html
# Importeer
php bin/magento import:run --entity=catalog_product products.csv
# Flush en heractiveer cache
php bin/magento cache:enable full_page block_html
php bin/magento cache:flush full_page block_html

Custom import voor hoge volumes

Bij 200.000+ producten per import-run is native import vaak te traag. Directe database-inserts via een custom import-script zijn 5-10x sneller, maar vereisen dat je de Magento-datastructuur begrijpt.

// Directe insert in EAV-tabel (vereist grondige kennis van Magento datamodel)
$connection = $this->resourceConnection->getConnection();

$rows = [];
foreach ($products as $product) {
    $rows[] = [
        'entity_id' => $product['entity_id'],
        'attribute_id' => $nameAttributeId,
        'store_id' => 0,
        'value' => $product['name'],
    ];
}

// Batch insert
$connection->insertOnDuplicate(
    $connection->getTableName('catalog_product_entity_varchar'),
    $rows,
    ['value']
);

Dit is krachtig maar gevaarlijk. Eén fout in de datastructuur corrumpeert producten. Doe dit alleen met uitgebreide tests en een rollback-strategie.

Caching bij grote catalogi

Full Page Cache strategie

Bij 100.000+ producten is volledige FPC-coverage niet realistisch. Niet elk product wordt dagelijks bezocht. Prioriteer caching op:

• Categoriepagina's (hoogste traffic)
• Populaire productpagina's (top 20% van views)
• Zoekresultatenpagina's voor populaire queries

Varnish TTL per pagina-type

// Varnish configuratie: hogere TTL voor categoriepagina's
sub vcl_backend_response {
    if (req.url ~ "^/[a-z]+-category\.html") {
        set beresp.ttl = 3600s; // 1 uur voor categoriepagina's
    }
    if (req.url ~ "^/[a-z]+-product\.html") {
        set beresp.ttl = 1800s; // 30 minuten voor productpagina's
    }
}

Redis voor product-data caching

// Cache producdata per product-id met TTL
$cacheKey = 'product_data_' . $productId . '_' . $storeId;
$cached = $this->cache->load($cacheKey);

if (!$cached) {
    $product = $this->productRepository->getById($productId);
    $data = $this->prepareProductData($product);
    $this->cache->save(
        serialize($data),
        $cacheKey,
        ['catalog_product_' . $productId],
        3600
    );
    return $data;
}

return unserialize($cached);

Veelgemaakte fouten

Elke productopslag triggert een volledige reindex. Bij 100.000 producten duurt dat minuten. De admin-beheerder wacht. Zet alle indexers op "Update by Schedule".

Een volledige catalogus-reindex van 100.000 producten legt voor 20-40 minuten extra load op de server. Plan dit 's nachts.

Elk searchable attribute vergroot de ElasticSearch index en vertraagt indexering. Markeer alleen attributes als searchable als klanten er daadwerkelijk op zoeken.

Een CSV van 500.000 regels in één keer importeren overbelast het geheugen. Splits op in batches van 10.000-50.000 regels en importeer sequentieel.

Conclusie

Een Magento-catalogus met 100.000+ producten vereist bewuste keuzes op het gebied van indexing, ElasticSearch-configuratie en importstrategie. De standaardconfiguratie is niet voldoende.

De meeste performance-problemen bij grote catalogi zijn configuratieproblemen, geen hardwareproblemen. Schaling helpt, maar de juiste instellingen helpen meer en kosten minder.

Wij helpen bij de architectuur en optimalisatie van grote Magento-catalogi. Bekijk onze Magento diensten of neem contact op voor een vrijblijvend gesprek. Voor geoptimaliseerde hosting bij grote catalogi is Hypernode een bewezen keuze.