Der er meget blevet sagt for nylig om fordelene ved statiske steder . Men i mange situationer er en dynamisk tilgang en nødvendighed. Uanset om et indholdsstyringssystem, et kundeforretningsværktøj eller en online-butik, giver de slutbrugere mulighed for hurtigt og konsekvent at opretholde komplekse websteder. Og når de samles ordentligt, kan de konkurrere med statiske steder for hurtighed.
Enhver applikation, der skal læse og skrive data ofte, vil medføre en mærkbar forsinkelse
Uanset hvilket system du bruger, består dynamiske websteder typisk af lignende elementer. Disse er en form for webserver, en backend og et program, der er skrevet på et eller flere programmeringssprog. Denne kombination af komponenter giver stor fleksibilitet, men hver især bidrager med egen overhead og øger belastningstid, hvilket alle moderne websteder vil undgå. Dette er især tilfældet med databaseadgang; enhver applikation, der skal læse og skrive data ofte, vil medføre en mærkbar forsinkelse.
Dette hvor caching og en passende caching strategi til din brug sagen vil hjælpe. Det grundlæggende formål med caching er at forhindre unødigt hyppige opkald mellem applikationsdatabase lagene og i stedet bruge forudgenererede statiske HTML-sider, som er meget hurtigere at gengive i en browser.
Den første cache, som enhver webbruger ville have bemærket, er cachen i deres browser. Hvor mange gange har udviklere bedt dig om at foretage en "force-refresh" for at se ændringer? Browser caches er enkle, men et godt udgangspunkt for at begynde at forklare caching begreber. En browser gemmer repræsentationer af websider, der er besøgt på en brugers computer, typisk opdatering dem en gang pr. Session, hvis ændringer opdages eller tvunget af webstedet.
Et fælles værktøj, der anvendes af webstedsejere og administratorer, er en 'reverse proxy cache', der sidder mellem sidebeskeder fra en webbrowser og webapplikationen. Det aflyser forespørgsler og gør kopier af sider direkte fra cachen, hvilket giver en mærkbar hastighedsforøgelse.
Der findes flere store proxy-cache-indstillinger til selvinstallation eller som 'Software as a Service'. (Vi ignorerer cloud hosting-udbydere, som typisk pakker alt, hvad du måske har brug for i en selvstændig webstabel.)
Populære proxy-cache-indstillinger omfatter:
SaaS muligheder for caching generelt ligger i verden af Content Delivery Networks (CDN'er), som i stedet for at placere en cache mellem en bruger og en webstabel, tjener brugere sæt af cachelagret indhold, der er geografisk tættest på dem. Det er en subtil forskel, men en for store websteder med globale målgrupper kan gøre en betydelig forskel.
Lak er tilgængelig i alle Linux-pakkeforvaltere, som et Docker-billede og mange andre muligheder, læses projektets installationsside for flere detaljer.
Larn gemmer en standard konfigurationsfil enten på /usr/local/etc/varnish/default.vcl eller /etc/varnish/default.vcl , skrevet i VCL (Larn Configuration Language). Denne konfigurationsfil bliver samlet i et lille program via en C-tolk for at øge hastigheden endnu mere.
Afhængigt af, hvordan du installerede Varnish, ser konfigurationsfilen sådan ud:
backend default {.host = "127.0.0.1";.port = "8000";}Det er det enkleste, det definerer standardbackend brugt af Varnish, definerer værten og porten, at den skal lytte og opfange indhold.
En praktisk funktion af Varnish kontrollerer ved foruddefinerede intervaller, hvis en backend stadig er sund. Den hedder 'Backend polling' og er konfigureret ved at tilføje en probesektion i backend-erklæringen:
.probe = {.url = '/';.timeout = 34ms;.interval = 1s;.window = 10;.threshold = 8;}Ovennævnte er standardindstillingerne fra Varnish og fortælle det at besøge et bestemt .url hvert interval og at hvis i det mindste .threshold fra .window probes, svarer url inden for .timeout millisekunder, er backend stadig betragtet som sund. Når man betragtes som "usundt", serveres indholdet fra cachen i en foruddefineret periode.
Vi dækker specifikke ændringer til larnekonfigurationen under hver platformsoption, så lad os nu se på generelle muligheder.
Havne
I første omgang skal porten til din webserver skifte fra standard. For eksempel ændrer porten til 81 eller 8080 i Apache Vhost-konfigurationen.
Start Lakedemonen med lakkommandoen eller brug en serviceemballage. Dæmonen har flagindstillinger, det mest almindelige og nyttige væsen:
Kontrol af alt fungerer
Kør varnishstat kommandoen eller besøg isvarnishworking.com at kontrollere din Varnish-server er klar og lytter til anmodninger.
Hvad ikke at cache
Der er visse dele af et websted, som vi ikke ønsker at cache, f.eks. Administrationssiderne. Vi kan udelukke dem ved at oprette en vcl_recv subrutine i standard.vcl- filen, der indeholder en if- sætning, der definerer, hvad der ikke skal cache:
sub vcl_recv {# URI of admin folderif (req.url ~ "^/url/"){return (pass);}return(lookup);}Hvis du bruger Varnish 4, er tingene lidt anderledes, herunder returværdier. Vcl_recv- funktionen returnerer nu ahash- værdi i stedet for et opslag.
sub vcl_recv {...return(hash);}Det er også her, hvor vi indstiller websteder eller underdomæner, som Varnish bør ignorere ved at tilføje et req.http.host ~ 'example.com' til if- erklæringen.
småkager
Som standard vil Varnish ikke cache indhold fra backenden, der angiver cookies. På samme måde, hvis klienten sender en cookie, vil den omgå Varnish lige til backend.
Cookies bruges ofte af websteder til at spore brugeraktivitet og gemme brugerspecifikke værdier. Generelt er disse cookies kun af interesse for klient-side-kode og har ingen interesse for backend eller larn. Vi kan fortælle Varnish at ignorere cookies, undtagen i bestemte områder af webstedet:
if ( !( req.url ~ ^/admin/) ) {unset req.http.Cookie;}Denne hvis sætning ignorerer cookies, medmindre vi er i webstedets adminområde, hvor cookie-passering kan være mere anvendelig (medmindre du virkelig vil frustrere webstedets administratorer).
Andre undtagelser
Med en standardinstallation lagrer Varnish heller ikke adgangskodebeskyttede sider, GET og HEAD-anmodninger.
Vi vil nu se på to perfekte brugssager til Varnish: Drupal og Magento. Begge er meget dynamiske systemer, der giver ikke-tekniske brugere mulighed for at foretage en lang række komplekse opgaver. Dette kan føre til databasesøgningstunge sidebelastninger og optagne websteder bliver markant langsomme. Typiske sider bygget med disse systemer vil få en blanding af indhold opdateret sjældent og ofte.
Drupal har standard caching muligheder, der udfører lignende funktioner til at larnere, men vil ikke give de fleksibilitet eller hastighedsforøgelser, der kræves af større eller mere komplekse steder.
På ægte Drupal måde er der en modul til håndtering af Larn integration for at gemme nogle af den manuelle konfiguration beskrevet ovenfor.
Installer modulet og sørg for, at du følger installationsanvisningerne i modulets Read Me- fil.
Sørg for at / etc / default / lakfilen har følgende dæmonopsætninger indstillet (og indrykket er vigtigt):
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"Sørg for, at Apache og eventuelle tilknyttede virtuelle værter lytter på port 8080, ikke 80. Genstart begge tjenester efter at have foretaget disse ændringer.
Det kan være nødvendigt at indstille en 'Larn Control Key' på modulets konfigurationsside. Find ud af hvad nøglen er med katten / etc / lak / hemmelig kommando og indsæt den i indstillingssiden. Vælg den korrekte Larnish-version, gem indstillingerne, og du skal se en række grønne flåter nederst på siden.
Varnish-modulet interagerer med standard Drupal-cache-indstillingerne, så sørg for, at du har aktiveret og konfigureret til brugssagen.
Kør lakstat fra kommandolinjen, start navigering af webstedet som en anonym bruger, og du skal se statistikændring i kommandoudgangen.
En af de stier, vi ikke ønsker at cache i Drupal, er administratorsiderne, vi kan gø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 kan overveje at ikke cache (logget ind) bruger sider, system opdatering sider og andre sider genereret af højt dynamiske moduler som flag, der gør omfattende brug af ajax til at fungere. Gør dette ved at tilføje yderligere req.url parametre til if- sætningen.
En standardinstallation af Magento leveres med et internt caching-system, der lagrer statiske versioner af webstedselementer i en bestemt mappe. Siden System -> Cache Management giver et overblik over den aktuelle cachestatus, ligesom du kan slette alle eller enkelte komponent caches. Du kan rydde aggregerede CSS- og JS-filer og automatisk genererede billedfiler fra denne side.
Den kommende version 2 af Magento vil som standard støtte Varnish caching, men vi skal i øjeblikket bruge 3rd party plugins, jeg anbefaler Terpentin modul . Sørg for at du læser projektets readme-fil da det bemærker nogle ekstra konfigurationstrin, kan ignoreringen af dem ødelægge dit websted.
Turpentine-modulet er meget konfigurerbart og vil foretage de nødvendige ændringer til vcl- filer og Varnish config til dig. Nogle nøgleindstillinger, der skal indstilles, er:
Turpentine-modulet binder ind i standard Magento-cachen, så rydning af cacher på siden for lak cache vil rydde de relevante Larn-caches.
Bortset fra at bruge Varnish med et af de dynamiske systemer ovenfor, er her en håndfuld andre forskellige tips, der hjælper cache-evnen til ethvert websted.
Hvis du serverer det samme indhold i forskellige sammenhænge, skal det bruge samme URL. For eksempel bland ikke brug af article.html , article.htm og artiklen , selvom dit CMS muligvis tillader det. Dette vil føre til tre forskellige cachelagrede versioner af samme indhold.
Som vi så ovenfor, er cookies svære at cache og er sjældent nødvendige som vi tror. Prøv at begrænse deres brug og nummer til dynamiske sider.
Indlæser webstedets aktiver kan være en af de mest tidskrævende dele af en sidegengivelse, og der er enkle tips til at reducere denne byrde:
Brug af CSS Image sprites til ikonografi i stedet for flere små filer resulterer i mindre netværkstrafik.
Hosting CSS og JavaScript-biblioteker lokalt betyder mindre netværkstrafik og mere kontrol over caching-strategier. Dette kan betyde en stigning i vedligeholdelsesomkostningerne for at holde disse aktiver ajour. Gem disse aktiver i konsekvent navngivne mapper, så henvisninger til dem kan også være konsekvente.
Jeg håber, at denne introduktion til at fremskynde dine dynamiske websteder med caching var nyttig. Forbedringsgevinsten er en begyndelsesperiode for konfiguration, eksperimentering og tweaking. I denne æra med korte opmærksomhed spændinger og utålmodighed, vil enhver hastighedsgevinst du kan presse ud af din opsætning gøre forskellen for dine brugere og konkurrence.