1. 1. Nybegynnerveiledning for å forstå WordPress interne funksjoner
  2. 2. Hva er WordPress Cache, og hvorfor er det viktig?
  3. 3. Leser for øyeblikket: Hvordan fungerer WordPress Caching?
  4. 4. Hvordan installere og installere WordPress Cache med WP Super Cache
  5. 5. Slik konfigurerer du WordPress-hurtigbuffer med W3 Total Cache (W3TC)
  6. 6. MaxCDN Review: Den beste CDN for WordPress?

Velkommen til et nytt kapittel i WordPress Caching-serien vår hvor vi lærer hvordan WordPress-hurtigbufring fungerer. Før du kommer til bunns i dette emnet, må du forsikre deg om at du har fulgt hvert av de forrige emnene (fra denne serien) nøye, da dette kapittelet bruker kunnskapen fra dem. Til å begynne med, la oss snakke om de to primære typene cache-protokoller som er tilgjengelige, basert på klient-servermodellen:


  • Client-Side caching og
  • Bufring av server-side

Bufring av klientsiden

Klient-servermodellen

Klient-servermodellen

Et nettsted inneholder mange ikke-tekstlige, statiske data, for eksempel bilder, CSS og Javascript. Når de er lastet ned, er nettleseren din smart nok til ikke å laste dem ned igjen hver gang du trykker på F5-knappen. Den tjener ganske enkelt data fra den lokale hurtigbufferen – dvs. bufrede data lagret på datamaskinens harddisk. Derfor anbefales det å rense nettleserens hurtigbuffer innimellom – det sparer mye plass og forbedrer ytelsen.

Denne prosessen med å gjenbruke cache-data fra klientens datamaskin (eller klientens slutt) er kjent som klientsiden-hurtigbufring, og nesten alle moderne nettsteder bruker dem, og hver nettleser støtter dem. Bufring av klientsiden hjelper til med å forhindre dataredundans (dvs. nedlasting av de samme dataene om og om igjen) og sparer dermed mange serverressurser og viktigst av alt – tid!

Bufring på serversiden

Server

Bufring på serversiden inkluderer alle de forskjellige hurtigbufringsprotokollene som brukes under WordPress-hurtigbufring. De inkluderer følgende:

  • Sidebuffing
  • Bufring av databaseforespørsel
  • Objektbasert hurtigbufring
  • Opcode-hurtigbufring

WordPress benytter seg av disse fire viktige hurtigbufringsprotokollene på serversiden. Vi kommer til å ta en titt på hver enkelt av dem og se hvordan caching av hver enkelt av dem kan spare mye dyrebar beregningstid, og dermed øke hastigheten på nettstedet ditt.

Page Cache

1381630448_HTML-2Sidebuffing er den enkleste av alle hurtigbuffer-protokollene, og jeg vedder på at du allerede vet om dette. Den refererer ganske enkelt til prosessen med å lagre de dynamisk genererte HTML-filene på serverens harddisk eller minne (RAM) (ofte kjent som ‘cachen’) og servere dem fra cachen (dvs. gjenbruk av tidligere genererte data) når en forespørsel blir fremsatt . Dette sparer overhead for å utføre PHP-kode og MySQL-database-spørsmål.

Cache for databaser

databaseDen første tingen å vite om databaser er at de er enorme og ressurssultne. De er bokstavelig talt, hjertet i hvert selskap – det være seg online eller på annen måte. Det samme gjelder WordPress. Målet med en database er å lagre, oppdatere og levere data effektivt. Siden de vanligvis er enorme, tar hvert spørsmål tid (vanligvis i størrelsesorden noen hundre mikrosekunder). Bedre maskinvaren, raskere generering av spørring. Tenk på dette. Siden WordPress er veldig avhengig av databasen sin, lager den et spørsmål nå og da. Og når data ikke endres i databasen, er det å laste spørsmål om å hente de samme dataene på samme måte som å laste ned de samme bildene igjen og igjen – som diskutert under Client Side Caching. Derfor er det fornuftig å lagre resultatene av en spørring i den lokale lagringen? Denne lagringen av databaseforespørsler resultater i lokal lagring kalles database cache, og er en av de grunnleggende faktorene i WordPress caching.

Når databasen først er oppdatert (for eksempel når et innlegg er oppdatert eller publisert, eller en kommentar er sendt inn), er det imidlertid veldig viktig at den tidligere lagrede databasebufferen blir slettet og gjenoppretter databasens spørringsresultater på nytt. Dette er ikke overflødig, da det hjelper til med å eliminere irrelevante eller feilaktige resultater av databaseforespørsler.

Objektbufring

opcodeWordPress har et internt hurtigbufringssystem som inkluderer flere undersystemer (dvs. Cache-API, Object Cache og Transient API). WordPress-kjernen lar plugins kontrollere dette hurtigbufringssystemet for å redusere antall databasesamtaler. Dette er et ganske avansert emne, og er ikke helt relevant for den daglige brukeren.

Opcode-hurtigbufring

PHP-kodePå samme måte som hurtigbufring av databaser der ideen er å redusere antall databaseforespørsler, refererer opkodebuffing til lagring av den kompilerte PHP-koden mellom hver forespørsel. Hvis du ser på en hvilken som helst PHP-fil, vil du se at koden faktisk er en liste over instruksjoner som kompilatoren skal bruke. PHP er et objektorientert programmeringsspråk, og har fordelene fra opprinnelsen! For at en PHP-kode skal kunne kjøres, må PHP-kompilatoren sammenstille koden først og generere den kjørbare koden for webserveren å utføre. Cache-utdata fra PHP-kompilatoren til for flere henrettelser, er det opcode caching handler om. Igjen, dette er interne ting – ting du ikke bør være mye bekymret for!

Lokal lagring – Primær kontra sekundær

Lokal lagring

For å implementere serverbufring av hvilken som helst form, er det forstått at dataene må lagres i det lokale lagringsstedet. Begrepet “lokal lagring” kan bety en av to ting. Den ene er serverens harddisk, og den andre er serverens primære minne – dvs. RAM.

RAM, som står for Random Access Memory, er en form for flyktig minne og er størrelsesordrer raskere enn harddisker, som er en form som ikke-flyktig, sekundær lagring. Det er dyrere også. Selvfølgelig vet dere alle dette.

Hvor du lagrer hurtigbufrede data gjør en stor forskjell. Hvis den er på en harddisk, er den definitivt tregere enn når den er lagret i en RAM. Igjen betyr hastigheten på harddisken. Serverens harddisker spenner fra 7.200 RPM til 15.000 RPM og kan ha forskjellige RAID-nivåer – RAID 0 er den raskeste og mest usikre, og RAID 4 er en riktig balanse. Du har også SSD-er. Derfor har den lagrede datalokaliteten en alvorlig innvirkning på hastigheten.

For personer på delte hosting-servere har du ikke noe annet valg enn å lagre det på harddisken. For folk som kjører sin egen dedikerte server eller VPS, har du det ekstra alternativet å lagre hurtigbufferen i ditt primære minne, noe som igjen må gjøres med mye forsiktighet – feil konfigurasjon kan føre til ustabilitet (tom for RAM osv.) og hyppige serverkrasj.

Konklusjon

Nå som du har god forståelse for de forskjellige WordPress-hurtigbufferprotokollene, la oss komme til midtpunktet i postserien vår – Hvordan implementere WordPress cache.

Hvis du har spørsmål eller forslag til å forbedre dette kapitlet, kan du gjerne spørre eller dele dem – vi vil gjerne høre tankene dine!

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me