Många har nyligen sagt om fördelarna med statiska platser . Men i många situationer är ett dynamiskt tillvägagångssätt en nödvändighet. Oavsett om ett innehållshanteringssystem, ett kundrelationsverktyg eller en nätbutik, tillåter de slutanvändarna att snabbt och konsekvent upprätthålla komplexa webbplatser. Och när de sätts ordentligt, kan de rivalisera statiska platser för fart.
Alla program som behöver läsas och skrivas ofta kommer att orsaka en märkbar fördröjning
Oavsett vilket system du använder, består dynamiska platser typiskt av liknande element. Dessa är en form av webbserver, en backend och ett program, skrivet på ett eller flera programmeringsspråk. Denna kombination av komponenter ger stor flexibilitet, men varje bidrar med egen överhuvud och ökar lasttiden, något som alla moderna webbplatser vill undvika. Detta gäller särskilt med databasåtkomst. Alla program som behöver läsas och skrivas ofta kommer att orsaka en märkbar fördröjning.
Detta där caching och en lämplig cachingstrategi för ditt användningsfall kommer att hjälpa till. Det grundläggande syftet med cachning är att förhindra onödigt frekventa samtal mellan applikationsdatabaslagren och istället använda pregenererade statiska HTML-sidor, vilket är mycket snabbare att göra i en webbläsare.
Den första cachen som någon webbanvändare skulle ha märkt är cachen i sin webbläsare. Hur många gånger har utvecklare bett dig att göra en "force-refresh" för att se förändringar? Browserkachetter är enkla men en bra utgångspunkt för att börja förklara caching-koncept. En webbläsare lagrar representationer av webbsidor som besöks på en användares dator, vanligtvis uppdaterar dem en gång per session om ändringar upptäcks eller tvingas av webbplatsen.
Ett vanligt verktyg som används av webbplatsägare och administratörer är en "omvänd proxy cache" som sitter mellan sidförfrågningar som görs av en webbläsare och webbapplikationen. Det avlyssnar förfrågningar och gör kopior av sidor direkt från cacheminnet, vilket ger en märkbar hastighetsökning.
Det finns flera stora proxy-cache-alternativ tillgängliga för självinstallation eller som "Programvara som en tjänst". (Vi ignorerar cloud hosting-leverantörer som vanligtvis paketerar allt du kan behöva till en fristående webbstack.)
Populära alternativ för proxybuffert inkluderar:
SaaS-alternativen för cachering ligger generellt i innehållet för innehållsleveransnätverk (CDN), som istället för att placera en cache mellan en användare och en webbstack, tjänar användarna uppsättningar av cachad innehåll som är geografiskt närmast dem. Det är en subtil skillnad, men en som för stora webbplatser med global publik kan göra en stor skillnad.
Lack Finns i alla Linux-pakethanterare, som en Docker-bild och många andra alternativ, läs projektets installationssida för mer detaljer.
Larn lagrar en standard konfigurationsfil antingen på /usr/local/etc/varnish/default.vcl eller /etc/varnish/default.vcl , skrivet i VCL (Larnkonfigurationsspråk). Denna konfigurationsfil sammanställs till ett litet program via en C-tolk för att öka hastigheten ännu mer.
Beroende på hur du installerat Varnish ser konfigurationsfilen ut något liknande:
backend default {.host = "127.0.0.1";.port = "8000";}På det enklaste sättet definierar den standardbackend som används av Varnish, definierar värd och port som den ska lyssna och avlyssna innehåll på.
En praktisk funktion hos Varnish kontrollerar med förutbestämda intervaller om en backend fortfarande är hälsosam. Den kallas "Backend polling" och är konfigurerad genom att lägga till en sond sektion i backend-deklarationen:
.probe = {.url = '/';.timeout = 34ms;.interval = 1s;.window = 10;.threshold = 8;}Ovanstående är standardinställningarna som tillhandahålls av Varnish och berättar att den besöker en viss .url varje intervall och att om åtminstone .tröskeln utav .window- sonder, svarar urlen inom. Timeout millisekunder, anses bakgrunden fortfarande som hälsosam. En gång betraktad som "ohälsosam" serveras innehållet från cacheminnet i en fördefinierad period.
Vi täcker specifika ändringar i larnkonfigurationen under varje plattformsalternativ, för nu tar vi en titt på allmänna alternativ.
Hamnar
Initialt kommer porten för din webbserver att behöva byta från standard. Till exempel i Apache Vhost-konfigurationen ändras porten till 81 eller 8080.
Starta varmademonen med lackkommandot eller använd ett serviceomslag. Daemonen har flaggalternativ, den vanligaste och mest användbara varelsen:
Kontrollera att allt fungerar
Kör kommandot varnishstat eller besök isvarnishworking.com att kontrollera din Varnish-server är redo och lyssnar på förfrågningar.
Vad inte att cache
Det finns vissa delar av en webbplats som vi inte vill cache, till exempel administrationssidorna. Vi kan utesluta dem genom att skapa en vcl_recv subrutin i default.vcl- filen som innehåller ett if- förklaring som definierar vad som inte ska caches:
sub vcl_recv {# URI of admin folderif (req.url ~ "^/url/"){return (pass);}return(lookup);}Om du använder Varnish 4 är sakerna något annorlunda, inklusive returvärden. Vcl_recv- funktionen returnerar nu ahash- värde istället för en sökning.
sub vcl_recv {...return(hash);}Det här är också där vi ställer in webbplatser eller underdomäner som Larn ska ignorera genom att lägga till ett req.http.host ~ 'example.com' till if- förklaringen.
Småkakor
Som standard kommer inte Larnish att cache innehåll från backend som anger cookies. På samma sätt, om klienten skickar en kaka, kommer den att omgå Lack rakt till backend.
Cookies används ofta av webbplatser för att spåra användaraktivitet och lagra användarspecifika värden. Vanligtvis är dessa cookies endast av intresse för klientsidkod och har inget intresse för backend eller Larn. Vi kan berätta för Larn att ignorera cookies, förutom i vissa delar av webbplatsen:
if ( !( req.url ~ ^/admin/) ) {unset req.http.Cookie;}Detta om uttalande ignorerar cookies om vi inte befinner oss i webbplatsens adminområde, där kakor som passerar kan vara mer användbara (om du inte vill frustrera webbplatsadministratörer).
Andra undantag
Med en standardinstallation crasar inte Larn också lösenordsskyddade sidor, GET och HEAD-förfrågningar.
Vi ska nu titta på två perfekta användningsfall för Lack: Drupal och Magento. Båda är högdynamiska system som gör det möjligt för icke-tekniska användare att genomföra en mängd olika komplexa uppgifter. Detta kan leda till att databasfrågor-tunga sidladdningar och upptagna webbplatser blir märkbart långsamma. Typiska sidor byggda med dessa system kommer att få en blandning av innehåll uppdaterad sällan och ofta.
Drupal har standard cachingalternativ som utför liknande funktioner för att Larnera, men kommer inte att ge de flexibilitet eller hastighetsökningar som krävs av större eller mer komplexa webbplatser.
På äkta Drupal sätt finns en modul för hantering av Larn integration för att spara lite av den manuella konfigurationen som beskrivs ovan.
Installera modulen och se till att du följer installationsanvisningarna som ingår i modulens Read Me- fil.
Se till att filen / etc / default / lak har följande inställningar för daemon (och inskärningen är 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"Se till att Apache och eventuella associerade virtuella värdar lyssnar på port 8080, inte 80. Starta om båda tjänsterna efter att ha gjort dessa ändringar.
Det kan hända att du måste ställa in en "Lack Control Key" på modulens konfigurationssida. Ta reda på vad den här nyckeln är med katten / etc / lack / secret- kommandot och klistra in det på inställningssidan. Välj rätt Larn-version, spara inställningarna och du bör se en serie gröna fästingar längst ner på sidan.
Lackmodulen interagerar med standardinställningarna för Drupal-cache, så se till att du har det aktiverat och konfigurerat för ditt användarfall.
Kör varnishstat från kommandoraden, börja navigera på webbplatsen som en anonym användare och du bör se statistikändring i kommandoutmatningen.
En av de vägar vi inte vill cache i Drupal är adminsidorna, vi kan göra det med en vcl_recv subrutin:
sub vcl_recv {# URI of admin folderif (req.url ~ "^/admin/"){return (pass);}unset req.http.Cookie;return(lookup);}Du kanske vill överväga att inte cacha (inloggade) användarsidor, systemuppdateringssidor och andra sidor som genereras av högdynamiska moduler som flagga som gör omfattande användning av ajax för att fungera. Gör detta genom att lägga till ytterligare req.url- parametrar till if- satsen.
En standardinstallation av Magento levereras med ett internt caching-system som lagrar statiska versioner av platselement i en angiven mapp. Sidan System -> Cache Management ger en översikt över aktuell cachestatus och låter dig rensa alla eller enskilda komponentcacher. Du kan rensa aggregerade CSS- och JS-filer och automatiskt genererade bildfiler från den här sidan.
Den kommande versionen 2 av Magento kommer som standard att stödja Larn caching, men för närvarande behöver vi använda 3: e plugins, rekommenderar jag Terpentinmodul . Se till att du läser projektets readme-fil eftersom det noterar några extra konfigurationssteg, kan det hända att du ignorerar dem på din webbplats.
Turpentine-modulen är mycket konfigurerbar och kommer att göra nödvändiga ändringar i vcl- filer och Larn config för dig. Några viktiga alternativ att ställa in är:
Turpentine-modulen knyts till standard Magento-cacheminnet, så att rensning av cachar på sidan Lackering av cacheminne rensar de relevanta Lack-cacharna.
Bortsett från att använda Lack med något av de dynamiska systemen ovan, här är en handfull andra diverse tips som hjälper till att cache-förmågan hos en webbplats.
Om du serverar samma innehåll i olika sammanhang ska det använda samma webbadress. Blanda inte bland annat användningen av article.html , article.htm och artikeln , men ditt CMS kan tillåta det. Detta kommer att leda till tre olika cachade versioner av samma innehåll.
Som vi såg ovan är kakor svåra att cache och är sällan så nödvändiga som vi tror. Försök att begränsa användningen och numret till dynamiska sidor.
Att ladda på webbplatsens tillgångar kan vara en av de mest tidskrävande delarna av en sidaåtergivning och det finns enkla tips för att minska denna börda:
Att använda CSS Image sprites för ikonografi istället för flera små filer resulterar i mindre nätverkstrafik.
Hosting CSS och JavaScript-bibliotek lokalt betyder mindre nätverkstrafik och mer kontroll över caching-strategier. Detta kan innebära en ökning av underhållskostnaderna för att hålla dessa tillgångar uppdaterade. Spara dessa tillgångar i konsekvent namngivna mappar så att hänvisningar till dem också kan vara konsekventa.
Jag hoppas att denna introduktion till att påskynda dina dynamiska webbplatser med cachning var användbart. Resultatförstärkningen är värt en första period av konfiguration, experiment och tweaking. I den här tiden med korta spänningar och otålighet kan varje snabba vinst du kan klämma ut från din uppsättning göra skillnaden för dina användare och tävling.