Freitag 9:00 Uhr: Anmeldebeginn für eine Tagung mit 800 Plätzen. Um 9:03 Uhr zeigt die Site einen 503-Fehler an. Um 9:15 Uhr machen soziale Netzwerke bereits Screenshots. Das Kommunikationsteam gerät in Panik, das Technikteam startet Apache neu, „um zu sehen“, und niemand hat die Zahlungsseite unter echter Last getestet.
Eine Veranstaltungsseite ist kein Blog, der nach und nach wächst. Das ist ein komprimiertes Verkehrsfenster – manchmal nur ein paar Minuten – das Sie nicht wiedergeben können. Die richtige Frage lautet also nicht: „Welcher Host ist der beste?“ ", aber welche Seite muss unbedingt passen, zu welchem Zeitpunkt und mit welchem Plan B sichtbar?
Planen Sie den großen Tag, bevor Sie sich für das Angebot entscheiden
Beginnen Sie mit der Trennung der Flüsse:
| Futtermittel | Typische Belastung | Fehlertoleranz |
|---|---|---|
| Infoseiten (Programm, Referenten) | Stark, besonders im Lesen | Durchschnittlich – eine statische Fallback-Seite reicht aus |
| Registrierung / Ticketverkauf | Extremer Spitzenwert, schreibt die DB | Null – es ist das Kerngeschäft |
| Teilnehmerbereich (Badge, PDF) | Mäßig, nach dem Kauf | Niedrig |
| Partner-API / Eingabescan | Variiert | Niedrig am Veranstaltungstag |
Berechnen Sie dann das glaubwürdige Worst-Case-Szenario: Wie viele gleichzeitige Anfragen bei der Eröffnung? Wie viele Basisschreibvorgänge pro Sekunde? Ein Ticketbüro mit einer virtuellen Warteschlange stellt nicht die gleichen Anforderungen wie ein einfaches eingebettetes Google Forms-Formular.
Eine sinnvolle Größenbestimmung beginnt mit dem ersten beängstigenden Klick, nicht mit dem monatlichen Analytics-Durchschnitt.
Architektur: Trennen zwischen dem, was halten muss, und dem, was warten kann
Drei Muster, die in diesem Bereich funktionieren:
1. Aggressiv zwischengespeicherte Showcase-Seiten + isoliertes Backoffice. Programm, FAQ, Zugriffsplan: statisch oder über CDN mit langer TTL bereitgestellt. Das Ticketing läuft auf einer Subdomain oder einem dedizierten Dienst mit Verbindungspool und Redis-Sitzungen.
2. Explizite Warteschlange. Es ist besser, „Sie sind #847“ mit einer stabilen Website anzuzeigen, als mit einem unendlichen Spinner, gefolgt von einem 503. Lösungen wie eine statische Seite + JWT-Token oder ein dedizierter Warteschlangendienst verhindern, dass PHP-FPM auf einmal in die Luft gesprengt wird.
3. Vorübergehender Hochlauf. Bereiten Sie in der Cloud (OVH Public Cloud, Scaleway, Hetzner Cloud) ein Image oder einen Snapshot, ein Scale-out-Skript und vor allem eine automatische Rückkehr zur Normalität vor – andernfalls zahlen Sie für ein Juni-Event bis Dezember drei Server.
Hosting: Shared, VPS oder Elastic Cloud?
| Veranstaltungsprofil | Konsistentes Produkt | Warum |
|---|---|---|
| Konferenz < 500 Plätze, einfache Form | Bescheidenes VPS + CDN | Cron-Steuerung, PHP, Redis |
| Festival, Ticketverkauf durch Dritte (Eventbrite, Weezevent) | Geteilt oder statisch | Die kritische Last wird ausgelagert |
| Hausticketing, Spitzenwert > 1000 req/s | Cloud + Load Balancer | Elastizität und Isolierung DB |
| Integriertes Live-Streaming | Video-CDN + separater Ursprung | Der Videostream sollte PHP-FPM nicht teilen |
Shared scheitert am häufigsten an drei Einschränkungen: gleichzeitige MySQL-Verbindungen, PHP-FPM-Worker und mangelnde schnelle Skalierbarkeit. Hierbei handelt es sich nicht um eine Frage des „bösen Willens“ des Hosts, sondern um ein Modell, das auf einen reibungslosen Datenverkehr ausgelegt ist.
Beobachtbarkeit und Runbook: Der große Tag kann nicht improvisiert werden
Legen Sie zwei Wochen vorher Folgendes fest:
- Wer schaut sich was an: CPU, TTFB-Latenz, 5xx-Fehler, MySQL-Dateigröße, Redis-Verbindungen.
- Alarmschwellenwerte für Mobiltelefonnummern, nicht nur für E-Mails.
- Runbook schreibt: „if 503 > 2 min → statische Seite aktivieren / Suche deaktivieren / Worker erhöhen“.
- Fenster zum Einfrieren des Codes: Keine Bereitstellung am Vortag, es sei denn, der Hotfix wurde validiert.
Testen Sie die Wiederherstellung eines Basis-Backups – nicht „wir machen Backups“, sondern „hier ist die Zeit, um 8:55 Uhr den Ticketschalter aufzurufen“.
Der Höhepunkt: Der Höhepunkt ist vorhersehbar, der Zusammenbruch sollte es nicht sein
Das Versprechen „unbegrenztes Hosting“ ersetzt nicht den Auslastungstest, die Warteschlange oder die Fallback-Seite. Das Prestige des Rechenzentrums zählt weniger als die Mapping der ersten Viertelstunde.
Entscheide dich und gehe ohne blinden Fleck voran
- Identifizieren Sie die eindeutige Seite, die nicht fallen darf (häufig Zahlungs- oder Registrierungsvalidierung).
- **Den Rest mindestens 72 Stunden vor dem Öffnen zwischenspeichern oder statisch aufladen.
- Belasten Sie diese Seite mit einem realistischen Szenario (kein Bauchmuskeltest zu Hause).
- Dokumentplan B: statische Seite, Kommunikationsnachricht, Verlängerung der Verkaufsöffnung.
- Plan für den Abstieg: Verkleinerung, Rechnungsstellung, Archivierung von Protokollen.
Vergleichen Sie die elastischen Angebote in unserem Verzeichnis und im Vergleich. Informationen zum Cache-Bereich finden Sie unter Dynamischer Seiten-Cache: Entscheiden, was tatsächlich zwischengespeichert werden kann.
Häufig gestellte Fragen
Sollten wir den Server für den D-Day das ganze Jahr über überdimensionieren?
Nein. Verwenden Sie Cache, CDN, temporäre Skalierung oder elastische Architektur für Spitzenwerte und kehren Sie dann zu den normalen Kosten zurück.
Reicht gemeinsames Networking für einen Veranstaltungsort aus?
Selten für den Ticketverkauf oder die Eröffnung konzentrierter Registrierungen. Ein VPS, eine elastische Cloud oder eine statische Seite + separate API sind realistischer.
Wann muss das CDN für eine Veranstaltung aktiviert werden?
Sobald die Informationsseiten stabil sind – mehrere Wochen vorher. Am großen Tag überwachen Sie, Sie konfigurieren nicht mehr.
Was sollte vor Verkaufsbeginn getestet werden?
Belastungstest auf der kritischen Seite, grundlegende Fehlersimulation, Vorgehensweise zum Wechsel auf eine dokumentierte statische Seite.
Ein Ereignis lässt Sie mit nur einem Take zurück. Größe für diese Viertelstunde – und schlafen Sie die Nacht davor, weil das Runbook geschrieben wird, und nicht, weil der Server das ganze Jahr über überdimensioniert ist.