Zum Inhalt springen 
wordpress multisite performance löst selten echte Engpässe: Gemeinsame Datenbank, gemeinsamer Code und geteilte Serverressourcen erzeugen Abhängigkeiten, die bei Lastspitzen jede Site im Netzwerk bremsen. Ich zeige, warum diese Architektur bei wachsenden Anforderungen kippt, welche Risiken entstehen und wie ich skalierbare Alternativen plane.
Zentrale Punkte
- Geteilte Ressourcen: Eine Site bremst alle
- Sicherheit: Ein Fehler, viele Ausfälle
- Skalierung: Theorie vs. Betrieb
- Hosting-Limits: CPU, IO, DB
- Alternative: Isolation pro Site
Warum Multisite bei Lastspitzen bremst
Ich sehe in Audits immer wieder, wie eine einzelne Site mit Traffic-Peaks das ganze Netzwerk in Mitleidenschaft zieht. CPU-Spitzen, IO-Wartezeiten und Datenbank-Locks entstehen nicht isoliert, sondern wirken auf alle Projekte im Verbund. Jede Optimierung muss für die kombinierte Last dimensionieren, was in der Praxis zu Überplanung und dennoch zu Engpässen führt. Selbst saubere Caching-Schichten puffern nur begrenzt, wenn zentrale Ressourcen überlasten. Wer das Problem tiefer verstehen möchte, findet typische Ursachen in den Infrastruktur-Limits von Multisite.
Architektur: gemeinsame Ressourcen, gemeinsame Engpässe
Multisite teilt sich eine Datenbank, Codepfade und Serverleistung – das ist bequem, aber riskant. Ein Plugin-Update verändert Verhalten für alle Sites gleichzeitig, und ein Lock auf einer Tabelle trifft jede Abfrage im Netzwerk. Auch der Cron verarbeitet Aufgaben zentral, wodurch lange Queues entstehen können, wenn mehrere Sites zur selben Zeit Jobs einplanen. Backups, Indizes und Wartungsfenster brauchen besondere Sorgfalt, weil ein Fehler stets kreisweit wirkt. Diese Kopplung lässt sich mit Governance-Regeln entschärfen, doch die Kopplung bleibt technisch bestehen.
Sicherheits- und Verwaltungsrisiken in der Praxis
Ein Sicherheitsleck in einem global aktivierten Plugin kann alle Sites lahmlegen, was ich als echtes Risikobündel werte. Teams warten oft auf Super-Admins, um Updates oder Config-Änderungen durchzuführen, was Time-to-Fix und Time-to-Feature verlängert. Nicht jedes Plugin verträgt Multisite, wodurch Sonderfälle, Edge-Cases und spätere Regressionen entstehen. Ein Theme-Update hilft Site A, bricht aber Site B – solche Ankereffekte sehe ich besonders bei individuelleren Projekten. Wer Verantwortung klar trennt, braucht Rollen und Prozesse, die in Multisite häufig Reibung erzeugen.
Skalierung in der Theorie vs. Betrieb
Auf dem Papier spart eine gemeinsame Codebasis Aufwand, doch im Betrieb frisst die Kopplung die Vorteile auf. Das Netzwerk erzeugt addierte Last, und die zentrale DB muss jeden Peak abfangen. Gleichzeitig wachsen Wartungsfenster, weil mehr Sites gemeinsam betroffen sind. Ich sehe in Logs häufig Contention, wenn mehrere Sites parallel ähnliche Queries ausführen oder wenn Scheduler-Jobs kollidieren. Hier zeigt sich die Asymmetrie zwischen theoretischem Sparen und realen Latenzen.
Hosting-Limits richtig einschätzen
Shared-Hosting bremst Multisite oft früh aus, weil CPU-, Memory-, IO- und DB-Verbindungs-Limits für alle Sites gemeinsam greifen und so Spitzen hart drosseln. Managed-WordPress-Plattformen helfen mit Isolation, bleiben aber ein Mittelweg, sobald sehr unterschiedliche Workloads zusammenlaufen. Ich plane bei 50+ Sites separate Ressourcenpools oder Cluster je Site-Gruppe, um Störungen zu begrenzen. Darüber hinaus zahlt ein sauberer Cache-Plan ein: Edge, Full-Page, Object, Transients – jeweils mit klaren TTLs und Warmup-Routinen. Wer Full-Page-Layer klug nutzt, kann Full‑Page‑Cache skalieren und gerade Leselast wirksam abfangen.
Dezentral statt Monolith – Control-Plane-Ansatz
Ich bevorzuge eine Control-Plane, die den Code als Read-Only-Artefakt verteilt, während jede Site eigene Stacks für Web, PHP-FPM, Cache und DB nutzt und damit echte Isolation erhält. So kann ich pro Site gezielt skalieren, Fehler lokalisieren und Downtimes begrenzen. Deployments laufen zentral standardisiert, aber die Laufzeit bleibt getrennt. Dieses Setup verbindet Governance mit Unabhängigkeit und reduziert Kettenreaktionen. Die folgende Tabelle macht die Unterschiede greifbar und zeigt, warum ich Trennung im Betrieb favorisiere.
| Aspekt | Multisite (ein Verbund) | Isolierte Stacks pro Site |
|---|---|---|
| Datenbanklast | Addiert sich in einer gemeinsamen DB, Contention möglich | Getrennte DBs, Contention begrenzt auf einzelne Site |
| Fehlerauswirkungen | Ein Fehler kann viele Sites treffen | Fehler bleibt auf Projekt begrenzt |
| Skalierung | Gemeinsamer Engpass bei CPU/IO | Skalierung pro Site nach Bedarf |
| Caching-Strategie | Ein Layer für viele Sites, wenig Feintuning | Feintuning je Site, klare TTLs und Purge-Logik |
| Sicherheitsrisiko | Angriffsfläche geteilt | Blast-Radius klein |
| Deployments | Ein Update, viele Effekte | Canary je Site, graduelles Ausrollen |
| Cron/Wartung | Zentrale Queues, Verzögerungen möglich | Separate Queues, klar planbar |
Suchfunktion, Cache und Cron – typische Stolpersteine
Globale Suche über mehrere Sites klingt attraktiv, doch getrennte Indizes pro Site sind meist sauberer und zuverlässig. Für Cache-Strategien brauche ich pro Site differenzierte TTLs, Purge-Regeln und Pre-Warm-Prozesse. Sonst invalidiert ein Update unnötig Inhalte im gesamten Netzwerk. Beim Cron plane ich dedizierte Runner oder Queues, damit lange Aufgaben die Auslieferung nicht beeinflussen. Wer die Unterschiede zwischen Layers versteht, trifft bessere Entscheidungen – der Vergleich Page Cache vs. Object Cache verdeutlicht die Stellschrauben.
Kosten realistisch kalkulieren
Ich rechne Projekte gerne in Euro pro Monat pro Site, inklusive Hosting, Teamzeit für Releases, Monitoring und Incident-Response. Multisite wirkt anfangs günstiger, doch Netzstörungen verteuern die Rechnung schnell. Eine einzelne Stunde Ausfall für 30 Sites kostet mehr als eine zusätzliche Instanz pro Site-Gruppe. Budgets profitieren von klaren SLIs/SLOs und einem Error-Budget, das Release-Tempo steuert. Am Ende zahlt sich Planung mit Isolation häufiger aus als vermeintliche Ersparnis.
Wann Multisite Sinn ergibt – klare Kriterien
Ich setze Multisite gezielt ein, wenn viele ähnliche, nicht mission-kritische Sites zentral verwaltet werden sollen und die Anforderungen technisch homogen bleiben. Beispiele: schlanke Microsites für Kampagnen, Standardseiten in Bildungskontexten oder Publisher mit strikt durchgesetzten Designs. Hier zählt die zentrale Steuerung von Updates und Backups, ohne dass starke Unterschiede bei Plugins entstehen. Steigen Diversity, Traffic oder Integrationsgrad, kippt der Vorteil. Dann ziehe ich Isolation mit standardisierter Control-Plane vor.
Praxisleitfaden: Entscheidungslogik ohne Schönfärberei
Ich starte mit einer Inventur: Lastprofile, Query-Toplisten, Cache-Hitrate, Fehlerquoten und Release-Rhythmus. Danach gewichte ich Risiken: Wie groß darf der Blast-Radius sein, wie schnell müssen Teams handeln, welche Sites erfordern Sonderregeln. Dritte Stufe: Architektur-Entscheid – Multisite nur bei homogener Technik und niedriger Kritikalität, sonst Control-Plane mit isolierten Stacks. Vierte Stufe: Betriebsregeln – Monitoring je Site, Alerting mit klaren Eskalationen, Rollback-Pfade, Canary-Deployments. Fünfte Stufe: Kontinuierliche Überprüfung via SLO-Reports und Kosten pro Site.
Datenbank-Realitäten: Optionen, Autoload und Indizes
In Multisite entsteht Last oft in der Datenbank, ohne dass es auf den ersten Blick sichtbar ist. Jede Site besitzt eigene Tabellen, doch einige Pfade bleiben geteilt – zum Beispiel globale Metadaten. Problematisch sind große autoload-Optionen: Wird pro Site zu viel in autoloaded Optionen abgelegt, lädt PHP bei jedem Request Megabytes an Daten in den Speicher. Das erhöht Response-Zeiten, belastet Object-Cache und führt bei Peaks zu Memory-Pressure. Ich überprüfe daher regelmäßig die Größe von autoload = 'yes' Einträgen, räume Legacy-Optionen auf und verschiebe große Strukturen in gezielte Lazy-Loads.
Bei Indizes gilt: Standardindizes reichen oft nicht aus. Besonders postmeta und usermeta profitieren von zusammengesetzten Indizes (z. B. (post_id, meta_key)), wenn viele Meta-Queries laufen. Auch term_relationships und term_taxonomy verursachen Contention, wenn Taxonomie-Filter auf breiten Datenmengen liegen. Ich analysiere Slow-Query-Logs, prüfe Query-Pläne und klemme N+1-Queries ab, die durch unbedachte Loops in Themes/Plugins entstehen. Wichtig: In Multisite multiplizieren sich ineffiziente Queries – ein kleiner Fehler skaliert zum Netzwerkproblem.
Cache-Fallstricke bei eingeloggten Nutzern und E‑Commerce
Full-Page-Cache holt viel raus, verliert aber Wirkung, sobald Cookies im Spiel sind. Eingeloggte Nutzer, Warenkorb-, Session- oder Kommentar-Cookies führen oft zum Cache-Bypass. In Multisite reicht eine Site mit vielen eingeloggten Sessions, um den gesamten Stack zu stressen: Die gemeinsame PHP-/DB-Schicht wird warm gefahren, Edge- und FPC-Layer greifen seltener. Ich plane darum strikt: Vary-Regeln pro Site, saubere Trennung von dynamischen Blöcken (ESI/Fragment-Cache) und harte Limits für admin-ajax.php sowie chatty REST-Endpunkte. Für Checkout- und Account-Seiten gelten eigene Policies, während ich Leseseiten maximal cachen und separat vorwärmen lasse.
Dateien, Medien und Storage
In Multisite landen Uploads typischerweise unter /uploads/sites/{ID}. Das klingt ordentlich, führt aber in der Praxis zu IO-Hotspots, wenn Thumbnail-Generierung, Bildoptimierung und Backups gleichzeitig laufen. Liegen alle Sites auf einem zentralen Filesystem (NFS/Shared Volume), blockieren sich IO-Queues gegenseitig. Ich entkopple schwere Medien-Jobs in Hintergrundprozesse, begrenze Parallelität und prüfe die Auslagerung in objektbasierten Storage. Wichtig sind konsistente Pfade, saubere Rewrites und klare Regeln für Expiration-Header. In isolierten Stacks bleiben Medien-Spitzen lokal – das reduziert Auswirkungen auf andere Projekte erheblich.
Observability: Metriken, Traces und Lastprofile
Ohne messbare SLIs ist jede Skalierungsdiskussion Bauchgefühl. Ich messe P50/P95/P99 für TTFB und Gesamtzeit je Site, tracke Fehlerquoten, Cache-Hitrates und DB-Latenzen. Dazu kommen RED-/USE-Metriken (Rate, Errors, Duration bzw. Utilization, Saturation, Errors) pro Layer. Traces zeigen, welche Handlers/Queries dominieren, und helfen, noisy Nachbarn zu erkennen. Wichtig: Dashboards und Alerts pro Site – nicht nur fürs Netzwerk. So erkenne ich, wenn Site X die Connection-Pools füllt oder wenn Cron-Jobs von Site Y die CPU saturieren. Sampling und Log-Reduktion verhindern, dass Observability selbst zum Kosten- oder Performanceproblem wird.
Migration und Exit-Strategie: Von Multisite zu isolierten Stacks
Ich plane Multisite immer mit einem Exit. Die Schritte haben sich bewährt:
- Inventur: Domains, Nutzer, Plugins/Themes, Medienvolumen, Integrationen, Redirects.
- Code-Artefakt: Build einmal, verteile read-only. Konfiguration strikt per Environment.
- Daten-Export: Pro Site Inhalte und User sauber extrahieren, Medien synchronisieren, Upload-Pfade neu schreiben.
- Identitäten: Nutzer-Mapping, SSO/Session-Domains klären, Cookies pro Domain isolieren.
- Dual-Run: Staging mit Produktionsdaten, synthetische Tests, Canary-Traffic, Latenz- und Fehlervergleiche.
- Cutover: DNS/Edge-Umschaltung, Purge/Warmup, Monitoring eng stellen, Rollback-Pfade bereit.
- Nacharbeiten: Redirects, Broken-Links-Check, Indizes, Caches, Cron-Worker und Backups pro Site.
So reduziert sich Migrationsrisiko, und Teams gewinnen Autonomie ohne Wildwuchs bei Code und Prozessen.
Compliance und Mandantenschutz
Mandanten in einem Verbund sauber zu trennen, ist nicht nur Technik, sondern Compliance. Ich achte auf Datenlokation, Aufbewahrungsfristen, Zugriffstrennung und die Granularität von Backups. Ein Restore nur für Site A darf nicht Site B berühren – in Multisite ist das schwierig. Logs, Admin-Zugriffe und Secrets brauchen per-Site-Isolation. Gleiches gilt für WAF– und Rate-Limits: Eine harte Regel für das Netzwerk kann unschuldig andere Sites treffen. Isolierte Stacks erlauben differenzierte Policies, reduzieren jurische Risiken und erleichtern Audits.
Internationalisierung: Multisite vs. Plugin
Für Mehrsprachigkeit ist Multisite verführerisch, weil Domains/Subsites Sprachen trennen. Ich entscheide pragmatisch: Gibt es geteilte Inhalte, gemeinsame Komponenten und ähnliche Workflows, reichen oft Sprach-Plugins mit klaren Fallbacks. Weichen Märkte, Rechtstexte, Integrationen und Teams stark ab, spricht viel für getrennte Stacks – nicht zwingend Multisite. Wichtig sind hreflang, konsistente Slugs, Caching pro Sprache und ein Redaktionsteam, das den Workflow beherrscht. Sobald Märkte unterschiedlich skalieren, punktet Isolation mit besserer Planbarkeit.
Betriebsprozesse und Team-Skalierung
Skalierung scheitert häufig an Prozessen, nicht an Technik. Ich arbeite mit Release-Trains, Feature-Flags und klaren Wartungsfenstern. Changes laufen durch denselben Quality-Gate, aber Rollouts sind pro Site steuerbar. On-Call-Regeln folgen dem Blast-Radius: Wer trifft wen? Es braucht Runbooks für Cache-Purges, DB-Rollbacks, Cron-Stalls und Rate-Limits. Rechte sind minimal: Site-Admins verwalten Inhalte, Platform-Teams verwalten Stacks. So wächst die Organisation ohne, dass ein Super-Admin zum Flaschenhals wird.
Was bleibt: Entscheidende Einsichten
Multisite fühlt sich bequem an, doch die Kopplung macht Leistung und Betrieb anfällig, sobald Traffic, Vielfalt und Risiken steigen. Ich plane lieber kleine, isolierte Einheiten, die gezielt wachsen und deren Fehler begrenzt bleiben. Gemeinsamer Code ist sinnvoll, gemeinsame Laufzeit selten. Klare SLIs/SLOs, harte Limits und ein durchdachter Cache-Plan tragen mehr zur Geschwindigkeit bei als eine Monolith-Struktur. Wer langfristig denkt, setzt auf Isolation mit Standardisierung statt auf eine vermeintliche Abkürzung.
