Zum Inhalt

Robuste WordPress Multisite

  • 3 min read

Notizen aus unserem Arbeitsalltag…

Systematische Optimierung im Docker- und Reverse Proxy-Umfeld

WordPress Multisite bietet eine flexible Basis für die Verwaltung mehrerer Webauftritte. In Kombination mit Docker ermöglicht dies eine hochskalierbare und isolierte Hosting-Lösung. Doch die Integration dieser Komponenten in eine performante und stabile Umgebung erfordert eine präzise Abstimmung. Dieser Artikel beleuchtet die Schlüsselbereiche eines typischen Optimierungsprozesses, der auf die Behebung häufiger Performance- und Kommunikationsprobleme abzielt.

Das Problem: Symptome gestörter Kommunikation

Ein wiederkehrendes Symptom in komplexen WordPress-Installationen sind scheinbar wiederholte Speichervorgänge im Backend. Dies deutet häufig auf Kommunikationsprobleme der WordPress Heartbeat API hin, die durch Timeouts, ineffizientes Caching oder unzureichende Serverressourcen verursacht werden können. Die Behebung erfordert einen ganzheitlichen Blick auf den gesamten Stack.

Die mehrschichtige Optimierung

Der Optimierungsprozess erstreckt sich über mehrere Ebenen der Infrastruktur:

1. Reverse Proxy: Der zentrale Vermittler

Der Reverse Proxy (z.B. Synology Reverse Proxy, Nginx) agiert als erster Kontaktpunkt für externe Anfragen. Seine korrekte Konfiguration ist entscheidend:

  • Caching-Ausschluss: Kritisch ist das vollständige Ausschliessen des /wp-admin/-Pfades und spezifischer WordPress-Dateien wie admin-ajax.php vom Caching. Eine Zwischenspeicherung dieser dynamischen Bereiche führt zu veralteten Antworten und Kommunikationsfehlern.
  • Timeouts: Erhöhung der Proxy-Timeouts (z.B. connect_timeout, send_timeout, read_timeout auf 300 Sekunden), um dem Backend genügend Zeit zur Verarbeitung langlaufender Anfragen zu geben.
  • Header-Weiterleitung: Sicherstellung der korrekten Weiterleitung von Headern wie X-Forwarded-For (Client-IP), X-Forwarded-Proto (Original-Protokoll, z.B. HTTPS) und des Host-Headers.
  • WebSocket-Unterstützung: Aktivierung der WebSocket-Unterstützung ist für moderne WordPress-Funktionen und den Gutenberg-Editor unerlässlich.

2. Docker Compose: Orchestrierung und Ressourcen

Die docker-compose.yaml definiert die Services und deren Zusammenspiel:

  • Ressourcenzuweisung: Präzise Definition von RAM- und CPU-Limits für jeden Container (mem_limit, cpu_shares), insbesondere für den WordPress- und den Datenbank-Container, um Ressourcenkonflikte zu vermeiden.
  • Abhängigkeiten und Health Checks: Nutzung von depends_on mit condition: service_healthy gewährleistet, dass abhängige Services (z.B. Redis, Datenbank) vollständig verfügbar sind, bevor der WordPress-Container startet.
  • Konsistente Benennung: Sicherstellung, dass Servicenamen in docker-compose.yaml (z.B. redis) exakt den in wp-config.php definierten Hostnamen entsprechen (WP_REDIS_HOST).
  • Spezifische Image-Versionen: Festlegung spezifischer Image-Tags (z.B. redis:7.2-alpine, mariadb:11.4) statt latest, um unkontrollierte Updates und Kompatibilitätsprobleme zu vermeiden.
  • Benutzerdefinierte Konfigurationen: Einbindung spezifischer PHP- (uploads.ini, opcache.ini) und Apache-Konfigurationsdateien (admin-apache.conf) per Volume-Mount.

3. WordPress (wp-config.php): Anwendungsnahe Anpassungen

Die Kernkonfigurationsdatei von WordPress ermöglicht applikationsspezifische Optimierungen:

  • Heartbeat API-Kontrolle: Anpassung des WP_HEARTBEAT_INTERVAL (z.B. auf 120 Sekunden) und selektives Deaktivieren der API für Frontend-Besucher (WP_HEARTBEAT_DISABLE_FRONTEND) reduziert die Serverlast.
  • Redis Object Cache: Konfiguration des Object Caching über Redis (WP_REDIS_HOST, WP_REDIS_PORT, WP_REDIS_SELECTIVE_FLUSH) zur Reduzierung der Datenbanklast.
  • Speicherlimits: Erhöhung der PHP-Speicherlimits (WP_MEMORY_LIMIT, WP_MAX_MEMORY_LIMIT) zur Unterstützung umfangreicher Operationen, besonders in einer Multisite-Umgebung.
  • Reverse Proxy-Erkennung: Implementierung der $_SERVER['HTTPS'] = 'on';-Logik zur korrekten Protokollerkennung hinter dem Proxy.

4. Datenbank (MariaDB): Das Rückgrat

Eine optimierte Datenbank ist fundamental für die Gesamtperformance:

  • InnoDB Buffer Pool Size: Feinabstimmung des innodb_buffer_pool_size (z.B. auf 4GB), um häufig genutzte Daten im Arbeitsspeicher zu halten. Konsistenz zwischen mysql.cnf und Umgebungsvariablen (MYSQL_INNODB_BUFFER_POOL_SIZE) ist hierbei zu gewährleisten, wobei Umgebungsvariablen oft Vorrang haben.

Fazit: Systematik führt zu Stabilität

Die erfolgreiche Optimierung einer WordPress Multisite in einem Docker- und Reverse Proxy-Umfeld erfordert einen systematischen Ansatz. Durch die gezielte Abstimmung jeder Schicht – vom Reverse Proxy über die Docker-Orchestrierung und die WordPress-Konfiguration bis zur Datenbank – können typische Performance-Engpässe eliminiert und eine stabile, reaktionsschnelle Plattform geschaffen werden. Kontinuierliches Monitoring und iteratives Anpassen sind dabei unerlässlich, um die Performance langfristig zu sichern.

Unsere WordPress-Umgebung – wir stehen Ihnen gerne zur Verfügung. Kontaktieren Sie uns.