Varnish på webbhotell (flyttade inlägg från Webbhotell och prestanda?)
 

För det mesta har du ett antal php processer att tillgå på ett konto, där varje process har en visst antal request tillåtna per sekund, men problemet är ju också att denna info inte räcker för att beräkna hur många sidvisningar och besökare din sida kan ta eftersom det också beror på hur snabbt eller effektivt ditt php skript exekverar. Varnish påverkar ofta inte så mycket, då flaskhalsen inte ligger så mycket på statiska filer utan på dynamiskt innehåll som php utgör, tillgång till memcached (spara sql data på minne) och xcache (opcode cache) eller liknande däremot påverkar i stor utsträckning. Man sätter sällan varnish att cacha php filer, men det går att döpa om php exekverarade filer till .html filer och på så sätt få varnish att på ett enkelt sätt att cacha innehållet. Problemet dock, är att man då får varnish att cacha lite för mycket och lösningen är då att du behöver få tillgång till att själv skapa en anpassad varnish config om detta ska fungera på ett bra sätt, saken är väl då att de flesta webbhotell, utom några få, inte tillåter dig att ha en egen varnish vcl fil.

Oj vad många fel det är i där inlägget... Förvånande för att komma ifrån dig måste jag säga.

Varnish är extremt bra för att avlasta PHP och genereringen av html för de allra flesta sidor. Just det är i min värld den främsta anledningen till att man har en cachande reverse proxy framför webbservrarna. Så du kan, enligt mig, inte ha mer fel där...

Jag sätter mer eller mindre alltid Varnish på att cacha även genererad HTML. Det gör väldigt mycket mer för prestandan än vad både memcached och opcode cache gör för de flesta typer av sidor. Ju tidigare man cachar desto bättre både för responstid och för skalning. Hur sidor ska cachas kan man styra hyfsat bra med HTTP headers (Expires, Last-modified, no-cache etc). Även om webbhotell har en "dum" varnish cache framför som bara cachar i 5 min så gör det ju ändå enorm skillnad för backenden för en vältrafikerad sida om man bara behöver generera samma sida en gång var 5:e minut jämfört med att generera varje request.

Alla sidor och all typ av innehåll lämpar sig givetvis inte för att cachas av varnish men jag skulle nog säga att minst 90% av sidor är lämpliga att cacha i varnish i minuter eller mer. Det är få typer av sidor som behöver realtidsuppdateringar.
För en blogg med många och frekventa kommentarer är det väl kanske gränsfall, men att det tar 5 minuter för kommentarerna att synas är ju inte någon katastrof. Just kommentarer kan man ju även ladda in asynkront utan större problem, exempelvis med Disqus.

Lätt och slänga ur sig att någon har fel, utan att exakt förklara vad som är fel, vilket jag inte tycker du har gjort. Jag sa inte att man inte kan använda varnish för att avlasta php, sa bara att man inte speciellt ofta gör det, och inte gör det på ett effektivt sätt. Kan man inte anpassa vcl filen på ett bra sätt får du aldrig riktigt till det bra. Du säger ju själv "Alla sidor och all typ av innehåll lämpar sig givetvis inte för att cachas av varnish" Standard config på varnish cachar inte .php filer, det var ju därför jag sa: "Man sätter sällan varnish att cacha php filer, men det går att döpa om php exekverarade filer till .html filer och på så sätt få varnish att på ett enkelt sätt att cacha innehållet." Vad är det jag har sagt som är fel?

Jag tyckte att jag förklarade ganska hyfsat i förra inlägget, men jag kan absolut förklara mer.
Jag är ganska säker på att i princip alla som använder Varnish(åtminstone de som gjort ett aktivt val och inte har det på sitt webbhotell t.ex.) cachar även den genererade HTML:en så där är jag ganska säker på att du har du fel. Jag tycker det är relativt sällan man ser ".php" i URL:en överhuvudtaget nuförtiden, och det är speciellt sällsynt för större sidor som ändå är den primära målgruppen för Varnish. I princip alla större sidor och de flesta små använder någon form av rewrite regler som döljer filändelserna. Oftast kör man med en front-end-kontroller som routar trafiken till rätt fil(dvs alla requests går genom index.php).

Ja, det stämmer. Men i samma mening sa jag att 90% lämpar sig för det så där tar verkligen det där ur sitt sammanhang.

