• hjem
  •  > 
  • Råd
  •  > 
  • Nginx-filbufring. Buffer Wordpress med Nginx

Nginx-filbufring. Buffer Wordpress med Nginx

|

Jo raskere et nettsted laster inn, jo større er sjansen for å beholde besøkende. Nettsteder med mange bilder og interaktivt innhold som kjører skript i bakgrunnen er svært vanskelig å laste raskt. Lasteprosessen til et slikt nettsted består av et stort antall forespørsler til forskjellige filer. Jo færre slike forespørsler serveren sender, jo raskere vil siden lastes.

Det er mange måter å øke hastigheten på lasting av nettsider, og nettleserbufring er en av de viktigste. Dette gjør at nettleseren kan gjenbruke lokale kopier av tidligere nedlastede filer. For å gjøre dette må du introdusere nye HTTP-svarhoder.

Header-modulen til Nginx-webserveren vil hjelpe deg med dette. Denne modulen kan legge til vilkårlige overskrifter til svaret, men dens hovedrolle er å definere bufringshoder. Denne opplæringen viser hvordan du bruker header-modulen til å konfigurere nettleserbufring.

Krav
  • Ubuntu 16.04 server (du kan finne ut om hvordan du setter opp serveren).
  • En bruker med tilgang til sudo-kommandoen.
  • Forhåndsinstallert Nginx webserver (installasjonsveiledning – ).
  • Kartmodul (instruksjoner for oppsett av denne modulen er i).
1: Lag testfiler

For å komme i gang, lag noen testfiler i standard Nginx-katalogen. Disse filene kan senere brukes til å sjekke nettleserbufring.

For å bestemme hvilken type fil som overføres over nettverket, analyserer ikke Nginx innholdet (det ville være for tregt), i stedet ser den på filtypen for å bestemme dens MIME-type, som bestemmer formålet med filen.

Derfor spiller det ingen rolle i det hele tatt hva testfilene vil inneholde. Bare gi dem de riktige navnene og utvidelsene, og Nginx vil behandle den tomme filen som et bilde eller et stilark.

I standard Nginx-katalog, lag en test.html-fil ved å bruke truncate. Som du kan se fra utvidelsen, vil dette være en HTML-fil.

sudo truncate -s 1k /var/www/html/test.html

På samme måte, lag noen flere testfiler med jpg (bilde), css (stilark) og js (JavaScript) utvidelser:

sudo truncate -s 1k /var/www/html/test.jpg
sudo truncate -s 1k /var/www/html/test.css
sudo truncate -s 1k /var/www/html/test.js

2: Sjekker Nginx Standard Behavior

Som standard bufres alle filer likt. For å bekrefte dette, bruk en test HTML-fil.

Send en forespørsel til test.html fra din lokale Nginx-server og se svarhodene:

Denne kommandoen vil returnere en svaroverskrift slik:

HTTP/1.1 200 OK

Dato: lør 10. september 2016 13:12:26 GMT
Innholdstype: tekst/html
Innholdslengde: 1024

Tilkobling: holde i live
ETag: "57d40685-400"
Godta-områder: bytes

I den røde uthevede linjen ser du ETag-overskriften, som inneholder den unike identifikatoren til denne visningen av den forespurte filen. Hvis du kjører curl-kommandoen igjen, vil du se nøyaktig samme ETag-verdi.

Nettleseren lagrer ETag-verdien og sender den tilbake til serveren i svarhodet If-None-Match når den trenger å be om filen på nytt (for eksempel når siden oppdateres).

Du kan simulere denne oppførselen med følgende kommando:

curl -I -H "If-None-Match: "57d40685-400"" http://localhost/test.html

Merk: Skriv inn ETag-verdien din i stedet for 57f6257c-400.

Kommandoen vil nå returnere:

HTTP/1.1 304 Ikke endret
Server: nginx/1.10.0 (Ubuntu)
Dato: lør 10. september 2016 13:20:31 GMT
Sist endret: lør 10. september 2016 13:11:33 GMT
Tilkobling: holde i live
ETag: "57d40685-400"

