Hochperformantes WordPress auf Netcup bereitstellen (Plesk Webhosting vs. Docker + Redis Stack)

Bevor Sie WordPress installieren, sollten Sie analysieren, wie Ihre Website unter Last mit PHP-Workern und der MySQL/MariaDB-Datenbank interagiert. Bei klassischen Unternehmenswebsites, Magazinen, Blogs und Portfolios sind über 95 % aller Seitenaufrufe identisch. Sobald ein Page-Caching-Plugin oder Nginx FastCGI-Cache das fertige HTML-Dokument einmal generiert hat, liefert der Webserver nachfolgende Anfragen direkt aus dem Dateisystem oder Arbeitsspeicher aus, ohne PHP oder die Datenbank überhaupt aufzurufen. Für dieses Lastprofil sind Managed Webhosting 2000 und Webhosting 4000 auf Netcup technisch wie wirtschaftlich optimal.

Völlig anders verhält sich die Architektur bei dynamischen WooCommerce-Shops, Lernplattformen (LearnDash) oder Community-Portalen mit eingeloggten Nutzern: Sobald ein Besucher einen Artikel in den Warenkorb legt, setzt WooCommerce die Cookies woocommerce_items_in_cart, woocommerce_cart_hash und wp_woocommerce_session_. Ein korrekt konfigurierter Reverse-Proxy oder Page-Cache muss bei Vorhandensein dieser Cookies das Vollseiten-Caching zwingend umgehen (fastcgi_cache_bypass / no_cache), damit Kunde B niemals den Warenkorb oder die Adressdaten von Kunde A im Checkout sieht.

Dadurch trifft jeder einzelne Klick eines aktiven Käufers direkt auf einen PHP-FPM-Worker und löst dutzende SQL-Abfragen gegen wp_options, wp_postmeta und wp_woocommerce_order_items aus. Auf einem dedizierten KVM-Server wie dem VPS 1000 G12.5 (8 GB ECC-RAM) oder RS 1000 G12.5 (8 GB DDR5 ECC-RAM) fangen Sie diese Last auf zwei Ebenen ab: Ein persistenter Redis 7 Object Cache hält serialisierte PHP-Objekte und Transients im Arbeitsspeicher vor (was bis zu 70 % aller wiederholten SQL-Lookups einspart), während ein auf 2 GB bis 4 GB dimensionierter MariaDB InnoDB Buffer Pool den gesamten Produkt- und Metadaten-Index dauerhaft im RAM behält.

Für fortgeschrittene Setups auf einem eigenen KVM-Server lässt sich zusätzlich Nginx FastCGI Microcaching vor den PHP-FPM-Pool schalten: Dabei speichert Nginx selbst dynamische Katalog- oder Kategorieseiten für kurze 1 bis 5 Sekunden im Shared Memory (fastcgi_cache_valid 200 3s;), schließt jedoch über eine map-Direktive alle Requests mit wordpress_logged_in_, woocommerce_items_in_cart oder /wp-admin/ strikt vom Cache aus. Vergleichen Sie die beiden Netcup-Architekturen in der folgenden Übersicht:

Nach der Bereitstellung Ihres Netcup Webhosting 2000 oder Webhosting 4000 Tarifs melden Sie sich im Netcup Customer Control Panel (CCP) an, wählen Produkte → Webhosting und klicken auf In Plesk einloggen. Bevor Sie WordPress installieren, sollten Sie zuerst Ihre im Tarif enthaltenen kostenlosen .de-Inklusivdomains im CCP unter Domains → Domain bestellen registrieren, damit die DNS-Zone und das Let’s Encrypt SSL/TLS-Zertifikat in Plesk Obsidian automatisch verknüpft werden.

Der wichtigste Performance-Hebel im Plesk-Panel befindet sich unter Websites & Domains → PHP-Einstellungen: Stellen Sie den Ausführungsmodus auf FPM-Anwendung von Nginx bedient mit PHP 8.3 (oder PHP 8.4). Dadurch verarbeitet Nginx alle statischen Bilder, Schriftarten und CSS/JS-Dateien direkt und leitet nur echte .php-Skriptaufrufe über einen lokalen FastCGI-Unix-Socket an den PHP-FPM-Worker-Pool Ihrer Domain weiter. Heben Sie gleichzeitig memory_limit auf das Maximum Ihres Tarifs an (512M bei Webhosting 2000 bzw. 1024M bei Webhosting 4000).

