Lær hvordan caching påvirker EPMV

Caching (eller cache) er en slags mellombuffer der data lagres. Takket være Caching blir nettstedet ikke gjenopprettet for hver bruker. Caching lar deg jobbe med en stor mengde data på kortest mulig tid og med begrensede ressurser (server og bruker).

Typer av caching.

1. Browser caching eller klient caching

Det instruerer nettleseren å bruke en eksisterende bufret kopi. Arbeidet med en slik caching er basert på det faktum at på et andre besøk er den 304 ikke endrede overskriften gitt til nettleseren, og siden eller bildet selv er lastet fra den lokale brukerbufferen. Det viser seg at nettstedets eier sparer på trafikk mellom besøkendes nettleser og nettstedets hosting. Følgelig begynner nettstedssiden lasting raskere.

1.1. Caching filer og bilder.

Browser Caching er den best egnet for nettsteder som inneholder et stort antall bilder: bildet er ikke lastet ned hver gang nettstedet åpnes, men bare lastes gjennom nettleserens cache. Dette er det første nivået av caching, som er å returnere Utløpt header og 304 IKKE MODIFIED header. Den mest effektive caching anses å være i to uker.

Men i dette tilfellet er det en viktig nyanse: Hvis bildet på nettstedet endres, vil nettleseren ikke vite om det umiddelbart, men bare hvis du venter på utløp eller tilbakestill hurtigbufferen i nettleseren selv. Det er ikke veldig effektivt hvis filen er i stadig endring, og det er nødvendig å kontinuerlig returnere sin nåværende versjon.

1.2. Https caching.

Spesielle overskrifter som strengt sikkerhet. Tillater nettleseren å alltid henvise til det valgte domenet via HTTPS. Det holder denne tilstanden ganske stiv, og hvis denne typen cache avbestilles, vil nettleseren fortsatt prøve å laste siden via HTTPS i ganske lang tid, mens du ignorerer de nåværende overskriftene.

1.3. Sertifisering autoritet caching.

Det såkalte sertifiseringsmyndighetsstempelet.

Denne typen caching anses å være obligatorisk hvis nettstedets eier ikke vil at brukerne av nettstedet hans skal vente på sertifiseringsmyndigheten (og dette er en bestemt server som er ansvarlig for gyldigheten av sertifikatet) for å behandle forespørselen fra brukerens nettleser og bekreft at ressursen faktisk er bekreftet av ham.

1.4. Side caching.

Når siden allerede er generert, må du hele tiden overvåke relevansen. For å gjøre dette må du bruke en serverbuffer med å spore tidspunktet for endringene i enkelte deler av siden (hvis siden er bygget fra et sett med dynamisk genererte blokker). Med denne tilnærmingen, i hvert svar fra serveren, er spesielle overskrifter installert som angir den tiden siden ble endret, som deretter sendes av brukerens nettleser når nettstedsiden er tilgjengelig på nytt. Når du mottar slike overskrifter, kan serveren analysere den nåværende tilstanden på siden (kanskje til og med gjøre det), men i stedet for sideninnholdet, gi overskriften 304 ikke endret, som for brukerens nettleser vil bety at siden kan være vist fra sin (brukerens nettleser) cache.

Selvfølgelig er det mulig å sende de riktige overskriftene uten å bruke server-sidesporingsbufferen, men i dette tilfellet vil de fleste brukere motta siden innholdsoppdatering ganske sent. Med denne tilnærmingen stiller nettleseren noen ganger serveren til å motta oppdateringer, men frekvensen og reglene for hver nettleser er konfigurert av utvikleren, så det er ingen grunn til å håpe at brukerne vil motta oppdateringer i tide.

Vanligvis er cachen kategorisert av typen bruker:

• for autorisert;
• for uautorisert.

Denne divisjonen skyldes det unike av innholdet for hver autorisert bruker og generaliteten til innholdet for gjestebrukere. På de fleste nettsteder kan en uautorisert bruker ikke endre innholdet på nettstedet, og påvirke derfor innholdet.