Denne gangen vil Nginx returnere 304 Not Modified. Nettserveren vil ikke videresende filen igjen, den vil ganske enkelt fortelle nettleseren at den kan gjenbruke den tidligere nedlastede filen.

Dette reduserer nettverkstrafikken, men er ikke helt nok til å oppnå høy bufferytelse. Problemet med ETag er at nettleseren alltid må sende en forespørsel til serveren om å gjenbruke sin bufrede fil. Serveren svarer med en 304 i stedet for en fil, men denne prosedyren tar fortsatt mye tid.

3: Sette opp Cache-Control og Expires-hodene

I tillegg til ETag er det ytterligere to svarhoder for å kontrollere caching: Cache-Control og Expires. Cache-Control er en nyere header som har flere funksjoner enn Expires og er generelt mer nyttig for å sette opp caching.

Disse overskriftene forteller nettleseren at den forespurte filen kan lagres lokalt i en viss periode (inkludert for alltid) uten å be om den på nytt. Hvis disse overskriftene ikke er konfigurert, vil nettleseren hele tiden bli tvunget til å be om filer fra serveren og forvente et 200 OK eller 304 Ikke endret svar.

Disse HTTP-hodene kan konfigureres ved hjelp av header-modulen. Header-modulen er innebygd i Nginx, noe som betyr at den ikke trenger å installeres.

For å legge til denne modulen, åpne standard Nginx virtuell vertsfil i et tekstredigeringsprogram:

sudo nano /etc/nginx/sites-available/default

Finn serverblokken:

. . .

