Det har vært mye sagt nylig om fordelene ved statiske steder . Men i mange situasjoner er en dynamisk tilnærming en nødvendighet. Enten et innholdsstyringssystem, et kundeforholdsverktøy eller en nettbutikk, tillater de sluttbrukere å vedlikeholde komplekse nettsteder raskt og konsekvent. Og når de er satt sammen riktig, kan de konkurrere med statiske nettsteder for fart.
Enhver applikasjon som trenger å lese og skrive data ofte, vil forårsake en merkbar forsinkelse
Uansett hvilket system du bruker, består dynamiske nettsteder vanligvis av lignende elementer. Dette er en form for webserver, en backend og et program, skrevet i ett eller flere programmeringsspråk. Denne kombinasjonen av komponenter gir stor fleksibilitet, men hver bidrar med egen overhead og øker lastetid, noe som alle moderne nettsider vil unngå. Dette gjelder spesielt databasetilgang, hvilket program som må lese og skrive data ofte, vil forårsake en merkbar forsinkelse.
Dette hvor caching og en passende caching strategi for din bruk saken vil hjelpe. Det grunnleggende målet med caching er å forhindre unødvendige samtaler mellom programdatabase lagene og i stedet bruke forhåndsgenererte statiske HTML-sider, som er mye raskere å gjengi i en nettleser.
Den første cachen som en nettbruker ville ha lagt merke til er cachen i nettleseren sin. Hvor mange ganger har utviklere bedt deg om å foreta en "force-refresh" for å se endringer? Nettleserkuffer er enkle, men et godt utgangspunkt for å begynne å forklare caching-konsepter. En nettleser lagrer representasjoner av nettsider som er besøkt på en brukers datamaskin, vanligvis oppdaterer dem en gang per økt hvis endringer blir oppdaget eller tvunget av nettstedet.
Et vanlig verktøy som brukes av eiere og administratorer er en "omvendt proxy cache" som sitter mellom sidebeskrivelser laget av en nettleser og webapplikasjonen. Det avbryter forespørsler og gir kopier av sider rett fra hurtigbufferen, og gir dermed en merkbar fartforhøyelse.
Det finnes flere store proxy-hurtigbufferalternativer tilgjengelig for selvinstallasjon eller som "Programvare som en tjeneste". (Vi ignorerer cloud hosting-leverandører som vanligvis pakker alt du trenger til en selvstendig web-stabel.)
Populære proxy-bufferalternativer inkluderer:
SaaS-alternativer for caching generelt ligger i verden av Content Delivery Networks (CDNs), som i stedet for å plassere en cache mellom en bruker og en webstabel, gir brukerne sett med bufret innhold som er geografisk nærmest dem. Det er en subtil forskjell, men en som for store nettsteder med globale publikum kan gjøre en betydelig forskjell.
Varnish er tilgjengelig i alle Linux-pakkeforvaltere, som et Docker-bilde og mange andre alternativer, leser prosjektets installasjonsside for flere detaljer.
Larn lagrer en standard konfigurasjonsfil enten på /usr/local/etc/varnish/default.vcl eller /etc/varnish/default.vcl , skrevet i VCL (Larnkonfigurasjonsspråk). Denne konfigurasjonsfilen blir kompilert i et lite program via en C-tolk for å øke hastigheten enda mer.
Avhengig av hvordan du installerte Varnish, ser konfigurasjonsfilen ut slik:
backend default {.host = "127.0.0.1";.port = "8000";}På den enkleste måten definerer denne standardbackenden som brukes av Varnish, definerer verten og porten den skal høre og avlyse innhold på.
En praktisk funksjon av Varnish sjekker på forhåndsdefinerte intervaller hvis en backend fortsatt er sunn. Det kalles 'Backend polling' og er konfigurert ved å legge til en sondeseksjon i backend-erklæringen:
.probe = {.url = '/';.timeout = 34ms;.interval = 1s;.window = 10;.threshold = 8;}Ovennevnte er standardinnstillingene gitt av Varnish og forteller det å besøke en bestemt .url hver .interval, og at hvis i det minste .threshold av .window probes, reagerer nettadressen innen .timeout millisekunder, er baksiden fortsatt ansett som sunn. En gang betraktet som "usunn", blir innholdet servert fra hurtigbufferen i en forhåndsdefinert periode.
Vi dekker spesifikke endringer i lakkekonfigurasjonen under hvert plattform, for nå kan vi se på generelle alternativer.
porter
I utgangspunktet vil porten for din webserver måtte endres fra standardinnstillingen. For eksempel i Apache Vhost-konfigurasjonen endrer porten til 81 eller 8080.
Start Varnishermonen med lakkkommandoen eller bruk et serviceemballasje. Daemonen har flaggalternativer, det vanligste og mest nyttige vesen:
Kontroller alt fungerer
Kjør varnishstat kommandoen eller besøk isvarnishworking.com for å sjekke din Varnish-server er klar og lytter til forespørsler.
Hva ikke å cache
Det er visse deler av et nettsted som vi ikke vil cache, for eksempel administrasjonssidene. Vi kan ekskludere dem ved å opprette en vcl_recv subrutine i standard.vcl- filen som inneholder en if- setning som definerer hva som ikke skal cache:
sub vcl_recv {# URI of admin folderif (req.url ~ "^/url/"){return (pass);}return(lookup);}Hvis du bruker Varnish 4, er ting litt annerledes, inkludert returverdier. Vcl_recv- funksjonen returnerer nå ahash- verdi i stedet for et oppslag.
sub vcl_recv {...return(hash);}Dette er også der vi angir nettsteder eller underdomener som Varnish bør ignorere ved å legge til en req.http.host ~ 'example.com' til if- setningen.
kjeks
Som standard vil Larnish ikke cache innhold fra baksiden som angir informasjonskapsler. På samme måte, hvis klienten sender en informasjonskapsel, vil den omgå Varnish rett til baksiden.
Cookies brukes ofte av nettsteder for å spore brukeraktivitet og lagre brukerspesifikke verdier. Vanligvis er disse informasjonskapslene bare av interesse for klient-side-kode og har ingen interesse for backend eller Larn. Vi kan fortelle Varnish å ignorere informasjonskapsler, bortsett fra bestemte områder av nettstedet:
if ( !( req.url ~ ^/admin/) ) {unset req.http.Cookie;}Dette hvis setningen ignorerer informasjonskapsler, med mindre vi er i administrasjonsområdet på nettstedet, der det kan være mer bruk av informasjonskapsler (med mindre du virkelig vil frustrere nettstedet administratorer).
Andre unntak
Med en standardinstallasjon lagrer ikke Varnish heller ikke passordbeskyttede sider, GET og HEAD-forespørsler.
Vi vil nå se på to perfekte brukstilfeller for Lakk: Drupal og Magento. Begge er svært dynamiske systemer som tillater ikke-tekniske brukere å gjennomføre et bredt spekter av komplekse oppgaver. Dette kan føre til databasesøk-tunge sidelast og opptatt nettsteder blir merkbart sakte. Typiske sider bygget med disse systemene vil ha en blanding av innhold oppdatert sjeldent og ofte.
Drupal har standard caching alternativer som utfører lignende funksjoner for å Larn, men vil ikke gi fleksibilitet eller hastighetsøkninger som kreves av større eller mer komplekse nettsteder.
På ekte Drupal måte er det en modul for håndtering av lakkintegrasjon for å lagre noen av den manuelle konfigurasjonen som er skissert ovenfor.
Installer modulen og sørg for at du følger installasjonsinstruksjonene som er inkludert i modulens Read Me- fil.
Pass på at / etc / default / lakkfilen har følgende demonstrasjonsalternativer satt (og innrykket er viktig):
DAEMON_OPTS="-a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s file,/var/lib/varnish/$INSTANCE/varnish_storage.bin,128M"Forsikre deg om at Apache og eventuelle tilknyttede virtuelle verter hører på port 8080, ikke 80. Start begge tjenestene etter at du har gjort disse endringene.
Det kan hende du må angi en 'Larn Control Key' på modulkonfigurasjonssiden. Finn ut hva nøkkelen er med katten / etc / lakk / hemmelig kommando og lim den inn på innstillingssiden. Velg riktig Varnish-versjon, lagre innstillingene, og du bør se en serie grønne flått nederst på siden.
Varnish-modulen samhandler med standard Drupal-hurtigbufferinnstillinger, så sørg for at du har aktivert og konfigurert for brukskassen.
Kjør varnishstat fra kommandolinjen, start navigering av nettstedet som en anonym bruker, og du bør se statistikkendring i kommandoen.
En av stiene vi ikke vil cache i Drupal er admin sidene, vi kan gjøre dette med en vcl_recv subrutine:
sub vcl_recv {# URI of admin folderif (req.url ~ "^/admin/"){return (pass);}unset req.http.Cookie;return(lookup);}Du vil kanskje vurdere å ikke cache (logget inn) bruker sider, systemoppdateringssider og andre sider generert av svært dynamiske moduler som flagg som gjør omfattende bruk av ajax til å fungere. Gjør dette ved å legge til flere req.url- parametre til if- setningen.
En standardinstallasjon av Magento leveres med et internt caching-system som lagrer statiske versjoner av sideelementer i en spesifisert mappe. Siden System -> Cache Management gir deg en oversikt over gjeldende cachestatus, samt lar deg slette alle eller enkelte komponent caches. Du kan fjerne aggregerte CSS- og JS-filer og automatisk genererte bildefiler fra denne siden.
Den kommende versjonen 2 av Magento vil som standard støtte Varnish caching, men for nå trenger vi å benytte tredjeparts plugins, anbefaler jeg Turpentine modul . Pass på at du leser prosjektets readme-fil som det legger merke til noen ekstra konfigurasjonstrinn, kan det være å bryte nettstedet ditt ved å ignorere dem.
Turpentine-modulen er svært konfigurerbar og vil gjøre de nødvendige endringene til vcl- filer og Varnish config for deg. Noen av de viktigste alternativene som skal settes er:
Turpentine-modulen binder seg til standard Magento-hurtigbufferen, slik at clearing-kufferter på Larn-cachesiden fjerner de relevante Larn-cachene.
Bortsett fra å bruke Varnish med noen av de dynamiske systemene ovenfor, er her en håndfull andre diverse tips som vil hjelpe cache-evnen til et hvilket som helst nettsted.
Hvis du serverer det samme innholdet i forskjellige sammenhenger, bør det bruke samme nettadresse. For eksempel bland ikke bruk av artikkel.html , artikkel.htm og artikkel , selv om CMS kan tillate det. Dette vil føre til tre forskjellige bufrete versjoner av samme innhold.
Som vi så over, er cookies vanskelig å cache og er sjelden som nødvendig som vi tror. Prøv å begrense bruken og nummeret til dynamiske sider.
Lasting av eiendomsverdier kan være en av de mest tidkrevende delene av en side gjengivelse, og det er enkle tips for å redusere denne byrden:
Bruke CSS Image sprites for iconography i stedet for flere små filer resulterer i mindre nettverkstrafikk.
Hosting CSS og JavaScript-biblioteker lokalt betyr mindre nettverkstrafikk og mer kontroll over caching-strategier. Dette kan bety en økning i vedlikeholdskostnader for å holde disse eiendelene oppdatert. Lagre disse eiendelene i konsekvent navngitte mapper, slik at henvisninger til dem også kan være konsistente.
Jeg håper denne introduksjonen til å fange opp dine dynamiske nettsteder med caching var nyttig. Ytelsesgevinsten er verdt en innledende periode med konfigurasjon, eksperimentering og justering. I denne perioden med kort oppmerksomhet spenning og utålmodighet, vil enhver hastighetsøkning du kan klemme ut av ditt oppsett, gjøre forskjellen for brukerne og konkurransen.