Browser Cache lar deg lagre trafikk og tid brukt på lasting av sider. Men for å oppnå lagringseffekten må brukeren besøke ressursiden minst en gang, noe som betyr at belastningen på serverressurser vil redusere, men ikke betydelig.

2 server caching.

Server caching refererer til alle typer caching hvor data er lagret på tjenersiden. Denne informasjonen er ikke tilgjengelig for klient nettlesere. Hurtiglageret er opprettet og lagret på en en-til-mange basis (mange, i dette tilfellet, er klientinnretninger).

2.1. Full side caching

Mest effektiv cache. Dens største fordel er at siden er returnert nesten på tidspunktet for tilgang, som et resultat, er det evnen til å behandle millioner av forespørsler selv på de svakeste server med hastigheten på minnet og med lite CPU-bruken.

Denne type hurtigbuffer har også sine ulemper: for eksempel, den manglende evne til å cache sider for en autorisert bruker, eller for en bruker som har sideinnhold avhenger av den aktuelle brukervariabler.

Bruk denne cache hvis serveren kjenner alle de statiske tilstander av eksterne data, det vil si, faktisk, er dette den ideelle siden staten for gjestebrukere. Det bør tas i betraktning at med en slik caching, må arkitekturen for et påføringsstedet alltid behandle innkommende forespørsler på samme måte og gi samme type av respons. Slik tilstand eksisterer i enhver applikasjon eller et nettsted, det bare må spores og brukes på cache.

Bufring av hele sider, som oftest blir brukt i en slags nødstilfelle, mens den side bufferen lagres i en forutbestemt tid (fra 2 minutter), i løpet av hvilken svarene fra serveren er av samme type.

2.2. PHP kompilering caching

Det skilles mellom ren kompilering av kode og dens optimalisering under kompilering (substitusjon av skript).

2.3. Caching individuelle blokker av en side

Dette er den mest interessante og samtidig den vanskeligste typen caching. Likevel kan det også være effektivt; det er den enkleste måten å forklare prinsippene for caching generelt bruker sin eksempel.

Det er nødvendig å overvåke: tilstanden av tabellene, staten brukerøkten, om å slå av caching under POST eller GET forespørsler, avhengigheten av den aktuelle adressen, utholdenhet av caching (hvis den forrige betingelsene endres) eller dens dynamiske justering.

Caching individuelle sideblokkene er bedre enn andre typer caching hvis du trenger, for eksempel for å redusere antall forespørsler til databasen fra reelle (autoriserte) brukere.

2.4. PHP caching basert på udelte ressurser

best egnet for standardisering forespørsler, hente data fra delte ressurser, har interne variabler som php ressurser tilgang til flere ganger i løpet av side generasjon.

2.5. PHP caching basert på delte ressurser

Dette caching brukes til å lagre serialisert data. For eksempel, en konfigurasjonsfil, bord stater, filsystem lister.

2.6. Mysql Caching Basert på spørre Cache

Dette er en ganske velkjent og velkjent tema. Likevel, jeg ønsker å vurdere detaljene i å jobbe med tidsstempel og hvordan du kan unngå stadig spyle spørringsmellomlageret.

Hvis du bruker en stadig skiftende tidsstempel i slike spørsmål, vil SQL-cachen ikke bare være ubrukelig, men til og med skadelig, siden de fleste av de bufret spørringene vil akkumulere, de som er utdaterte på det tidspunktet cachen ble opprettet.

Som regel publiseres ethvert materiale på enkelte punkter i tide. For eksempel, 00:00. Alt du trenger å gjøre er å lage en forespørsel som vil evaluere tabellen med maksimal dato, mens mindre enn den nåværende.

Denne spørringen vil ikke bli bufret, men alle spørsmålene til dette tabellen vil bli bufret hvis nummeret deres er mer enn en.

2.7. MySQL caching av produksjon, aggregering tabeller