Prüfen Sie in derselben Ansicht, dass der PHP OPcache (opcache.enable = on) aktiv ist und opcache.memory_consumption auf mindestens 192M sowie opcache.max_accelerated_files auf 20000 steht. Eine moderne WordPress-Installation mit WooCommerce und einem Page-Builder wie Elementor oder Bricks lädt bei jedem Request mehrere tausend einzelne PHP-Klassendateien. Ohne ausreichend großen OPcache müsste PHP diese Dateien bei jedem Seitenaufruf erneut von der SSD lesen und in Bytecode kompilieren; mit aktivem OPcache liegt der fertig kompilierte Bytecode abrufbereit im Shared Memory.

Schließlich sollten Sie im Plesk WordPress Toolkit zwei kritische Einstellungen vornehmen: Aktivieren Sie erstens im Reiter Sicherheit die Sperrung der PHP-Skriptausführung im Verzeichnis wp-content/uploads sowie den Schutz der xmlrpc.php (einem häufigen Angriffsziel für amplifizierte Brute-Force-Attacken). Schalten Sie zweitens die Option wp-cron.php übernehmen ein: Plesk setzt daraufhin automatisch DISABLE_WP_CRON in der wp-config.php und legt einen echten System-Cronjob an, sodass langlaufende Hintergrundaufgaben (wie WooCommerce-Webhooks, geplante Beiträge oder Update-Prüfungen) niemals den Seitenaufruf eines echten Besuchers ausbremsen.

• ▪ 1. Inklusiv-.de-Domains zuerst abrufen: Registrieren Sie im CCP unter Domains → Domain bestellen Ihre kostenlosen Inklusiv-.de-Domains, damit diese automatisch Ihrem Webhosting-Tarif zugeordnet werden.
• ▪ 2. Wildcard Let’s Encrypt SSL + HTTP/2 aktivieren: Aktivieren Sie in Plesk unter Websites & Domains → SSL/TLS-Zertifikate Let’s Encrypt für Hauptdomain (example.de), www und Webmail inklusive dauerhafter 301-HTTPS-Weiterleitung.
• ▪ 3. PHP 8.3 FPM in Plesk optimieren: Öffnen Sie die PHP-Einstellungen Ihrer Domain, wählen Sie PHP 8.3 FPM-Anwendung von Nginx bedient, setzen Sie memory_limit auf 512M (Webhosting 2000) bzw. 1024M (Webhosting 4000), max_execution_time auf 120 und prüfen Sie opcache.enable = on mit opcache.memory_consumption = 192.
• ▪ 4. Installation über das WordPress Toolkit & Security-Hardening: Installieren Sie WordPress über WordPress → Installieren und aktivieren Sie im Reiter Sicherheit alle Schutzmaßnahmen (PHP-Ausführung in wp-content/uploads verbieten, XML-RPC deaktivieren, Datenbank-Präfix ändern und Datei-Editor im WP-Admin sperren).
• ▪ 5. WP-Cron durch echten Plesk-Cronjob ersetzen: Aktivieren Sie im WordPress Toolkit den Schalter wp-cron.php übernehmen, damit Hintergrundaufgaben alle 10 Minuten über einen echten System-Cronjob statt bei jedem Besucheraufruf ausgeführt werden.

Auf einem Netcup VPS 1000 G12.5 (8 GB ECC-RAM) oder RS 1000 G12.5 (8 GB DDR5 ECC-RAM) haben Sie die volle Kontrolle über die Speicherzuteilung zwischen Datenbank, Object Cache und PHP-Workern. Die häufigste Absturzursache auf selbstverwalteten WordPress-Servern ist ein falsch berechneter PHP-FPM-Worker-Pool (pm.max_children). Die Formel für eine stabile Dimensionierung lautet: (Gesamter RAM − OS/Kernel − MariaDB Buffer Pool − Redis maxmemory) ÷ Durchschnittlicher RSS-Speicher pro PHP-Worker. Auf einem 8 GB Server, auf dem wir 512 MB für Linux/Nginx, 2,5 GB für MariaDB und 512 MB für Redis reservieren, bleiben rund 4,5 GB RAM für PHP übrig. Da ein typischer WooCommerce-PHP-Worker (dank gemeinsam genutztem OPcache) etwa 70 MB bis 90 MB privaten RSS-Speicher belegt, ist ein Limit von pm = dynamic mit pm.max_children = 45 bis 55 absolut betriebssicher, ohne jemals Swap-Thrashing auszulösen.

