Varnish transformeert een mediasite: 90% hitcache, oorsprong bijna inactief, processorrekening gedeeld door drie. Vervolgens logt een redacteur in, publiceert een dringende oplossing - en anonieme mensen zien nog steeds de oude titel omdat het opschonen alleen de artikel-URL beïnvloedde, en niet de startpagina met de tag 'listing-news'.
Dit scenario illustreert de aard van Varnish: het is geen beheerd CDN, het is een HTTP-beleidsengine. Je schrijft in VCL wat hetzelfde is, wat anders is, en wat er gebeurt als er een session_id cookie verschijnt. Slecht beheerst, het is de snelste cache om de slechte waarheid te dienen.
Vóór Varnish is de vraag niet "hoeveel RAM?" » maar “is een ingelogde gebruiker een cachevariant of een uitzondering?”
Op een media- of e-commercesite varieert de respons per pagina: een openbaar artikel kan in de cache worden opgeslagen, de kop van het lid in een privéfragment, het winkelwagentje wordt altijd overgeslagen. Zonder deze geschreven matrix wordt de VCL een reeks post-incidentoplossingen.
Mentaal model: hash, pass, miss
| VCL-besluit | Effect |
|---|---|
retour (hash) | Zoeken/opslaan in cache |
retour (pas) | Oorsprong, geen blinde |
retour (pijp) | Ruwe tunnel |
retour (synth) | Synthetische respons (onderhoud) |
Huidige stroom: zoekopdracht → vcl_recv; sessiecookie → pas; POST/PUT → geslaagd; anders → hash met URL-sleutel + taal + anoniem segment; druk op → bezorgen; missen → oorsprong → TTL in vcl_backend_response.
Vernis dwingt je te antwoorden: is een ingelogde gebruiker een cachevariant of een uitzondering?
Verbonden gebruikers: drie patronen
Patroon 1 — totale omzeiling bij cookiesessie
if (req.http.Cookie ~ "PHPSESSID") {
retour(pas);
}
Eenvoudige, veilige, drukkere oorsprong voor leden.
Patroon 2 — hash-segmentatie
Dezelfde URL, twee role=member versus anon-vermeldingen. Risico: te veel variaties.
Patroon 3 — ESI (inclusief randzijde)
Cachebare shell plus fragment <esi:include src="/private/header"> in pass. Krachtig, complex.
PURGE, BAN en surrogaatsleutels
| Operatie | Reikwijdte | Gebruik |
|---|---|---|
| PURGE-URL | Een voorwerp | Gewijzigd artikel |
| BAN-expressie | Patroon | ban("req.url ~ /nieuws/") |
| Surrogaatsleutelverbod | Logische tag | ban("obj.http.Surrogate-Key ~ artikel-123") |
Oorspronkelijke header: Surrogate-Key: artikel-123 listing-home. Bij CMS-publicatie → ban tag article-123 plus listing-home. Zonder tags PURGEER je met de hand – vergetelheid gegarandeerd.
TTL, gratie en muf
TTL: nominale versheid. Grace: serveer een verlopen versie tegen een lage prijs - handig op piekmomenten, gevaarlijk bij aandelenkoersen. Voor e-commerce: korte of geen respijt op prijspagina's.
Met de genade kun je een verouderde versie serveren terwijl de oorsprong traag is – handig in piekmedia, gevaarlijk voor prijs of voorraad. Documenteer het beleid per paginatype: blogpost tolereert tien seconden oudheid; productblad met beperkte voorraadnr.
Hosting en grootte
Varnish verbruikt veel RAM: reken op ongeveer 1-2 GB plus de cacheobjectgrootte. Op VPS: speciale instantie als het hitpercentage groter is dan 70%; monitor varnishstat — cache_hit, n_lru_nuked. Gedeeld: Vernis niet beschikbaar; Gedeeltelijke edge CDN zonder fijnkorrelige VCL-controle. Zie Dynamische paginacache en CDN of origin-optimalisatie. Zonder een team dat de VCL onderhoudt, kan een beheerd CDN met vooraf gedefinieerde regels veiliger zijn dan een slecht afgestelde lak.
The Summit: Varnish beloont degenen die hun publiek kennen
Beslis en ga vooruit zonder blinde vlek
Begin met het inventariseren van de cookies en routes die altijd moeten worden omzeild. Versie de VCL in Git en test het opnieuw laden vóór elke release. Sluit de surrogaatsleutels van het CMS aan om te zuiveren zonder handmatig PURGE. Valideer ten slotte het anonieme versus ledengedrag op de startpagina, het account en het winkelmandje, en controleer vervolgens het hitpercentage en de mislukte bans gedurende een week.
Veelgestelde vragen
Verbergt Varnish pagina's met sessiecookies?
Standaard nee: de aanwezigheid van een sessiecookie zou een bypass of gesegmenteerde hash moeten activeren. Geef nooit een ledenpagina weer aan een anonieme bezoeker, zelfs niet als de VCL er “bijna” correct uitziet.
Verschil tussen pass, pipe en cache?
In de cachemodus wordt het antwoord opgeslagen. Pass-modus ondervraagt de oorsprong zonder op te slaan. In de Pipe-modus wordt de onbewerkte verbinding getunneld – handig voor typische niet-HTTP-stromen.
Hoe opschonen na update?
Gebruik gerichte PURGE of BAN, of beter nog een geautomatiseerde Surrogate-Key-ban uit het CMS voor elke publicatie. Vermijd globale opschoningen die tijdens piekuren de volledige cache leegmaken.
Vernis voor nginx of andersom?
De klassieke architectuur plaatst Varnish aan de voorkant, vervolgens nginx en vervolgens PHP-FPM. Vernis absorbeert repetitief verkeer; nginx beheert de applicatiedetails en headers die de VCL niet mag breken.
Varnish versnelt wat u besluit hetzelfde te blijven; de rest is uw VCL-verantwoordelijkheid, gedocumenteerd en getest vóór elke grote redactionele campagne.