Det er en regel: Det bør være betydelig færre dataoppdateringer enn å lese for å returnere dem.

DNS Caching: Den beste utførelsen av nettstedet caching

Imidlertid er den beste typen caching mulig DNS-caching, som sparer webserveren fra unødvendig sideforberedelse for statiske sider, og bringer innholdet kopierer nærmere brukeren, og dermed gjør nettstedet levering raskere.

DNS Caching kan bli dyrt, men kan implementeres på nettstedene dine gratis ved å bruke teknologier som Ezoic -plattformen som optimaliserer innhold på nettsteder.

Store dataanalyse og statistikk ved siden caching

Det vil si, det gir ingen mening å samlet det vil endre seg i samme øyeblikk, mens relevansen av aggregerte data er viktig.

Hva du skal velge for aggregering? Vanligvis er dette en slags statistisk informasjon om antall poster, dato for siste oppdatering, forfatteren av den siste oppdateringen, og lignende.

For å finne ut hvordan caching påvirker EPMV, bør nettstedet eieren gjør du følgende:

1. Logg inn på din Ezoic konto;
2. I menyen til venstre, velg Site speed setting;
3. I rullegardinmenyen, klikk på Caching alternativet.

Brukeren er tatt til en side som viser analytiske data. En del av de data som er vist i form av en grafisk fremstilling, og den andre - i form av et bord, der den analytiske data er beskrevet i mer detalj.

Oversikt over grafen og tabelldata

Det bør bemerkes umiddelbart at dataene som vil bli gitt i denne artikkelen er bare gyldig for én bestemt nettsted. Hvis du er eier av din egen nettside, og du trenger også å få tilgang til slike analyser, må du registrere i Ezoic system.

Hovedfunksjonen til cachen er å fremskynde datainnhentingsprosessen. Det eliminerer behovet for å få tilgang til en saktere underliggende lagringsnivå. Den lille mengden cache -minne kompenseres med høy tilgangshastighet.

Med riktig Ezoic cache -innstillinger, kan du forbedre kvaliteten på nettstedet ditt for deg selv og brukerne dine.

En gang i Caching alternativet, vil eieren av nettstedet se en graf og en tabell under. Følgende data vil bli vist i tabellen for denne type analyser:

1. Ezoic cache nivå;
   
2. Browsing sider;
   
3. Gjennomsnittlig lastetiden;
   
4. Side inngrep hastighet;
   
5. Gjennomsnittlig tid til første byte;
   
6. Gjennomsnittlig interaksjon tid;
   
7. Gjennomsnittlig host responstid;
   
8. Avvisningsfrekvens;
   
9. Exit prosent;
   
10. Caching RPM (Revenue Per Mille).
    

Cache rammet.

En cache hit er det første nivået av cache i Ezoic. La oss ta en nærmere titt. Sidevisninger - 2.002.169, av det totale antall visninger, er dette 69,96%. Den gjennomsnittlige lastetiden for denne cache nivået var 00:36, mens gjennomsnittet for denne beregningen var 00:38. Siden inngreps satsen er 49.02%, gjennomsnittlig for dette kriteriet er 50,52 prosent. Gjennomsnittlig tid til første byte er 1,470.92 ms, det totale er 1,906.62 ms.

Den gjennomsnittlige tid for interaksjon dette cachenivå er 2,469.89 ms, mens det totale er 2,959.37 ms. Den gjennomsnittlige vertsrespons tid er 20,70 ms, med en total på 262.14 ms. Fluktfrekvensen er 28,96%, den generelle bounce rate er 28,47%. Avkjørselen prosentandelen er 84,73%, den totale prosentandelen er 84,52%.

RPM for en gitt cache tier er $ 5,32, og totalen for alle cache nivåer er $ 5.29.

Ikke treffer cache.

