Bekijk Volledige Versie : Verschil tussen NGINX en Varnish (cache)
VersteggelM
21/04/18, 12:40
Voor een nogal goed bezochte site zijn wij op zoek naar nieuwe mogelijkheden en technieken voor het hosten van onze site.
Nu heb ik gekeken naar NGINX en Varnish en ik raak daar nogal van in verwarring. Wat is nu eigenlijk het verschil tussen deze twee? Ik weet dat NGINX ook een echt webserver is en sommigen zelfs beiden gebruiken maar ik raak er een beetje van in de war.
Waarom zou je de een over de ander kiezen? Of zelfs allebei tegelijktijd gebruiken? Ik hoop dat jullie experts mij een beetje op weg kunnen helpen.
Groeten,
Mike
Nginx is net als bijvoorbeeld Apache een webserver. Je zal altijd een webserver nodig hebben om je website te hosten. Daarnaast kan je Nginx ook als proxy gebruiken naar een andere applicatie, waarbij Nginx bijvoorbeeld SSL offloading doet (bijvoorbeeld voor Kibana). Varnish is een front-end cache. Deze benaderd je bestanden niet direct, maar cached blokken HTML die worden opgevraagd bij bijvoorbeeld Nginx/Apache. Varnish werkt met een VCL, een configuratiebestand die zegt wat er wel en niet moet worden gecached. De gratis versie van Varnish ondersteund echter geen SSL, dus zal je daarvoor nog een proxy server moeten zetten (bijvoorbeeld Nginx of HAProxy).
Dan krijg je iets van:
[bezoeker] <-> [haproxy/nginx] <-> [varnish] <-> [nginx/apache]
Ramon Fincken
22/04/18, 12:54
Nginx is een combinatie van webserver en proxy. Nginx kan zelfs emailverkeer proxien. Nginx kan cachen op (ram-)disk, maar ik ben er zelf niet zo een fan van.
Varnish is puur HTML/file cache (middels proxy naar een backendserver) en doet zijn opslag in het RAM geheugen.
Je kunt ze beiden inzetten op eenzelfde server voor optimaal resultaat :)
En .. Varnish is fatsoenlijk met if/else statements. Kun je bij Nginx wel vergeten. Voor een simpele If A AND B moet je al gekke toeren uithalen.
Welke problemen heb je nu of je verwacht je met de website?
Ik zou zelf niet zomaar caching gebruiken zonder te weten wat het doel is of waar je tegen aan loopt. Varnish is geen plug & play. Je moet goed nadenken over wat je vooral niet wilt in je cache wilt hebben. Soms is het goedkoper om 'gewoon' meer servers te starten en je load balancing op orde te hebben of om je dure server capaciteit niet te gebruiken voor het serveren van afbeeldingen.
Er zijn meerdere wegen naar Rome en alles is afhankelijk van je website en hoe deze nu werkt.
systemdeveloper
22/04/18, 21:56
Nginx is een webserver, net zoals apache met het verschil dat nginx niet met .htaccess kan omgaan. Dat betekent niet direct dat je de dingen van je .htaccess niet in nginx kunt doen, maar het is wel een stuk complexer.
Daarom draaien veel mensen nginx en apache tegelijk, waarbij nginx een proxy/cache rol heeft. De basis opzet daarvan is niet echt complex maar kan dat uiteindelijk wel worden natuurlijk.
Varnisch moet je zien als een plugin cache server die je vóór alles hangt. Varnish is erg goed in cachen en ook online zijn er vcl's te vinden waarvan 'wow' de beste beschrijving is. Complexer maar kan wel eenvoudig ingezet worden als caching loadbalancer. Varnisch kan ook op basis van voorwaarden geinige dingen zoals TTL's aanpassen, cookies strippen/toevoegen, etc.
Vervolgens kun je nog kiezen voor een varnisch + nginx frontend en apache backend. In zo'n setup kun je nginx gebruiken tbv SSL offloading waarbij https requests op nginx binnenkomen en je cert gechecked wordt, waarna nginx de request naar varnisch doorstuurt als http (zonder s) en varnish in zijn cache checked of desnoods op de apache backends bv een pagina ophaalt. Varnisch cached default op file basis maar kan dat ook doen in ram.
Als je dit een beetje leuk opzet, kun je responsetijden bereiken die belachelijk laag zijn.
Een klant heeft ons zelfs eens gevraagd om een site trager te maken omdat de dynamische pages bij de bezoeker binnen 200ms geladen waren. Persoonlijk wel trots op, maar het bleek dat de adsense pas 0,5/1 seconde later getoond werd en de klant gewoon omzet verloor :/
Je kunt leuke dingen doen, maar het is de complexiteit niet altijd waard. Met 5-6000 concurrent bezoekers heb je weinig keus, maar als je maar 1000 bezoekers per dag hebt, dan heb je meer kans dat de meeste requests al hun cache ttl verstreken hebben voordat ze weer opnieuw opgevraagd worden. (Tenzij je de mogelijkheid hebt om 'dynamische' pages erg lang te cachen)
VersteggelM
23/04/18, 16:49
Ik was het weekend even van het zonnetje genieten net zoals de meeste Nederlanders geloof ik.
Maar hier kan ik wat mee mensen, heel erg bedankt voor al jullie antwoorden.
Ons platform (LAMP installatie) heeft gemiddeld zo'n 10.000 bezoekers/gebruikers tegelijkertijd te verwerken en dat gaat op zich wel goed maar we merken dat we tegen bepaalde limieten aan beginnen te lopen. Op dit moment zijn we dan ook bezig met het tweaken van PHP en MySQL en daarna kunnen we gaan kijken naar de andere opties.
Het is dus niet zozeer dat we nu al tegen problemen aanlopen maar we willen gewoon voorbereid zijn.
Ramon Fincken
23/04/18, 19:31
Wat voor app is het ? Want als het vereist dat men met cookies en/of in moet loggen kan caching in varnish vies tegen vallen. Tenzij er ook veel files bij komen kijken zoals plaatjes en dergelijke
systemdeveloper
23/04/18, 20:35
Wat voor app is het ? Want als het vereist dat men met cookies en/of in moet loggen kan caching in varnish vies tegen vallen. Tenzij er ook veel files bij komen kijken zoals plaatjes en dergelijke
Heel strikt genomen heeft varnish een default (built-in rule) om requests met Cookie of Authorization headers niet te cachen. Maar varnish doet doet omdat mensen niet fatsoenlijk een app kunnen bouwen en niet of foutief gebruik maken van cache headers en cookiedomeinen (ok, dat vergt ook wel een paar hersencellen meer).
Een cookie heeft namelijk vrij weinig met caching te maken. Zodra je ingelogd bent op een site heb je meestal maar een beperkt aantal pages waarvoor dat cookie nodig is. Alle andere pages die je ook kunt bezoeken zonder ingelogd te zijn, kunnen nog steeds perfect gecached worden.
Een truc is, indien je backend goed gebouwd is, om in de vcl de Cookie: header te renamen. Dan trigger je de built-in 'do not cache when Cookie' rule niet en kun je alsnog pages uit de cache teruggeven.
Dit betekent wel dat je tussen varnish en je app een 'trust' relatie moet hebben en goed moet nadenken wat je doet. (maar dat doen we allemaal toch?). Het betekent ook dat je de Authorization: header moet gebruiken voor.. nou ja... de autorisatie pages (bearer maar ook de oudere basic/digest tokens).
Voor juist en doordacht maatwerk kan dat je performance goed en veilig boosten. Zomaar op shared hosting mikken en je kunt je GPDR compliance wel vergeten ;)
Als je voorbereid wilt zijn moet je testen en vooral goed meten. Als je geen explosieve groei hebt of verwacht kun je ook goed testen wat de impact is van een wijziging zonder load test trouwens. Ook dan moet je goed meten.
Varnish wordt te pas en te onpas genoemd als oplossing (of als eis). Vaak totaal onnodig.
Het profilen van je applicatie met New Relic kan helpen bij het vinden van pijnpunten in je website. Dan kun je gericht je website verbeteren. Het zijn soms de kleine dingen maar het belangrijkste is altijd om te meten wat je verandering doet.
VersteggelM
30/04/18, 13:29
Dank allen voor de reacties! :lovewht:
Wat voor app is het ? Want als het vereist dat men met cookies en/of in moet loggen kan caching in varnish vies tegen vallen. Tenzij er ook veel files bij komen kijken zoals plaatjes en dergelijke
Het is een combinatie van forum, chat en webshop (internationaal). Er gebeurt nogal wat de hele dag door en ja veel lees en schrijfacties naar de database (extern) per seconde. Ik mag helaas niet noemen waarover het gaat.
We zijn ons wel bewust van wat er is maar nog niet van wat we nodig hebben en daar zijn we ons een beetje aan het orienteren.
En New Relic, leuk maar prijzig. Niet dat het niets mag kosten...
Ramon Fincken
30/04/18, 14:24
hoegroot is je pagina in MB ? hoeveel files vanaf jullie server ?
Dat men hier aangeeft dat Nginx niet geschikt is als caching en tegenwoordig helemaal niet meer waar. Uit sommige tests blijkt zelfs dat Nginx in "sommige" gevallen beter performed dan Varnish.
Het is per applicatie echt totaal verschillend wat de beste oplossing is. Wij hebben nog enkele Varnish omgevingen draaien maar doen tegenwoordig steeds meer op puur Nginx.
Op pieken doen we 150K concurrent users op basis van een Nginx cache.
golden om wat voor website gaat het? Als je bijvoorbeeld e-commerce doet, hoe gaan jullie om met een winkelwagentje? Het is juist leuk om dan ook wat technische details te horen. Dat geeft TS ook een beter idee of het past bij de website waar het nu om gaat.
De BBC heeft trouwens een paar jaar terug een artikel geschreven over Nginx vs. Varnish in hun eigen omgeving:
http://www.bbc.co.uk/blogs/internet/entries/17d22fb8-cea2-49d5-be14-86e7a1dcde04
Ramon Fincken
03/05/18, 07:46
golden om wat voor website gaat het? Als je bijvoorbeeld e-commerce doet, hoe gaan jullie om met een winkelwagentje? Het is juist leuk om dan ook wat technische details te horen. Dat geeft TS ook een beter idee of het past bij de website waar het nu om gaat.
De BBC heeft trouwens een paar jaar terug een artikel geschreven over Nginx vs. Varnish in hun eigen omgeving:
http://www.bbc.co.uk/blogs/internet/entries/17d22fb8-cea2-49d5-be14-86e7a1dcde04
Even snel gescanned, en het ging mis bij dus veel grote files. Dan gaat nginx inderdaad beter zijn. Maar als ik lees wat voor site TS heeft is dat niet van toepassing.
VersteggelM
09/05/18, 16:34
Is het te voorbarig om te concluderen dat jullie er zelf ook niet echt helemaal uit zijn?
Wat ons nu wel duidelijk is dat het wel belangrijk is om precies in kaart te brengen wat er nu eigenlijk gebeurd en waar de eventuele bottlenecks zitten of zijn te verwachten en dat NGINX en Varnish ieder op hun eigen manier een oplossing kunnen leveren voor een probleem.
systemdeveloper
09/05/18, 20:39
Is het te voorbarig om te concluderen dat jullie er zelf ook niet echt helemaal uit zijn?
Wat ons nu wel duidelijk is dat het wel belangrijk is om precies in kaart te brengen wat er nu eigenlijk gebeurd en waar de eventuele bottlenecks zitten of zijn te verwachten en dat NGINX en Varnish ieder op hun eigen manier een oplossing kunnen leveren voor een probleem.
Ach, ik ben er wel uit. Maar het is natuurlijk wel dat andere oplossingen misschien bij jou beter werken. Dat is het leuke aan dit vak. Als er 1 goede oplossing was voor alles dan waren we snel klaar met innoveren, haha.
Maar optimaliseren begint altijd met goed inzicht hebben in wat er gebeurt, waar je traffic stromen zitten en wat de levensduur en privacy nivo van die stroom is. Voor al die punten ga je een lijst af van mogelijke optimalisaties (code aanpassen, opcache, memcache/redis, page cache, image ofloading, minifying etc...etc...) en kiest 1 of meer die op die bottleneck van toepassing zouden kunnen zijn.
Zo heb je redelijk snel een overzicht van welke 'tools' je kunt gebruiken, wat je kunt combineren en hoeveel winst je verwacht te maken in performance als je optimalisatie lukt. Dit staat en valt natuurlijk met de kennis/ervaring waar je uit kunt putten. Weten wanneer een bepaalde oplossing niet meer werkt en wanneer wél pas. En ook gewoon veel proberen natuurlijk en open staan voor nieuwe oplossingen. Als je 'vast' zit aan bepaalde software of er niet eenvoudig aanpassingen aan kunt laten doen, heb je ook direct al een stuk minder mogelijkheden.
Het is niet zomaar varnish óf nginx :)
VersteggelM
12/05/18, 12:58
We hebben inmiddels wel in de gaten dat er vele factoren zijn waar we naar moeten kijken en voorlopig gaan we het stap voor stap bekijken. Uiteindelijk zullen we wel een externe partij gaan inschakelen.
Frappant is wel dat we via persoonlijke berichten meer tips en aanbiedingen hebben gehad dan via het openbare forum zelf. Bedankt voor de hulp maar ik snap even niet zo goed waarom het allemaal zo geheim moet gaan. Het lijkt wel of er issues spelen binnen jullie branche en dat vinden wij apart te noemen.
Aanbiedingen via PM is in ieder geval niet de bedoeling. Die mag je gerust rapporteren.
Succes met de keuze!
VersteggelM
15/05/18, 12:42
Het waren niet enkel aanbiedingen maar ook gewoon tips die blijkbaar niet met iedereen gedeeld mogen worden. Wij wisten niet dat dit allemaal zo gevoelig ligt bij iedereen en denken wij dat dit soort dingen juist wel geshared moet worden.
We gaan er nog rustig over nadenken iig. Bedankt allemaal voor de feedback!