Auf Datenbankebene optimieren wir MariaDB 11.4 LTS mit drei gezielten Startparametern: --innodb-buffer-pool-size=2G reserviert 2 GB Arbeitsspeicher exklusiv für Tabellen- und Indexseiten. Mit --innodb-flush-method=O_DIRECT weist MariaDB den Linux-Kernel an, das doppelte Zwischenspeichern (Double Buffering) von InnoDB-Datendateien im Host-Page-Cache zu überspringen und direkt mit dem NVMe-Blockgerät zu kommunizieren. Zusätzlich reduziert --innodb-flush-log-at-trx_commit=2 die synchronen fsync()-Aufrufe von jeder einzelnen Mikro-Transaktion auf ein 1-Sekunden-Intervall – das vervielfacht die Schreibgeschwindigkeit bei WooCommerce-Bestellungen, während das Risiko bei einem kompletten Host-Ausfall auf maximal eine Sekunde begrenzt bleibt.

Für den persistenten Redis 7.4 Object Cache konfigurieren wir --maxmemory 512mb zusammen mit der Verdrängungsstrategie --maxmemory-policy allkeys-lru. Sobald die 512 MB ausgeschöpft sind, entfernt Redis automatisch die am längsten nicht mehr abgerufenen Cache-Schlüssel (Least Recently Used), sodass neue Produkt- oder Session-Objekte jederzeit verzögerungsfrei gespeichert werden können. Wenn Redis und PHP-FPM auf demselben Host oder über ein gemeinsames Volume laufen, können Sie die Verbindung wahlweise über einen Unix-Domain-Socket (/var/run/redis/redis.sock, spart den TCP/IP-Loopback-Overhead) oder wie im folgenden Compose-Stack über das interne Bridge-Netzwerk wp_internal (redis:6379) herstellen.

Der folgende produktionsreife Docker-Compose-Stack bindet den WordPress-Container strikt an 127.0.0.1:8080, sodass er ausschließlich über Ihren gehärteten Host-Nginx- oder Caddy-Reverse-Proxy erreichbar ist, während MariaDB und Redis komplett vom öffentlichen Internet abgeschirmt im internen Netzwerk wp_internal kommunizieren:

services:
  mariadb:
    image: mariadb:11.4
    restart: unless-stopped
    command:
      - --character-set-server=utf8mb4
      - --collation-server=utf8mb4_unicode_ci
      - --innodb-buffer-pool-size=2G
      - --innodb-log-file-size=256M
      - --innodb-flush-log-at-trx-commit=2
      - --innodb-flush-method=O_DIRECT
      - --max-connections=150
    environment:
      MARIADB_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
      MARIADB_DATABASE: wp_production
      MARIADB_USER: wp_user
      MARIADB_PASSWORD: ${DB_PASSWORD}
    volumes:
      - db_data:/var/lib/mysql
    networks:
      - wp_internal
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 10s
      timeout: 5s
      retries: 5

  redis:
    image: redis:7.4-alpine
    restart: unless-stopped
    command: ["redis-server", "--maxmemory", "512mb", "--maxmemory-policy", "allkeys-lru"]
    networks:
      - wp_internal

  wordpress:
    image: wordpress:6.7-php8.3-apache
    restart: unless-stopped
    depends_on:
      mariadb:
        condition: service_healthy
      redis:
        condition: service_started
    ports:
      - "127.0.0.1:8080:80"
    environment:
      WORDPRESS_DB_HOST: mariadb:3306
      WORDPRESS_DB_NAME: wp_production
      WORDPRESS_DB_USER: wp_user
      WORDPRESS_DB_PASSWORD: ${DB_PASSWORD}
      WORDPRESS_CONFIG_EXTRA: |
        define('WP_REDIS_HOST', 'redis');
        define('WP_REDIS_PORT', 6379);
        define('WP_CACHE', true);
        define('DISABLE_WP_CRON', true);
        define('DISALLOW_FILE_EDIT', true);
        define('WP_MEMORY_LIMIT', '512M');
        if (isset($$_SERVER['HTTP_X_FORWARDED_PROTO']) && $$_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
            $$_SERVER['HTTPS'] = 'on';
        }
    volumes:
      - wp_html:/var/www/html
      - ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini:ro
    networks:
      - wp_internal

volumes:
  db_data:
  wp_html:

networks:
  wp_internal:
    driver: bridge

# 1. Benutzerdefinierte PHP-OPcache- und Upload-Limits schreiben
cat << 'EOF' > /opt/stacks/wordpress/uploads.ini
upload_max_filesize = 128M
post_max_size = 128M
memory_limit = 512M
max_execution_time = 180
opcache.enable = 1
opcache.memory_consumption = 192
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 20000
opcache.revalidate_freq = 2
EOF

# 2. Echten System-Cronjob alle 5 Minuten als Ersatz für WP-Cron einrichten
cat << 'EOF' | sudo tee /etc/cron.d/wordpress-cron
*/5 * * * * root docker exec wordpress-wordpress-1 php /var/www/html/wp-cron.php >/dev/null 2>&1
EOF