Statische Veröffentlichung ohne großen Exporter-Server
Statische WordPress-Veröffentlichung mit Lambda-Workern skalieren
Der WordPress-Server kann sich auf die Quellseiten konzentrieren. Der Exporter koordiniert den Auftrag, während Lambda-Worker die in Stapel teilbaren Verarbeitungsschritte übernehmen.
WordPress-Quelle
↓ Seiten
Exporter-Koordination
├→ Lambda Rendering
├→ Lambda Asset-Abruf
├→ Lambda HTML-Umschreibung
└→ Lambda Bereitstellung
↓
S3-Arbeitsbereich → Ziel-S3 → CloudFront
Ausführungsgrenze
Der Exporter muss die rechenintensiven Schritte nicht selbst ausführen
Static Publisher führt Crawl und Deployment bereits außerhalb von WordPress/PHP aus. Mit Lambda-Delegation kann der Exporter zusätzlich Seitenrendering, Asset-Abruf, abschließende HTML-Umschreibung und Deployment an getrennte Lambda-Worker übergeben.
WordPress / Quellseite
│ liefert angeforderte Frontend-Seiten
▼
Exporter-Koordination
│ verwaltet Warteschlange, Sicherheit, inkrementelle Entscheidungen,
│ Manifeste, Wiederholungen, Protokolle und Endstatus
│
├─ Render-Stapel ─────→ Lambda + Chromium ─┐
├─ Asset-Stapel ──────→ Lambda ────────────┤
├─ Rewrite-Stapel ────→ Lambda ────────────┤→ S3-Arbeitsbereich
└─ Deployment-Stapel ─→ Lambda ────────────┘ │
└→ Ziel-S3 → CloudFront
Was das Seitenrendering weiterhin begrenzt Render-Worker rufen die Seiten weiterhin von der WordPress-Quelle ab. Mehr Lambda-Parallelität macht die Quelle daher nicht unbegrenzt schnell: WordPress-Kapazität, Lambda-Kontingente und Zielsysteme setzen weiterhin Grenzen. Asset-Abruf, Umschreibung und Deployment belasten WordPress nicht auf dieselbe Weise.
Ablauf
Rechenleistung nur während eines Veröffentlichungsauftrags nutzen
Das Worker-Modell trennt das ständig verfügbare Redaktionssystem von der kurzfristig benötigten Verarbeitungskapazität für die Veröffentlichung.
- WordPress stellt den Auftrag ein — WordPress speichert Konfiguration und Auftrag. PHP startet weder den Node-Exporter noch leitet es den Deployment-Datenverkehr weiter.
- Der Exporter koordiniert — Die Koordination zerlegt die Arbeit, wendet Sicherheits- und inkrementelle Regeln an und verfolgt Wiederholungen und Fortschritt.
- Verarbeitung stapelweise an Lambda delegieren — Lambda-Worker können Seiten rendern, Assets abrufen, Objekte im S3-Arbeitsbereich umschreiben und fertige Dateien zum Ziel kopieren. Ein warmer Chromium-Prozess kann mehrere Seiten nacheinander verarbeiten.
- Fertige Ausgabe bleibt in S3 — Bei vollständiger Delegation bleiben HTML und Assets im S3-Arbeitsbereich. Umschreibung und direkte S3-zu-S3-Bereitstellung erfolgen dort, ohne die fertige Ausgabe erneut über den Koordinator zu übertragen.
Wann Lambda-Delegation die Infrastrukturwahl verändert
Verarbeitung delegieren
Sinnvoll bei kurzen, parallelen Lastspitzen während der Veröffentlichung
- Der Exporter-Server soll nicht für den größten Veröffentlichungsauftrag dimensioniert werden.
- Genug Seiten oder Assets sind vorhanden, damit paralleles Rendering, Abrufen, Umschreiben oder Bereitstellen einen Unterschied macht.
- AWS-Rechenkosten sollen der tatsächlichen Veröffentlichungsarbeit folgen statt dauerhaft bereitgestellter Reservekapazität.
Lokal verarbeiten
Einfacher bleiben, wenn ein Exporter-Host bereits ausreicht
- Die Website ist klein und die Veröffentlichungsdauer akzeptabel.
- Die WordPress-Quelle kann zusätzliche parallele Seitenabrufe nicht sinnvoll bedienen.
- Ein dauerhaft laufender Worker-Host ist betrieblich einfacher und ein zusätzlicher Lambda-Stack nicht nötig.
Praxisfragen
Lambda-Delegation in Static Publisher
Entlastet Lambda WordPress vollständig?
Nein. Render-Worker rufen die Frontend-Seiten weiterhin von WordPress ab. Delegiert wird die Exporter-seitige Verarbeitung; die Quelle muss die zu rendernden Seiten weiterhin ausliefern.
Bleibt der Exporter nach der Delegation wichtig?
Ja. Er koordiniert Warteschlangen, Sicherheits- und inkrementelle Entscheidungen, Manifeste, Wiederholungen, Protokolle, Invalidierung und den endgültigen Auftragsstatus.
Braucht jede Veröffentlichung einen leistungsstarken Server?
Nein. Die Koordination kann vergleichsweise leicht bleiben, weil delegierte Phasen Lambda nur während der Arbeit nutzen. Kosten und Durchsatz hängen weiterhin von Konfiguration, AWS-Grenzen und der WordPress-Quelle ab.
Wo liegen die erzeugten Dateien bei vollständiger Delegation?
Gerendertes HTML und heruntergeladene Assets bleiben im S3-Arbeitsbereich. Dort kann die Umschreibung erfolgen; die fertigen Objekte werden anschließend direkt in den Ziel-S3-Bereich kopiert.
Static-Publisher-Architektur
WordPress als Quelle, nicht als Veröffentlichungs-Worker
Static Publisher trennt WordPress-Redaktion, Export-Koordination und optionale Lambda-Verarbeitung. Die Produktseite verbindet dieses Modell mit vollständiger, inkrementeller und gezielter Veröffentlichung.