Vrijdag 9.00 uur: inschrijving geopend voor een congres met 800 plaatsen. Om 09:03 uur geeft de site een 503-fout weer. Om 9.15 uur maken sociale netwerken al screenshots. Het communicatieteam raakt in paniek, het technische team start Apache opnieuw op "om te zien", en niemand heeft de betalingspagina onder echte belasting getest.
Een evenementensite is geen blog die geleidelijk groeit. Dat is een gecomprimeerd verkeersvenster (soms slechts een paar minuten) dat u niet opnieuw kunt afspelen. De juiste vraag is dus niet “welke host is de beste?” ", maar welke pagina moet absoluut passen, op welk tijdstip, en met welk plan B zichtbaar?
Breng de grote dag in kaart voordat je voor de aanbieding kiest
Begin met het scheiden van de stromen:
| Voer | Typische belasting | Fouttolerantie |
|---|---|---|
| Infopagina's (programma, sprekers) | Sterk, vooral in lezen | Gemiddeld — een statische reservepagina is voldoende |
| Registratie / ticketverkoop | Extreme piek, schrijft DB | Nul – het is de kernactiviteit |
| Deelnemersgedeelte (badge, pdf) | Matig, na aankoop | Laag |
| Partner API / invoerscan | Varieert | Laag op evenementendag |
Bereken vervolgens het geloofwaardige worstcasescenario: hoeveel gelijktijdige verzoeken bij opening? Hoeveel basisschrijfbewerkingen per seconde? Een ticketkantoor met een virtuele wachtrij heeft niet dezelfde behoeften als een eenvoudig ingebed Google Formulierenformulier.
Nuttige maatvoering begint vanaf de eerste enge klik, niet vanaf het maandelijkse Analytics-gemiddelde.
Architectuur: scheiden van wat moet blijven en wat kan wachten
Drie patronen die in het veld werken:
1. Agressief in de cache opgeslagen showcasepagina's + geïsoleerde backoffice. Programma, FAQ, toegangsplan: statisch aangeboden of via CDN met lange TTL. Ticketing draait op een subdomein of een speciale service met verbindingspool en Redis-sessies.
2. Expliciete wachtrij. Het is beter om “jij bent #847” weer te geven met een stabiele site dan een oneindige spinner gevolgd door een 503. Oplossingen zoals een statische pagina + JWT-token of een speciale wachtrijservice voorkomen dat PHP-FPM in één keer wordt opgeblazen.
3. Tijdelijke opstart. Maak in de cloud (OVH Public Cloud, Scaleway, Hetzner Cloud) een image of snapshot, een scale-out-script en vooral een geautomatiseerde terugkeer naar normaal — anders betaal je tot december voor drie servers voor een evenement in juni.
Hosting: gedeeld, VPS of elastische cloud?
| Evenementprofiel | Consistent product | Waarom | |
|---|---|---|---|
| Conferentie < 500 plaatsen, eenvoudig formulier | Bescheiden VPS + CDN | Croncontrol, PHP, Redis | |
| Festival, ticketverkoop van derden (Eventbrite, Weezevent) | Gedeeld of statisch | De kritische last wordt uitbesteed | |
| Huisticketing, piek > 1000 req/s | Cloud + load-balancer | Elasticiteit en isolatie DB | |
| Geïntegreerde livestreaming | Video CDN + aparte oorsprong | Videostream mag PHP-FPM | niet delen |
Gedeeld mislukt het vaakst op drie limieten: gelijktijdige MySQL-verbindingen, PHP-FPM-workers en gebrek aan snelle schaalbaarheid. Dit is geen kwestie van “kwade wil” van de kant van de host – het is een model dat is ontworpen voor soepeler verkeer.
Waarneembaarheid en draaiboek: de grote dag kan niet worden geïmproviseerd
Stel twee weken van tevoren het volgende in:
- Wie kijkt naar wat: CPU, TTFB-latentie, 5xx-fouten, MySQL-bestandsgrootte, Redis-verbindingen.
- Waarschuwingsdrempels met mobiele nummers, niet alleen met e-mails.
- Runbook schrijft: "als 503 > 2 min → statische pagina activeren / zoeken deactiveren / werknemers verhogen".
- Bevriezingsvenster code: geen implementatie de dag ervoor, tenzij hotfix gevalideerd.
Test het herstellen van een basisback-up - niet "we maken back-ups", maar "dit is het moment om om 8:55 uur naar het loket te gaan".
De piek: de piek is voorspelbaar, de uitsplitsing zou dat niet moeten zijn
De ‘onbeperkte hosting’-belofte vervangt niet de laadtest, de wachtrij of de reservepagina. Het prestige van het datacenter doet er minder toe dan de mapping van het eerste kwartier.
Beslis en ga vooruit zonder blinde vlek
- Identificeer de unieke pagina die niet mag vallen (vaak betalings- of registratievalidatie).
- Cache of statisch de rest minimaal 72 uur vóór opening.
- Belastingstest deze pagina met een realistisch scenario (geen ab-test thuis).
- Documentplan B: statische pagina, communicatiebericht, verlenging van de verkoopopening.
- Plan voor de afdaling: afschalen, factureren, archiveren van logboeken.
Vergelijk de elastische aanbiedingen in onze overzicht en de vergelijking. Voor het cachevenster, zie Dynamische paginacache: beslissen wat daadwerkelijk in de cache kan worden geplaatst.
Veelgestelde vragen
Moeten we de server het hele jaar door te groot maken voor D-Day?
Nee. Gebruik cache, CDN, tijdelijke schaling of elastische architectuur voor pieken en keer vervolgens terug naar de normale kosten.
Is gedeeld netwerken voldoende voor een evenementensite?
Zelden voor ticketverkoop of opening van geconcentreerde registraties. Een VPS, elastische cloud of een statische pagina + aparte API is realistischer.
Wanneer moet ik het CDN voor een evenement activeren?
Zodra de informatiepagina's stabiel zijn - enkele weken eerder. Op de grote dag monitor je, configureer je niet meer.
Wat moet u testen voordat de verkoop begint?
Laadtest op de kritieke pagina, basissimulatie van fouten, procedure voor het overschakelen naar een gedocumenteerde statische pagina.
Een evenement geeft je slechts één take. Grootte voor dat kwartier – en slaap de nacht ervoor omdat het runbook is geschreven, niet omdat de server het hele jaar door te groot is.