Ikke treffer cache er det andre nivået av caching i Ezoic. La oss ta en nærmere titt. Sidevisninger 727 702, av det totale antall visninger, er dette 24,43%. Den gjennomsnittlige lastetiden for denne cache nivået var 00:41, mens gjennomsnittet for denne beregningen var 00:38. Siden inngreps satsen er 54,52%, gjennomsnittlig for dette kriteriet er 50,52 prosent. Den gjennomsnittlige tid til den første byte er 2,558.18 ms, det totale er 1,906.62 ms.

Den gjennomsnittlige tid for interaksjon dette cachenivå er 3.677.07 ms, mens det totale er 2.959.37 ms. Den gjennomsnittlige vertsrespons tid er 415.68 ms, med en total på 262.14 ms. Den fluktfrekvens er 26,98%, den totale prosentandelen er 28,47%. Avkjørselen prosentandelen er 83,99%, den totale prosentandelen er 84,52%.

RPM for en gitt cache tier er $ 5,23, og totalen for alle cache nivåer er $ 5.29.

Bufferen er deaktivert.

Cache Off - Dette er det tredje nivået av caching i Ezoic. La oss ta en nærmere titt. Sidevisninger 132 113, av det totale antall visninger, er dette 4,62%. Den gjennomsnittlige lastetiden for denne cache nivået var 00:36, mens gjennomsnittet for denne beregningen var 00:38. Siden inngreps satsen er 51,20%, gjennomsnittlig for dette kriteriet er 50,52 prosent. Gjennomsnittlig tid til første byte er 4,695.58 ms, det totale er 1,906.62 ms.

Den gjennomsnittlige tid for interaksjon dette cachenivå er 6.169.49 ms, mens det totale er 2.959.47 ms. Gjennomsnittlig verten responstid er 3.075.51 ms, med et totalt gjennomsnitt på 262.14 ms. Den fluktfrekvens er 29,55%, den totale prosentandelen er 28,47%. Avkjørselen prosentandelen er 84,70%, den totale prosentandelen er 84,52%.

RPM for en gitt cache-tier er $ 5,17, og total for alle cache-tier er $ 5,29.

Big Data Analytics fra Ezoic

Big Data Analytics fra Ezoic is a relatively young product in the market for similar services from this company. It should be noted that it is very popular with website owners, and there are several reasons for this.

En av de første som tiltrekker seg oppmerksomhet - etter å ha registrert seg på deres ressurs, kan eieren få et stort utvalg av informasjon, som er veldig godt visualisert og lett å forstå selv blant de som er nye i denne virksomheten.

En annen grunn er det brukervennlige grensesnittet til produktet. Dette betyr at selv en ikke-avansert bruker vil kunne forstå funksjonaliteten, forstå hvor hva som er og hvordan man skal se på det.

Det finnes mange forskjellige kriterier i Big Data Analytics som du kan bruke til å undersøke Asset Analytics. For eksempel, når som helst kan du se hvor mye penger en ressurs genererer på et gitt øyeblikk, eller hvordan man ser lønnsomheten til sider avhengig av innflytelsen av deres alder.

Ofte Stilte Spørsmål

Hva er fordelene med hurtigbufring for et nettsted?

Den største fordelen med hurtigbufring for et nettsted er muligheten til å ikke lage siden for hver bruker. Dette vil gi deg muligheten til å jobbe med en stor mengde data på kortest mulig tid og med begrensede ressurser.

Hva betyr hurtigbufring?

Cache (eller cache) er en slags mellombuffer der data lagres. Takket være hurtigbufring blir ikke nettstedssiden gjenopprettet for hver bruker. Caching lar deg jobbe med en stor mengde data på kortest mulig tid og med begrensede ressurser (server og bruker).

Hva er forholdet mellom caching av nettstedet og EPMV, og hvordan kan utgivere lære om denne effekten?

Hurtigbufring kan påvirke EPMV positivt ved å få fart på lastetider på siden og forbedre brukeropplevelsen, noe som kan føre til økt annonseengasjement og inntekter. Utgivere kan analysere EPMV før og etter implementering av hurtigbufringsløsninger for å forstå virkningen.