Shopware 6 Performance-Tuning: Elasticsearch, Redis und HTTP-Cache optimal nutzen

Ein langsamer Shop kostet Umsatz. Laut verschiedenen Studien verlassen Nutzer eine Seite, die länger als drei Sekunden lädt. Shopware 6 bietet alle notwendigen Werkzeuge, um auch bei großen Produktkatalogen und hohem Traffic schnelle Ladezeiten zu erreichen — man muss sie nur richtig einsetzen.

1. Elasticsearch / OpenSearch für Produktsuche und Listing¶

Shopware 6 unterstützt Elasticsearch und OpenSearch nativ. Ohne Search Engine benutzt Shopware den eigenen DAL (Data Abstraction Layer) mit MySQL/MariaDB für alle Produkt-Queries — das wird ab etwa 10.000 Produkten spürbar langsamer.

Installation und Aktivierung¶

# In .env
SHOPWARE_ES_ENABLED=1
SHOPWARE_ES_HOSTS=localhost:9200
SHOPWARE_ES_INDEXING_ENABLED=1
SHOPWARE_ES_INDEX_PREFIX=sw

# Initialen Index aufbauen
php bin/console es:index
php bin/console es:create:alias

Wichtige Konfiguration in config/packages/shopware.yaml¶

shopware:
    elasticsearch:
        enabled: true
        hosts:
            - '%env(SHOPWARE_ES_HOSTS)%'
        index_prefix: '%env(SHOPWARE_ES_INDEX_PREFIX)%'
        throw_exception: true
        # Produkt-Felder für Aggregationen aktivieren
        product:
            custom_fields_mapping:
                my_custom_field_text:
                    type: text
                    fields:
                        keyword:
                            type: keyword

Fallstricke¶

• Indexierung nach Änderungen: Jede Produkt-Änderung triggert eine Re-Indexierung. Bei Massenänderungen den Message Queue Supervisor laufen lassen.
• Mapping-Änderungen: Neue Custom Fields erfordern es:index erneut auszuführen.
• Heap Size: Elasticsearch benötigt mindestens 1 GB Heap — in der jvm.options konfigurieren: -Xms1g -Xmx1g.

2. Redis für Session-, Cache- und Queue-Storage¶

Redis beschleunigt Shopware in drei Bereichen erheblich: Session-Speicherung, Objekt-Cache und als Message-Queue-Backend.

Redis konfigurieren¶

# config/packages/framework.yaml
framework:
    session:
        handler_id: 'redis://localhost:6379/0'
    cache:
        app: cache.adapter.redis
        system: cache.adapter.redis_tag_aware
        pools:
            cache.adapter.redis:
                adapter: cache.adapter.redis
                provider: 'redis://localhost:6379/1'

Redis für den Shopware-Cache¶

# config/packages/shopware.yaml
shopware:
    cache:
        invalidation:
            delay: 0
            count: 150

In config/packages/prod/framework.yaml:

framework:
    cache:
        prefix_seed: '%env(APP_SECRET)%'
        app: cache.adapter.redis_tag_aware
        pools:
            cache.app:
                tags: true

Redis-Verbindungspool mit Sentinel (Hochverfügbarkeit)¶

framework:
    cache:
        pools:
            cache.app:
                adapter: cache.adapter.redis_tag_aware
                provider: 'redis+sentinel://sentinel1:26379,sentinel2:26379,sentinel3:26379?redis_sentinel=mymaster'

Message Queue auf Redis¶

# config/packages/messenger.yaml
framework:
    messenger:
        transports:
            async:
                dsn: 'redis://localhost:6379/messages'
                options:
                    auto_setup: false
                    delete_after_ack: true

3. HTTP-Cache (Varnish / Symfony Reverse Proxy)¶

Shopware unterstützt zwei HTTP-Cache-Backends: den integrierten Symfony Reverse Proxy und Varnish. Der HTTP-Cache macht Seiten für nicht eingeloggte Benutzer extrem schnell, weil keine PHP-Ausführung nötig ist.

Integrierten HTTP-Cache aktivieren¶

Der HTTP-Cache wird über Umgebungsvariablen aktiviert — Shopware übernimmt die Kernel-Konfiguration intern. Eine manuelle Änderung der public/index.php ist nicht nötig.

In der .env:

SHOPWARE_HTTP_CACHE_ENABLED=1
SHOPWARE_HTTP_CACHE_DEFAULT_TTL=7200

Cache-Tags und Invalidierung¶

Shopware nutzt Cache-Tags, um präzise zu invalidieren. Wird ein Produkt geändert, werden nur Seiten aus dem Cache entfernt, die dieses Produkt enthalten.

<?php

declare(strict_types=1);

namespace MyPlugin\Subscriber;

use Shopware\Core\Framework\DataAbstractionLayer\Event\EntityWrittenEvent;
use Shopware\Storefront\Framework\Cache\CacheResponseSubscriber;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;

class ProductInvalidationSubscriber implements EventSubscriberInterface
{
    public static function getSubscribedEvents(): array
    {
        return [
            'product.written' => 'onProductWritten',
        ];
    }

    public function onProductWritten(EntityWrittenEvent $event): void
    {
        foreach ($event->getIds() as $productId) {
            // Cache-Tag für dieses Produkt invalidieren
            // Shopware übernimmt das automatisch über den EntityCacheKeyGenerator
        }
    }
}

Varnish konfigurieren¶

Für Hochlast-Setups ist Varnish die bessere Wahl. Shopware liefert eine default.vcl-Vorlage mit:

# In .env
SHOPWARE_HTTP_CACHE_ENABLED=1
SHOPWARE_HTTP_REVERSE_PROXY_ENABLED=1
SHOPWARE_HTTP_REVERSE_PROXY_HOSTS=http://localhost:6081
SHOPWARE_HTTP_REVERSE_PROXY_TTL=7200

4. Datenbankoptimierung¶

Nicht zu vernachlässigen: Die Datenbank. Shopware nutzt MariaDB/MySQL. Wichtige Einstellungen:

# my.cnf / mariadb.conf.d/shopware.cnf
[mysqld]
innodb_buffer_pool_size = 2G          # 70-80% des RAM
innodb_log_file_size = 256M
query_cache_type = 0                  # Bei MySQL 8 ohnehin entfernt
max_connections = 300
thread_cache_size = 16

Fehlende Indizes identifizieren:

-- Langsame Queries finden
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.5;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

5. Asset-Optimierung¶

Shopware komprimiert und bündelt Assets automatisch. Wichtig für Produktionsumgebungen:

php bin/console asset:install
php bin/console theme:compile
# Dann Brotli/gzip-Komprimierung durch nginx

Fazit¶

Performance-Tuning in Shopware ist kein einmaliges Ereignis, sondern ein kontinuierlicher Prozess. Die drei wichtigsten Maßnahmen nach einem Basis-Setup:

1. Elasticsearch für große Produktkataloge (ab ~10.000 Produkten)
2. Redis für Session, Cache und Message Queue
3. HTTP-Cache für alle nicht-personalisierten Seiten

Mit dieser Kombination sind Ladezeiten unter 500ms auch bei komplexen Shops erreichbar.