[Danielos]

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.

[pelmered]

Ursprungligen postat av Danielos

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.

[Danielos]

Ursprungligen postat av ITisGood.se

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.

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?

[pelmered]

Ursprungligen postat av Danielos

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 tyckte att jag förklarade ganska hyfsat i förra inlägget, men jag kan absolut förklara mer.

Ursprungligen postat av Danielos

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.

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).

Ursprungligen postat av Danielos

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"

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.

Ursprungligen postat av Danielos

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?

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ö.

[Danielos]

Ursprungligen postat av ITisGood.se

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.

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.

[pelmered]

Ursprungligen postat av Danielos

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.

[Danielos]

Ursprungligen postat av ITisGood.se

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.

[Clarence]

Ursprungligen postat av Danielos

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?

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.

[pelmered]

Ursprungligen postat av Danielos

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.

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.

[Danielos]

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.