Börja med att se ovan angående .php-filer. Sedan tror jag att de flesta som tar sig tiden att faktiskt sätta upp Varnish framför sin webbserver vet vad det gör och även lägger lite tid på att konfigurera det för att få bättre prestanda som i de allra flesta fallen är anledningen till att man installerar Varnish till att börja med.
Sedan har jag har nog aldrig hört om någon som döpt om filändelsen på php-filer för att få de att cachas i Varnish...

Jag tycker det mesta som du skrivit här angående Varnish varit mer eller mindre fel.

Det bästa är ju som sagt att cacha datan så tidigt som möjligt i serverstacken. Ju djupare ned i din miljö du måste för att hämta datan ju längre tid tar det och ju dyrare är det att serva requesten. Det dyraste är att läsa in data som ligger på disk, i synnerhet ifrån databaser. Kan du istället serva hela HTML-dokumentet direkt ifrån RAM-minnet genererat och klart så går det ju väldigt mycket fortare och kräver endast en bråkdel av serverresurserna.
Om du exempelvis kan serva 50% av dina HTML-dokument direkt i från cachen i Varnish så har du halverat antalet requests som når dina webbservrar och därmed i princip halverat din serverlast. På vältrafikerade sajter brukar man kunna få över 95% cache hits i Varnish vilket gör att det är är mindre än 5% av alla request som ens tar sig ned till webbservrarna. Vad det innebär för belastningen på både webbservrar och databasservrar är det ju inte så svårt att räkna ut. Varnishservrarna är extremt effektiva och kan i de flesta serva tusentals requests per sekund med minimal hårdvara. Inget av det här kommer du i närheten av om du bara använder applikationscache(t.ex. Memcached) och opcode(t.ex. APC eller xCache) även om du såklart gärna kan kombinera och köra allt för att få en ännu effektivare miljö.

Det är nog det som gör att du tycker jag har fel vilket jag själv inte tycker, du blandar ihop de som kör vps/dedikerat med de webbhotell som har varnish och där man normalt inte kan ändra sin vcl-fil och jag har inte gått in på något annat än webbhotell med varnish, vilket hela tråden handlar om, webbhotell och prestanda.

Nej, det var många andra saker som jag reagerade mer över.
Webbhotellen använder väl knappast standardconfig? Jag har dock inte koll på exakt hur de är konfigurerade.
Så visst, du har en poäng där, men läste du verkligen resten av inlägget?

Du kan som sagt styra en del genom att skicka rätt HTTP-headers och det är numera relativt få sidor som faktiskt visar ".php" i URL:en med tanke på att i princip alla ramverk och CMS:er som finns har stöd för att enkelt få till "pretty URLs" med rewrites.

När du säger att Varnish "inte påverkar så mycket" kunde du inte ha mer fel. Det är min bestämda åsikt.

Då missförstod du mig, varnish kan visst avlasta och snabba upp, det är ju därför vi själva erbjuder varnish, men eftersom du inte kan cacha allt dynamiskt php innehåll så påverkar memcached och tex. xcache mer i de fallen.

Standard config på varnish gör inte skillnad på .php och .html eller några andra filändelser heller för den delen: https://www.varnish-cache.org/trac/b...lt.vcl?rev=3.0

Vidare finns det inget i den som säger att den cachar "statiskt" innehåll bättre än något annat. Det beror på vad webbservern skickar för headers för statiskt innehåll. Det kan du dock styra själv både för statiska (.htaccess) och dynamiska filer (egna headers) på de flesta webbhotell. Det enda stora problemet med varnish med delad generisk config blir att du inte kan hantera cookies som backend behöver på ett bra sätt.

Sen vet jag inte om du har rätt i att webbhotellen sätter varnish till att explicit inte cacha .php requests. Det vore isåfall ofantligt dumt. Att tillåta användaren att kontrollera det med cache headers det vore det ända acceptabla.

Vidare finns det inget (opcode cache, query cache, key-value stores, snabb webbserver osv) som kan göra så mycket för prestandan som en bra setup med varnish (eller motsvarande mjukvara!) även om man har en delad vcl - som inte är klantigt uppsatt.

På en vanlig hemsida kan du cacha i princip allt, det handlar bara om att sätta vettiga TTL:s på datan eller att du har möjlighet att skriva över cachen när du vill. Att skriva över cachen brukar tyvärr inte vara möjligt i delade miljöer vilket är synd, men om man kan styra beteendet med HTTP-headers(främst expires headern) kommer man ganska långt. Allt statiskt innehåll kan man sätta lång TTL på, speciellt om man har någon cache-busting teknik som t.ex. att ha en versionsvariabel, en timestamp eller något derivat av en timestamp i filnamnet för kringgå cachen. När det gäller genererad HTML brukar någonstans mellan 1-10 minuter vara en bra avvägning mellan prestanda och snabba uppdateringar av innehållet.

Precis som Clarence säger så finns det inget som slår Varnish eller någon annan cachande reverse proxy-lösning(t.ex. Nginx eller Squid) när det gäller prestanda även i delade miljöer.

Fast det är ju ändå inte det jag säger att varnish inte gör enormt stor skillnad, varför skulle vi då satsa på varnish i så fall? Vad jag har försökt att säga är att man kan inte ha en seg php backend och tro att man kan fixa till det med varnish, för då hade ju alla siter på tex. one.com flugit fram, för där har man vad jag förstår supertrimmat varnish.

Nja, nu drar du nog lite förhastade slutsatser. One.com satsar på så låga priser som möjligt och då försöker man rimligtvis också trycka in så mycket som möjligt på så få maskiner som möjligt. Varnish gör inte per automatik att sajter går snabbare på ett webbhotell utan det kan lika gärna vara ett sätt för webbhotellen att kunna hålla nere kostnaderna. Alla de stora tävlar idag snarare med priser och överförsäljning snarare än prestanda.

Är det här en gammal diskussion som flyttats till en ny tråd eller varför är första inlägget så rörigt? Jag orkade faktiskt inte läsa igenom detta tyvärr. Hoppas du inte tar illa upp Danielos.

Det är inlägg som har flyttats ut ifrån en tidigare tråd :)

Nä, sluta nu, detta är ju helt otroligt!! Dra inte ut inlägg från en annan tråd för att sedan sätta mig som trådskapare, jag misstänker att det är tartareandesire som står bakom detta, radera hela tråden isåfall!

Håller med dig, hur rörigt som helst, speciellt när inlägget blev taget från sitt sammanhang, och skulle jag skapa en ny tråd skulle jag lägga upp det på ett mycket bättre sätt.

Ja det blev lite tokigt nu, håller med om att det är bättre att ta bort tråden istället.

Jag hade som alternativ att antingen radera alla inläggen eller flytta ut dom till en ny tråd. Eftersom det ändå var ganska mycket text så kändes det lite tråkigt att radera allt. En lång diskussion om Varnish hade ingenting med den ursprungliga trådens frågeställning att göra. Däremot så missade jag mycket riktigt att notera att det handlade om utflyttade inlägg.

Jaha, men ITisGoods inlägg om varnish på CN funkar bra?

Mitt inlägg som handlande om varnish, php och prestanda var definitivt inte off-topic, för ett webbhotell med prestanda är php exekvering och varnish eller liknande A och O

Till en början tycker jag att varnish-diskussionen var väldigt relevant med tanke på på trådstarten som nämner City Network. Korrekt användning av Varnish kan i de flesta fall göra enormt stor skillnad för prestandan även i delade miljöer vilket var vad tråden handlade om. Jag ser det som väldigt relevant för tråden.

Har du en seg backend så blir det bara ännu viktigare att hålla cachen varm. Tyvärr är det lite svårt att styra på ett bra sätt i delade miljöer eftersom du inte kan t bort/banna cache på varnish servern och pusha upp ny data. När inte de möjligheterna finns kan man t.ex. ha crawlers som vandrar runt på sidan och som uppdaterar cachen med jämna intervall(cronjob). Använder man ett CMS som t.ex. Wordpress finns det plugins som löser det här. Det här är dock långt ifrån 100-procetig lösning och det går inte att komma ifrån att blir en del cachemissar som med en seg backend kan bli väldigt långsamma. Om man gör allt rätt så bör man kunna se till att det max är ett procent av alla requests som missar Varnish-cachen.

Är varnishcachen varm så levereras sidan alltid på någon millisekund om inte varnish-servern är extremt överbelastad eller konfigurerad på något sätt som jag inte förstår.

Varför hade det som alternativ, alla är ju överens om att det var on-topic och relevant?

Bara för att ha det sagt - vet massor av företag som har en seg sida när det gäller backend men tack varje väl konfiggad varnish laddas den på under 10 ms. Oftast då laddas cachen endast om vid ändringar - vilket sker mer sällan än man tror på mångas webbplatser. ;-) Detta görs förstås via en virtuell server där man har koll på sin egen miljö. Så även om jag håller med om att man bör skapa en väl fungerande backen - så låser många många det med Varnish eller cache generellt.

Att köra det på delad miljö är förstås en helt annan fråga då man måste tillgodose så många olika mönster av användande och det blir genast mindre effektivt och du kan aldrig komma ifrån att backend måste accessas oftare. Även i delad miljö - rätt gjort dock - så kan du faktsikt unkomma många av begränsningarna och lösa det. ;-) Sedan är det inte något jag rekommenderar - utan precis som du tycker man bör ha en väl fungerande backend.

Fast vad är det som säger att ett webbhotell blir bättre med Varnish än utan? Varför skulle man inte då, precis som innan, försöka trycka in så mycket som möjligt i systemet utan att man går för långt jämfört med konkurrenterna? Jag ser inte alls idag att något av de stora webbhotellen konkurrerar med prestanda utan det har hela tiden varit pris och överförsäljning som gäller. Vem behöver till exempel inte ha femtielva gigabyte utrymme med tusentals helt onödiga loggfiler från flera år tillbaka? :) Det tycker Binero och City Network är en bra idé. Ska man se till prestanda så är det Egensajt eller andra som gäller men då har man andra nackdelar istället.

Jag har exempelvis själv inte märkt någon som helst skillnad i prestandan på City Network innan och efter Varnish utan de sajter jag kört där har gått normalsnabbt hela tiden. Har ni andra märkt av någon tydlig skillnad? CN har blivit lite mer stabilt visserligen men det har sannolikt ingenting med Varnish att göra.

Om du laddar hela din sajt från Varnish hamnar du på ca 10 ms i generering. Detta är nästan omöjligt att slå på något annat sätt. Så om du utnyttjar detta fullt ut så når du snabbast möjliga laddning. Många gånger är upp till en sekund helt ok och mellan 0,5 och 1 sekund är ok även när du kör tex cache i WP mm.

Vi cachar dock bara 5 minuter i taget vilket innebär att du behöver rätt mycket trafik för att hela tiden använda varnish fullt ut. Kombinationen med WP-cache blir därför många gånger riktigt bra. Dock finns det andra begränsningar - tex kör man sajter som måste uppdatera sessioner mm hela tiden - som en e-handelssajt - så kan du inte cacha alls i många lägen. En lite mer traditionell WP sajt eller företagssajt kan dock oftast köra varnish hela tiden.

Du har rätt - stabilitet lär inte ha mycket med varnish att göra - men roligt att även det verkar gå åt rätt håll.

Konsultar varnish och varit och petat i nästan 15% av topp 50 här i sverige. De kör varnish och det bara fungerar. Nästan så magiskt att man kan glömma göra saker som fixa andra opcode optimizers ibland (obs, det är bra att göra det också) :)

Jag tycker att fördelen med varnish handlar om att kunna säkra siten för riktigt stora mängder trafik.

Ska du ha en wordpress (även om du kör total cache) får du köra väldigt mycket resurser (CPU/minne/snabb disk) om du ska ha flera hundra mbit/s i average trafik. Samma gäller andra CMS eller egenkodat.

Visst du kan få siten att svara snabbt men du får lägga mer resurser för att det ska lira.
Slänger vi en varnish framför så kan du klara dig med ett minimum backend med nginx+phpfpm på 512MB RAM och 1 kärna för att köra samma site.

Det är ganska stor besparing i infrastrukturkostnader och du kan slänga på fler varnish på lokala ställen i andra länder om du behöver lokalt uppsnabbade av din site.

Håller med dig, såvida man har stora siter är varnish ett väldigt bra komplement om man inte vill lägga lasten direkt på webbservern och köpa in mer hårdvara =)

Bra sätt att spara pengar är att lägga sin site på något webbhotell som översäljer kapacitet med sjukt billig disk.
Sen sätter man varnish på snabbare VPS och får fördel av hög prestanda men billig storage i backend.

hehe låter som något som passar dom som lirar Binero och Citynetwork och Crysone med andra ord :cool:

Ja, det är en riktigt bra lösning. Speciellt eftersom man då har möjlighet att skicka purge requests när man ändrar datan. I Wordpress finns det bra plugins för just detta.

Det här är dock inte en lösning som fungerar för alla siter, men för de som endast har statiskt innehåll (inklusive sidor som inte ändras så ofta) är det klockrent.

Det räcker väldigt långt med den minsta VPS:en som finns, dvs 512MB RAM och 1 core, på varnish-server vilket innebär att det inte kostar mycket mer än 100kr i månaden om man ska ha servern hos en vettig leverantör i Sverige.

Om nån vill testa varnish som front för sin vanliga wordpress eller CMS så kan jag hjälpa till :) bara dra ett pm. Tycker det är bra att varnishkunskaper sprids!