#
server (
lytt 80 default_server;

. . .

Plasser to nye seksjoner i filen: en før serverblokken (angi varigheten av hurtigbufring av filer av ulike typer), og den andre inne i denne blokken (innstilling av bufringsoverskrifter).

. . .
# Standard serverkonfigurasjon
#
# Utløper kart
kart $sent_http_content_type $expires (
standard av;
tekst/html epoke;
tekst/css maks;
applikasjon/javascript maks;
~bilde/maks;
}
server (
lytt 80 default_server;
lytt [::]:80 default_server;
expires $expires;
. . .

Seksjonen før serverblokken er en ny kartblokk som definerer samsvaret mellom filtypen og lagringsperioden i hurtigbufferen.

  • av er standard og legger til ingen bufringskontrolloverskrifter. Dette er en forholdsregel for innhold som ikke har noen spesifikke bufringskrav.
  • text/html er satt til epoke. Dette er en spesiell verdi som deaktiverer caching, som et resultat av at nettleseren alltid vil be om gjeldende tilstand til nettstedet.
  • tekst/css (stilark) og applikasjon/javascript (Javascript-filer) er satt til maks. Dette betyr at nettleseren vil cache disse filene så lenge som mulig, noe som reduserer antallet forespørsler betydelig (gitt at det vanligvis er mange slike filer).
  • ~image/ er et regulært uttrykk som søker etter alle filer med MIME-typen image/ (for eksempel image/jpg og image/png). Den har også verdien max, siden det er mange bilder, samt stilark, på nettsteder. Ved å bufre dem vil nettleseren redusere antall forespørsler.

Utløpsdirektivet (inkludert i overskriftsmodulen) konfigurerer overskrifter for å kontrollere caching. Den bruker verdien til $expires-variabelen som er spesifisert i kartblokken, noe som får svarhodene til å variere avhengig av filtypen.

Lagre og lukk filen.

For å oppdatere innstillingene, start Nginx på nytt:

sudo systemctl start nginx på nytt

4: Testing av nettleserbufring

Kjør samme spørring som i begynnelsen av veiledningen:

curl -I http://localhost/test.html

Responstidene vil variere. Du vil se to nye svaroverskrifter i utdataene

HTTP/1.1 200 OK
Server: nginx/1.10.0 (Ubuntu)
Dato: lør 10. september 2016 13:48:53 GMT
Innholdstype: tekst/html
Innholdslengde: 1024
Sist endret: lør 10. september 2016 13:11:33 GMT
Tilkobling: holde i live
ETag: "57d40685-400"
Utløper: tor 1. januar 1970 00:00:01 GMT
Cache-kontroll: ingen cache
Godta-områder: bytes

Expires-overskriften viser en dato i fortiden, og Cache-Control er satt til no-cache, noe som betyr at nettleseren hele tiden må be om den nyeste versjonen av filen (ved å bruke ETag-overskriften).

Be om en annen fil:

curl -I http://localhost/test.jpg
HTTP/1.1 200 OK
Server: nginx/1.10.0 (Ubuntu)
Dato: lør 10. september 2016 13:50:41 GMT
Innholdstype: image/jpeg
Innholdslengde: 1024
Sist endret: lør 10. september 2016 13:11:36 GMT
Tilkobling: holde i live
ETag: "57d40688-400"
Utløper: tor 31. desember 2037 23:55:55 GMT
Cache-kontroll: maks-alder=315360000
Godta-områder: bytes

Som du kan se, er resultatet annerledes. Expires inneholder en dato i fjern fremtid, og Cache-Control har en maks-aldersverdi som forteller nettleseren hvor lenge den kan cache filen (i sekunder). I dette tilfellet vil nettleseren cache den nedlastede filen så lenge som mulig, slik at nettleseren i fremtiden vil bruke den lokale cachen til å laste ned dette bildet.

Prøv å spørre test.js- og test.css-filene, du bør få et lignende resultat.

Curl-kommandoen viser at nettleserbufring har blitt konfigurert. Sidebufring vil øke nettstedets ytelse og redusere antall forespørsler.

Merk: Denne guiden tilbyr praktiske caching-innstillinger som passer til et gjennomsnittlig nettsted. For å forbedre nettstedets ytelse, analyser innholdet på nettstedet ditt og juster hurtigbufringsinnstillingene dine basert på hvilke filer som er mest rikelig på nettstedet ditt.

Caching er en teknologi eller prosess for å lage en kopi av data på raskt tilgjengelige lagringsmedier (cache, kontanter). Enkelt sagt og brukt på realitetene ved nettstedbygging, kan dette være å lage en statisk HTML-kopi av en side eller en del av den, som genereres ved hjelp av PHP-skript (eller andre, som Perl, ASP.net), avhengig av hvilket språk nettstedets CMS er skrevet på) og er lagret på disk, i RAM eller til og med delvis i nettleseren (vi skal se på det mer detaljert nedenfor). Når det oppstår en forespørsel om en side fra en klient (nettleser), i stedet for å sette den sammen med skript, vil nettleseren motta en ferdig kopi av den, som er mye mer økonomisk når det gjelder vertsressurser, og raskere, siden overføring av den ferdige siden tar kortere tid (noen ganger betydelig mindre), enn å lage den på nytt.

Hvorfor bruke caching på nettstedet ditt?
  • For å redusere belastningen på hosting
  • For raskt å vise nettstedinnhold til nettleseren

Begge argumentene tror jeg ikke krever noen kommentar.

Ulemper og negative effekter av webbufring

Merkelig nok har webbufring også sine ulemper. Først og fremst gjelder dette nettsteder hvis innhold endres dynamisk når de samhandler med det. Ofte er dette nettsteder som serverer innhold eller deler av det ved hjelp av AJAX. Generelt er AJAX-bufring også mulig og til og med nødvendig, men dette er et emne for en annen diskusjon og angår ikke tradisjonelt brukte teknologier, som vil bli diskutert senere.
Det kan også oppstå problemer for registrerte brukere, for hvem en vedvarende cache kan bli et problem når de samhandler med nettstedselementer. Her er som regel cachen deaktivert, eller objektbufring av individuelle sideelementer brukes: widgets, menyer og lignende.

Hvordan sette opp caching på nettstedet ditt

Først må vi finne ut hvilke teknologier som tradisjonelt brukes til å bufre nettstedinnhold.
Alle mulige metoder kan deles inn i 3 grupper

Buffer på serversiden Bufring med NGINX Bufring med htaccess (Apache)

Hvis du bare har tilgang til .htaccess og produksjonsserveren kun er Apache, kan du bruke teknikker som gzip-komprimering og Expires-hoder for å dra nytte av nettleserbufferen.

Aktiver gzip-komprimering for passende MIME-filtyper

AddOutputFilterByType DEFLATE tekst/ren tekst/html AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE tekst/javascript-applikasjon/javascript-applikasjon/x-javascript AddOutputFilterByType DEFLATE tekst/xml-applikasjon/xml-applikasjon/xml-applikasjon/xml-Filterhtml ATE-applikasjon/json AddOutputFilterByType DEFLATE application/vnd.ms-fontobject application/x-font-ttf font/opentype image/svg+xml image/x-icon

Vi aktiverer Expires-overskrifter for statiske filer for en periode på 1 år (365 dager)

ExpiresActive on ExpiresStandard "tilgang pluss 365 dager"

Bufring med Memcached Bufring med php-akselerator

Hvis nettstedmotoren er skrevet i PHP, kjøres PHP-skript hver gang en side på nettstedet lastes: kodetolkeren leser skriptene skrevet av programmereren, genererer bytekode fra dem som er forståelig for maskinen, utfører den og produserer resultatet. PHP-akseleratoren eliminerer konstant generering av bytekode ved å bufre den kompilerte koden i minnet eller på disken, og øker dermed ytelsen og reduserer tiden brukt på å utføre PHP. Blant de for øyeblikket støttede akseleratorene er det:

  • Windows Cache Extension for PHP
  • XCache
  • Send OPcache

PHP-versjoner 5.5 og nyere har allerede Zend OPcache-akseleratoren innebygd, så for å aktivere akseleratoren trenger du bare å oppdatere PHP-versjonen din

Bufring på siden

Som regel refererer dette til muligheten til nettstedets CMS til å lage statiske HTML-kopier av sider. De fleste populære motorer og rammeverk har denne muligheten. Personlig har jeg jobbet med Smarty, WordPress, så jeg kan forsikre deg om at de gjør en utmerket jobb. Den originale WordPress ut av esken har ikke bufringsmuligheter, som er nødvendige for ethvert litt lastet prosjekt, men det er mange populære plugins for caching:

  • , som er ansvarlig for å generere statiske nettsider;
  • Hyper Cache, som i hovedsak fungerer på samme måte som forrige plugin;
  • DB Cache. Essensen av arbeidet er bufring av spørringer til databasen. Også en veldig nyttig funksjon. Kan brukes sammen med de to forrige pluginene;
  • W3 Total Cache. Lagret det til dessert, dette er min favorittplugin i WordPress. Med den blir stedet forvandlet, og blir fra en stor buss til en racerbil. Dens store fordel er et stort utvalg av funksjoner, for eksempel flere hurtigbufringsalternativer (statikk, akseleratorer, Memcached, databasespørringer, objekt- og sidebufring), kodesammenkobling og minifisering (sammenslåing og komprimering av CSS, Javascript-filer, HTML-komprimering ved å fjerne mellomrom) , bruker CDN og mye mer.

    • Hva kan jeg si - bruk riktig CMS, og caching av høy kvalitet vil være tilgjengelig nesten ut av esken.

    Nettleser (klient) sidebufring, bufring overskrifter

    Nettleserbufring er mulig fordi enhver nettleser med respekt for seg selv tillater og oppmuntrer til det. Dette kan skyldes HTTP-hodene som serveren gir til klienten, nemlig:

    • Utløper;
    • Cache-kontroll: maks-alder;
    • Sist endret;
    • ETag.

    Takket være dem bruker brukere som gjentatte ganger besøker nettstedet svært lite tid på å laste inn sider. Bufret overskrifter bør brukes på alle bufrede statiske ressurser: malfiler, bildefiler, javascript- og css-filer hvis tilgjengelig, PDF, lyd og video, og så videre.
    Det anbefales å sette overskrifter slik at statiske data lagres i minst en uke og ikke mer enn ett år, helst et år.

    Utløper

    Expires-overskriften kontrollerer hvor lenge hurtigbufferen er gjeldende, og nettleseren kan bruke bufrede ressurser uten å spørre serveren om en ny versjon av dem. Det er sterkt og svært ønskelig å bruke, da det er obligatorisk. Det anbefales å angi en periode fra en uke til et år i tittelen. Det er bedre å ikke spesifisere mer enn et år, dette er et brudd på RFC-reglene.

    For eksempel, for å konfigurere Expires i NGINX for alle statiske filer i et år (365 dager), må koden være til stede i NGINX-konfigurasjonsfilen

    Plassering ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ ( utløper 365d; )

    Cache-kontroll: maks-alder;

    Cache-Control: max-age gjør det samme.
    Det er mer å foretrekke å bruke Expires enn Cache-Control på grunn av dens større utbredelse. Imidlertid, hvis Expires og Cache-Control er tilstede i overskriftene samtidig, vil prioritet bli gitt til Cache-Control.

    I NGINX er Cache-Control aktivert på samme måte som Expires , med expires: 365d-direktivet;

    Last-Modified og ETag

    Disse overskriftene fungerer etter prinsippet om digitale fingeravtrykk. Dette betyr at hver URL i cachen vil ha sin egen unike ID. Last-Modified oppretter den basert på siste endringsdato. ETag-overskriften bruker en hvilken som helst unik ressursidentifikator (oftest en filversjon eller en innholds-hash). Last-Modified er en "svak" overskrift fordi nettleseren bruker heuristikk for å bestemme om elementet skal bes om fra hurtigbufferen.

    I NGINX er ETag og Last-Modified aktivert som standard for statiske filer. For dynamiske sider er det enten bedre å ikke spesifisere dem, eller så bør skriptet som genererer siden gjøre dette, eller best av alt, bruk en riktig konfigurert cache, så tar NGINX seg av overskriftene selv. For eksempel, for WordPress, kan du bruke .

    Disse overskriftene lar nettleseren effektivt oppdatere bufrede ressurser ved å sende GET-forespørsler hver gang brukeren eksplisitt laster inn siden på nytt. Betingede GET-forespørsler returnerer ikke et fullstendig svar med mindre ressursen har endret seg på serveren, og gir dermed lavere ventetid enn fulle forespørsler, og reduserer dermed vertsbelastning og responstid.

    Samtidig bruk av Expires og Cache-Control: max-age er overflødig, akkurat som samtidig bruk av Last-Modified og ETag er overflødig. Bruk Expires + ETag eller Expires + Last-Modified i kombinasjon.

    Aktiver GZIP-komprimering for statiske filer

    Selvfølgelig er GZIP-komprimering ikke direkte relatert til caching som sådan, men det sparer mye trafikk og øker sidelastingshastigheten.

    Hvordan aktivere GZIP for statisk i server ( .... gzip på; gzip_disable "msie6"; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript applikasjon /javascript; ) Slik aktiverer du GZIP for statisk i For å aktivere gzip-komprimering i .htaccess, må du sette inn følgende kode i begynnelsen av filen: AddOutputFilterByType DEFLATE text/plain AddOutputFilterByType DEFLATE text/html AddOutputFilterByTypTypeByType AddOutputFilterByTypeByType DEFLATE text/css AddOutputFilterByType DEFLATE application/ xml AddOutputFilterByType DEFLATE application/xhtml+xml AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/javascript AddOutputTypeFilter

    |

    Nginx inkluderer en FastCGI-modul som lar deg bruke direktiver for caching av dynamisk innhold i PHP-grensesnittet. FastCGI eliminerer behovet for å finne flere sidebufringsløsninger (som omvendte proxyer eller tilpassede programplugins). Innhold kan også ekskluderes fra bufring basert på forespørselsmetoden, URL, informasjonskapsler eller andre servervariabler.

    Aktiverer FastCGI Caching

    For å følge denne veiledningen må du først. Du må også redigere den virtuelle vertskonfigurasjonsfilen:

    nano /etc/nginx/sites-enabled/vhost

    Legg til følgende linjer til toppen av filen utenfor server()-direktivet:

    Fastcgi_cache_path-direktivet spesifiserer banen til cachen (/etc/nginx/cache), dens størrelse (100m), minnesonenavn (MYAPP), underkatalognivåer og inaktiv tidtaker.

    Cachen kan plasseres på et hvilket som helst passende sted på harddisken. Maksimal hurtigbufferstørrelse bør ikke overstige server-RAM + swap-filstørrelse; ellers vil feilmeldingen Kan ikke tildele minne vises. Hvis cachen ikke har blitt brukt i en bestemt tidsperiode spesifisert av "inaktiv"-alternativet (60 minutter i dette tilfellet), sletter Nginx den.

    Fastcgi_cache_key-direktivet spesifiserer hvordan filnavn hashes. I henhold til disse innstillingene vil Nginx kryptere filer ved hjelp av MD5.

    Nå kan vi gå videre til lokasjonsdirektivet, som sender PHP-forespørsler til php5-fpm-modulen. I plassering ~ .php$ ( ), legg til følgende linjer:

    fastcgi_cache MYAPP;
    fastcgi_cache_valid 200 60m;

    Fastcgi_cache-direktivet refererer til en minnesone som allerede var spesifisert i fastcgi_cache_path-direktivet.

    Som standard beholder Nginx bufrede objekter i en tidsperiode spesifisert ved hjelp av en av disse overskriftene:

    X-Accel-Utløper
    Utløper
    Cache-kontroll.

    Fastcgi_cache_valid-direktivet spesifiserer standard cache-alder hvis ingen av disse overskriftene er til stede. Som standard lagres kun svar med statuskode 200 (selvfølgelig kan andre statuskoder spesifiseres).

    Sjekk FastCGI-innstillingene dine

    service nginx configtest

    Start deretter Nginx på nytt hvis innstillingene er ok.

    service nginx reload

    På dette stadiet skal vhost-filen se slik ut:

    fastcgi_cache_path /etc/nginx/cache levels=1:2 keys_zone=MYAPP:100m inaktiv=60m;
    fastcgi_cache_key "$scheme$request_method$host$request_uri";
    server (
    hør 80;
    root /usr/share/nginx/html;
    indeks index.php index.html index.htm;
    servernavn eksempel.com;
    plassering/(
    try_files $uri $uri/ /index.html;
    }
    plassering ~ \.php$ (
    try_files $uri =404;
    fastcgi_pass unix:/var/run/php5-fpm.sock;
    fastcgi_index index.php;
    inkluderer fastcgi_params;
    fastcgi_cache MYAPP;
    fastcgi_cache_valid 200 60m;
    }
    }

    Nå må vi sjekke om caching fungerer.

    Sjekker FastCGI-bufring

    Lag en PHP-fil som sender ut UNIX-tidsstemplet.

    /usr/share/nginx/html/time.php

    Legg til i filen:

    Be deretter om denne filen flere ganger via curl eller en nettleser.

    root@server:~# curl http://localhost/time.php;echo
    1382986152

    1382986152
    root@server:~# curl http://localhost/time.php;echo
    1382986152

    Hvis hurtigbufring gjøres riktig, vil tidsstemplet for alle forespørsler samsvare (siden svaret har blitt bufret).

    For å finne hurtigbufferen til denne spørringen, må du utføre en cache-tilbakeskrivning

    root@server:~# ls -lR /etc/nginx/cache/
    /etc/nginx/cache/:
    totalt 0
    drwx------ 3 www-data www-data 60 28. okt 18:53 e
    /etc/nginx/cache/e:
    totalt 0
    drwx------ 2 www-data www-data 60 28. okt 18:53 18
    /etc/nginx/cache/e/18:
    totalt 4
    -rw------- 1 www-data www-data 117 28. okt 18:53

    Du kan også legge til en X-Cache-header, som vil indikere at forespørselen ble behandlet fra cachen (X-Cache HIT) eller direkte (X-Cache MISS).

    Over server ( )-direktivet skriver du inn:

    add_header X-Cache $upstream_cache_status;

    Start Nginx-tjenesten på nytt og send en detaljert forespørsel ved å bruke curl for å se den nye overskriften.

    root@server:~# curl -v http://localhost/time.php
    * Om å koble () til localhost port 80 (#0)
    * Prøver 127.0.0.1...
    * tilkoblet
    * Koblet til localhost (127.0.0.1) port 80 (#0)
    > FÅ /time.php HTTP/1.1
    > User-Agent: curl/7.26.0
    > Vert: lokalvert
    > Godta: */*
    >
    * HTTP 1.1 eller nyere med vedvarende tilkobling, pipelining støttes
    < HTTP/1.1 200 OK
    < Server: nginx
    < Date: Tue, 29 Oct 2013 11:24:04 GMT
    < Content-Type: text/html
    < Transfer-Encoding: chunked
    < Connection: keep-alive
    < X-Cache: HIT

    Send en POST-forespørsel til denne filen med URL-en du vil skrape.

    curl -d "url=http://www.example.com/time.php" http://localhost/purge.php

    Skriptet vil sende ut sant eller usant avhengig av om hurtigbufferen ble tømt eller ikke. Pass på å ekskludere dette skriptet fra caching, og ikke glem å begrense tilgangen til det.

    Tags: ,

    Databufring på klientsiden er muligheten til å konfigurere en engangsnedlasting av data av en bestemt type og deretter lagre dem i klientens minne. Ved å bufre nginx-nettleseren eller bruke en annen server kan du redusere antall forespørsler fra klientmaskinen, og som et resultat, belastningen, og også øke lastehastigheten til nettsteder.

    De. klienten får tilgang til sidesiden - serveren behandler forespørselen, den genererte siden sendes til klienten sammen med en viss overskrift. Nettleseren lagrer informasjonen lokalt og returnerer den når du blir bedt om det igjen.

    CSS- og Javascript-stilbilder bufres. Nginx nettleserbufring implementeres ved å legge til Cache-control-overskriften.

    I overskrifter overføres tjenesteinformasjon fra serveren til klientnettleseren, hvorfra nettleseren lærer når den trenger å lagre data av en bestemt type og hvor lenge den skal lagres i minnet.

    Nginx nettleserbufring

    I Nginx-konfigurasjonsfilen er JS/CSS-caching aktivert som følger (andre utvidelser er lagt til - i praksis er det bedre å cache dem alle):

    server (
    …
    plassering ~* \.(jpg|jpeg|gif|png|ico|css|bmp|swf|js|html|txt)$ (
    utløper maks;
    root /home/website/example.com/;
    }
    …
    }

    expires max betyr at TTL er satt til uendelig og hvis filene på serveren endres, vil klienten aldri få vite om det siden en gjentatt forespørsel ikke vil bli sendt.

    utløper (denne overskriften vil bli diskutert nedenfor) bestemmer når nettleseren vil oppdatere cachen, verdien settes i sekunder.

    Vanligvis settes utløpsmaksverdien i serverkonfigurasjonen, og deretter i applikasjonen, når du kobler til css- og js-filer, bestemmes versjonene deres, som bør endres hver gang innholdet oppdateres.

    Spesifisere caching-overskrifter på programnivå

    Serveren i dette tilfellet vil oppfatte hver nye versjon som en ny fil som legges til og vil cache den.

    Sammen med Cache-Control er Expires-overskriften ofte spesifisert - den tvinger frem datoen og klokkeslettet når nettleseren vil tilbakestille den eksisterende cachen; neste gang brukeren kontakter, vil de oppdaterte dataene bli lastet inn i hurtigbufferen igjen.

    Den valgfrie HTTP Expires-headeren spesifiserer datoen og klokkeslettet når nettleseren skal oppdatere cachen (hodene kan brukes sammen; Expires har en lavere verdi når begge overskriftene brukes):

    Begge overskriftene kan settes i applikasjonsnivåkode.

    Aktiverer caching i PHP

    De fleste nettprosjekter er skrevet på PHP-språket; i PHP er Cache-control og Expires HTTP-hodene satt som følger: