U prethodnom članku o web tehnologijama spomenuli smo koristan članak Keširanje u HTTP-u (u daljem tekstu: "Članak sa nomagic.ru"). O članku smo, međutim, imali pitanja, a rasprava je zamrla, pa smo sve odgovore morali tražiti sami. Pitanja se, naime, ne odnose posebno na članak - gomilaju se već nekoliko godina. Umorni su od toga što su oni neriješeni, a članak je samo dao razlog da se aktivnije traže rješenja.
Alati
Prvo pitanje je kako vidjeti HTTP zaglavlja zahtjeva pretraživača i odgovora servera? Autor članka sa nomagic.ru preporučuje korištenje "Web Developer Tools" u Firefoxu "za ovu svrhu i neku vrstu blatnjave" DevToolbar" za IE. Ruka je ispružila ruku da klikne na vezu, ali je visjela u zraku:
1) Web Developer alate za FF već imamo, a ne postoji alat za pregled HTTP zaglavlja, čak je i DOM inspektor u verziji 3 iz nekog razloga uklonjen!
3) I vrlo sumorna misao: u redu, recimo da imamo LiveHTTPHeaders za FF; sa IE - odjednom da imate sreće; pa, šta je sa Operom? A šta je sa Google hromom?
Zašto ne biste prikazali sva HTTP zaglavlja direktno na web lokaciji koristeći PHP alate? Na kraju krajeva, postoji varijable okruženja, varijable za rad sa serverom i sve to. Odnosno, znamo tačno šta postoji, na primjer, $ _SERVER ["HTTP_HOST"] i HTTP_REFERER (koristimo ga na svim stranicama). Sve ostalo se mora dodati HTTP_- ovdje će biti zaglavlja zahtjeva. Štaviše, PHP ima posebnu funkciju getallheaders () za ovo. Ili apache_request_headers (). I apache_response_headers (). Da. Ovo će prikazati sva HTTP zaglavlja. Naizgled. Ali nas je čekao težak udarac ispod pojasa i 15 minuta muke, što je rezultiralo otkrićem: na našem hostingu PHP je instaliran kao cgi (a ne kao Apache modul) && u ovoj konfiguraciji sve ove funkcije ... zaglavlja () ne rade!
Pokretanjem skripte sa echo phpinfo () i pregledavajući rezultat, nalazimo da se potrebna zaglavlja HTTP zahtjeva nalaze u nizu $ _ENV(i nigde drugde). U redu, _env je tako _env. Ali ima mnogo svakakvog smeća (trenutno nam je suvišno), pa kreiramo novi niz $ varrvis i pažljivo odrežite manje-više potrebne komade iz _env tamo:
Foreach ($ _ ENV kao $ ke => $ va) (if (preg_match ("/ ^ HTTP \ _ / i", $ ke) &&! Preg_match ("/ COOKIE / i", $ ke)) $ varrvis [" $ ke "] = $ va;)
Ali da dobijemo zaglavlja odgovora našeg servera - pa, konačno, ništa, osim funkcije headers_list ()... I samo ona zaglavlja koja ćemo sami poslati u PHP skriptu koristeći funkciju zaglavlje ()... U teoriji, funkcija headers_list () treba pokrenuti nakon što su sva zaglavlja napisana. To smo otprilike uradili, iako, najvjerovatnije, za ovu stranicu (mjesto na kojem su eksperimenti napravljeni) nije važno, jer se svuda koristi ob_start ("ob_gzhandler")... Dodajte sljedeću konstrukciju na kraj skripti koje se testiraju:
Foreach (headers_list () kao $ ke => $ va) ($ varrvis [$ ke] = $ va;)
I dopunjavamo naš niz zaglavlja odgovorima servera. I između Zahtjeva i Odgovora, radi čitljivosti, umetnite red:
$ varrvis ["Odgovor"] = "===============================";
Ostaje na samom kraju skripte koje treba testirati za pisanje print_r ($ varrvis)- a zatim veselo listajte stranice stranice u svim dostupnim pretraživačima, diveći se HTTP zaglavljima.
HTTP keširanje s Apache instrukcijama
Članak sa nomagic.ru ukazuje na dva izvora instrukcija za keširanje: Apache konfiguracione datoteke (http.conf && .htacces) i PHP skriptu direktno sa komandama poput zaglavlja ("Pragma: no-cache"). Ali još uvijek postoji treći izvor - može se otkriti jednostavnim iskustvom:
1) pisati (dekomentirati) u httpd.conf(Apache 1.3.39) linije:
LoadModule expires_module modules / mod_expires.so LoadModule headers_module modules / mod_headers.so AddModule mod_expires.c AddModule mod_headers.c
2) u folderu naše stranice u .htaccess dodajte uputstva:
Zaglavlje dodaj Cache-Control "javno" ExpiresActive On ExpiresDefault "pristup plus 1 sat"
3) napisati jednostavnu skriptu pi.php iz dva reda:
4) otvorite pi.php stranicu u Firefoxu i pogledajte je u LiveHTTPHeaders (Naš PHP "alat" može prikazati samo zaglavlja poslana od strane funkcije zaglavlja (), mi ga za sada ne koristimo). sljedeće linije vezane za keširanje:
Kontrola predmemorije: bez skladištenja, bez keširanja, mora se ponovo potvrditi, naknadna provjera = 0, prethodna provjera = 0 Ističe: Čet, 19. novembar 1981. 08:52:00 GMT Pragma: bez keširanja
Voila. I ne treba vam nikakva Wikipedia - ovdje su zaglavlja koja ubijaju keširanje. Dolaze iz trećeg izvora - datoteke php.ini. U njemu je, po defaultu, prilikom instaliranja PHP-a napisano sljedeća instrukcija, posebno:
Session.cache_limiter = nocache
Ona je ta koja tjera PHP da šalje zaglavlja protiv keš memorije pod određenim uvjetima (na primjer, kada se koristi funkcija session_register ()). Mi smo se, naravno, malo prevarili prilagođavajući situaciju ovim uslovima. Ali ko može garantovati da nikada neće koristiti funkciju u svojim skriptama session_register ()? Da, generalno, i bez toga, situacija je prilično loša: uklonite prvi red iz pi.php skripte (ostavljajući samo echo phpinfo (;) - također ništa dobro:
I to je sve što Apache instrukcije za keširanje daju u kombinaciji sa "session.cache_limiter = nocache" u php.ini. Nedostaje najvažniji naslov - Zadnja izmjena(datum kada je stranica posljednji put izmijenjena), bez čega je nemoguće pravilno instalirati ili pravilno uništiti keširanje u pretraživaču.
Najsmješniji rezultat se dobija ako "povučete papagaja za obje noge odjednom" - napišite "session.cache_limiter = private" u php.ini (trebate ponovo pokrenuti Apache) i ostavite red session_register ("var1") u skripti :
Kontrola predmemorije: privatno, maksimalna starost = 300, prethodna provjera = 300 Ističe: Čet, 19. novembar 1981. 08:52:00 GMT Zadnja izmjena: Pon, 06. jul 2009. 15:13:40 GMT
Pojavljuje se Zadnja izmjena koji pokazuje vrijeme posljednje izmjene php skripte, i Cache-Control protivreči Ističe... Ponašanje pretraživača će biti nepredvidivo.
Ispravno HTTP keširanje
U posljednjim naslovima koje smo dobili tokom našeg iskustva, nedosljednost općenito nije nimalo fatalna: pretraživači ovo još nisu vidjeli, prilično su "imuni na buku" na takve stvari. Najveći problem je samo Zadnja izmjena, koji je potreban i korisnicima (pretraživačima) i pretraživačima. Jasno je da se datum modifikacije PHP datoteke ne može koristiti za to – jer stvarni sadržaj stranice možda nema nikakve veze sa ovim datumom: obično se sadržaj stranice preuzima iz baze podataka, a datum njegove izmjene također se mora preuzeti odatle (od DB).
Ako je ovo konkretan članak sa naše stranice, jednostavno uzimamo datum trenutnog posta iz polja `datrec` u tabeli `članaka`. Ako je ovo lista članaka (na glavnoj stranici sajta), tražimo najviši datum od svih zapisa koristeći formulu "odaberi maksimum (`datrec`) iz `članaka`" - ovo je datum posljednja promjena stranice, koju ćemo prenijeti u naslov Zadnja izmjena.
Postoje još dvije "tačke kontrole" za sadržaj koji se implementira pomoću HTTP zaglavlja:
1) Etag- hash sadržaja stranice, dobijen, na primjer, korištenjem funkcije md5(tekst_stranice);
2) Dužina sadržaja- ukupna dužina teksta poslanog pretraživaču kao odgovor na njegov zahtjev.
Ne možemo koristiti Dužina sadržaja, jer se ovaj parametar stalno mijenja: u desnoj koloni svake stranice imamo podsjetnik da je ovo ipak stranica reklamnih novina "Business Week" - lista proizvoda iz najnovijeg broja novina. Ova lista je prilično velika, tako da stranica prikazuje samo mali dio odabrane liste nasumično.
Kako, pitate, koristimo Etag- I on se onda stalno nasumično mijenja? Vrlo je jednostavno: ne uključujemo promjenljivi dio stranice u hash, već sastavljamo hash samo "iz materijala baze podataka članaka". Zašto ne možete učiniti isto sa Dužina sadržaja? Jer Dužina sadržaja pretraživač može lako provjeriti (IE radi upravo to - šalje nazad stvarnu dužinu primljenog sadržaja na server). A hash se može pisati nasumično (glavna stvar je da se mijenja kada se prati dio stranice), pretraživač ne zna koji algoritam koristimo i prisiljen je jednostavno prihvatiti naš Etag na vjeru.
Koristimo dvije metode heširanja:
1) u slučaju liste tekstova dobijenih iz više redova tabele, kreiramo Etag* prema formuli $ etag = md5 ($ lista);
2) u jednostavnijem slučaju (samo jedan zapis se preuzima iz tabele) činimo da mysql radi dodavanjem dodatne vrijednosti upitu: "select` id`, `title`,` text`, `author`,` datrec` , old_password (konkat (`naslov`,` tekst`, `autor`)) kao` etag` iz `članaka`...".
Prilikom slanja zaglavlja pomoću funkcije zaglavlja (), morate biti sigurni da se te radnje izvode prije bilo koju vrstu sadržaja koji se šalje pretraživaču (preko eha, print PHP-a ili jednostavnog HTML-a). To jest, prvo se cijeli dio koji treba provjeriti stavlja u varijablu, izračunava Etag*, šalju se sva zaglavlja i tek tada se sadržaj može prikazati. Osim ako, naravno, niste napisali ob_start ("ob_gzhandler") na početku stranice. Upravo smo to napisali, tako da šaljemo zaglavlja svejedno i kad god. Ovo ob_gzhandler takođe vam omogućava da dobijete sav sadržaj koji se šalje u pretraživač odjednom - pomoću funkcije ob_get_contents () kao i pravu dužinu sadržaja (za zaglavlje Dužina sadržaja) - funkcija ob_get_length ()... Mi, kao što je već rečeno, ne možemo koristiti na ovoj stranici sve sadržaj stranice za formiranje ovih zaglavlja. Ali na drugim stranicama - sasvim.
304 Nije izmijenjeno
Tako da klijentima šaljemo tačan datum promjene stranice i Etag... Klijenti imaju razumijevanja - šalju zaglavlja u sljedećim pozivima na ovu stranicu Ako-Modificirano-Od i Ako-Nema-Match, što se i sami možete uvjeriti na samom dnu bilo kog našeg članka (nakon što pritisnete tipku F5, naravno). Ali željeni rezultat nije postignut: server kao odgovor na sve zahtjeve pretraživača redovno šalje zaglavlje HTTP / 1.x 200 OK i ne 304 ... Naš "alat" ne prikazuje zaglavlja "200 OK", jer ih ne generišemo pomoću funkcije zaglavlja ().
Naslov 304 može se vidjeti u velikom broju kroz LiveHTTPHeaders - za slikovne datoteke, Javascript, css i jednostavne HTML stranice. Ovo zaglavlje šalje sam Apache, i to radi bez ikakvih naših podešavanja sa modulom headers.so i bez dodatnih instrukcija poput "ExpiresActive On". Ali ne za PHP generisane stranice.
Slanje zaglavlja u pretraživač smo sami upisali u PHP skriptu i sami moramo provjeriti prisustvo ili odsustvo validacije naknadnih zahtjeva pretraživača, a zatim sami uporediti kontrolne parametre i, ovisno o rezultatu, poslati zaglavlje 200 ili 304 u pretraživač. Tačnije, PHP 200 zaglavlje uvijek sam šalje, potrebno je samo izračunati situaciju potrebe 304. To radimo u glavnoj konfiguracijskoj datoteci svih web stranica configbase.php.
Poteškoća u dobijanju informacija o zaglavljima je što na jednom hostingu PHP radi kao cgi, a na drugom kao Apache modul, tako da prvo morate da proverite prisustvo varijabli u "superglobalnim" nizovima Env i Server, i ovisno o rezultatu, kreirajte referencu na odgovarajući niz:
$ h304 = "HTTP / 1.x 304 nije modifikovano"; $ match = ""; $ since = ""; $ varr = niz (); $ varrvis = niz (); if (array_key_exists ("HTTP_HOST", $ _ ENV)) $ varr = & $ _ENV; if (array_key_exists ("HTTP_HOST", $ _ SERVER)) $ varr = & $ _SERVER; if (isset ($ varr ["HTTP_IF_NONE_MATCH"])) $ match = $ varr ["HTTP_IF_NONE_MATCH"]; $ match = trim (strval ($ match)); if (isset ($ varr ["HTTP_IF_MODIFIED_SINCE"])) $ since = $ varr ["HTTP_IF_MODIFIED_SINCE"]; $ since = eksplodirati (";", $ since); $ since = strtotime (trim ($ since));
Pretposljednji red je potreban zbog IE-a, koji također šalje dužinu stranice u zaglavlju IF_MODIFIED_SINCE: "Pet, 3. jul 2009. 15:42:30 GMT; dužina = 20994" - iz ovog zaglavlja smo odrezali sve što možda nakon tačke zarez. Zatim kreiramo niz HTTP zaglavlja nezavisan od hosta:
Foreach ($ varr kao $ ke => $ va) (if (preg_match ("/ ^ HTTP \ _ / i", $ ke) &&! Preg_match ("/ COOKIE / i", $ ke)) $ varrvis ["$ ke "] = $ va;) $ varrvis [" Odgovor "] =" ============================= ";
Pa, i glavni fragment keširanja, jezgro cijelog našeg sistema, smješteno unutar PHP stranica (gdje je $dat vrijeme iz mysql tabele, pretvoreno u sekunde od strane funkcije strtotime):
Zaglavlje ("Etag: $ etag"); zaglavlje ("Kontrola predmemorije: privatno, maksimalna starost = 0"); zaglavlje ("Ističe:" .gmdate ("r"). "GMT"); zaglavlje ("Veza: Keep-Alive"); zaglavlje ("Keep-Alive: timeout = 5, max = 100"); if ($ since == $ dat) (if (! $ match || $ match == $ etag) ($ varrvis = $ h304; uključiti "bottom.php"; zaglavlje ($ h304); header ("Veza: Zatvori "); izlaz;)) else (zaglavlje (" Zadnja izmjena: ".gmdate (" r ", $ dat)." GMT ");)
Sistem radi ispravno u svim pretraživačima navedenim u ovom članku: kešira po potrebi i šalje nove informacije pretraživaču, ako ih ima. Na primjer, ako nakon otvaranja glavne stranice stranice (sa listom članaka) pritisnete F5 (ne u Operi! :-), na dnu stranice možete vidjeti dugo očekivani naslov 304 (U Operi to možete vidjeti i ako odete na ovu stranicu klikom na link na drugoj stranici stranice). Ako su napravljene promjene u naslovu članka ili je, na primjer, dodan novi članak, skripta će, po prijemu zahtjeva za validaciju od pretraživača, otkriti promjenu podataka i poslati pretraživaču novi sadržaj stranice , ne naslov 304 .
U ljudskom smislu, ono što radimo sa ovim naslovima može se sažeti na sljedeći način:
1) šaljemo pretraživaču (generalno svakom klijentu) dva identifikaciona znaka: vreme poslednje promene sadržaja stranice i heš stranice (kontrolni zbir); takođe šaljemo instrukciju da dozvolimo keširanje samo krajnjem klijentu (Cache-Control: privatno); u istom naslovu (max-age = 0), kažemo da klijent ne treba da zahteva novi sadržaj 0 sekundi (tj. treba ga uvek zahtevati); u sljedećem zaglavlju (Expires) kažemo klijentu istu stvar: stranica ističe odmah, odmah;
2) pretraživač poslušno stavlja stranicu u svoju keš memoriju, zajedno sa slikama i css datotekama; pri narednim pozivima na stranicu, pretraživač pita server da li se promijenio datum (IF_MODIFIED_SINCE) i, ponekad, kontrolni zbir (IF_NONE_MATCH) - na primjer, IE ne pita za kontrolni zbir;
3) ako je datum promenjen, proveravamo da li je iz pretraživača postojao zahtev za kontrolnu sumu, a ako jeste, proveravamo i njegovu promenu; ako se ništa nije promijenilo, pošaljite zaglavlje u pretraživač 304 ; ako se promijeni - ne šaljemo 304 (a sam PHP šalje 200 OK);
Da, i još jedan detalj za naš "alat": prvo zaglavlje (HTTP statusa) iz nekog razloga ne preuzima funkcija headers_list ()... Kada on 200 , ovo nije jako bitno, ali 304 Želio bih vidjeti (da se uvjerim da naš sistem za keširanje radi). Stoga, ovaj naslov morate ručno "obojiti" u niz naslova u redu
$ varrvis = $ h304;,a zatim za sve ostale primljene od strane funkcije headers_list () zaglavlja povećavaju indeks za jedan ($ ke + 1):
Foreach (headers_list () kao $ ke => $ va) ($ varrvis [$ ke + 1] = $ va;)
Poslednja nijansa. Kako vidjeti naslov 304 u pretraživaču ako je pretraživač primio ovo zaglavlje sa servera, a nije primio nikakav sadržaj stranice (stranica se ne bi trebala mijenjati na ekranu)? Neka ovo ostane naša mala tajna.
© 2009, "Business Week", Mihail Gutentog
501. SlipkeR
Hvala) sve je jasno i razumljivo napisano) autoru ATP-a)
Moderni pretraživači često koriste lokalnu keš memoriju u svom radu. Šta to znači? To znači da pretraživač, nakon što je od servera primio html dokument, sliku ili drugi resurs, smešta ga u svoju lokalnu keš memoriju (drugim rečima, upisuje primljeni resurs na hard disk računara korisnika) i na naknadne zahteve na takav resurs, ne okreće se serveru, već prima resurs iz lokalne keš memorije.
Ovaj algoritam pretraživača dramatično povećava brzinu učitavanja html dokumenata. Budući da je resurs već učitan i, kao rezultat toga, nalazi se u lokalnoj predmemoriji, tada vrijeme pristupa nije određeno propusnošću komunikacijskog kanala (na primjer, modemska veza), već brzinom hard disk.
Međutim, uz svoje prednosti, ova metoda stvara i niz problema. Konkretno, većina web-programera početnika, kada razvijaju dinamičke stranice, suočavaju se sa istim problemom. Suština ovog problema je da umjesto ponovnog pristupa serveru za stranicu koja pokreće skriptu na serveru koja mijenja neke informacije, pretraživač pristupa lokalnoj keš memoriji. I kao rezultat, na primjer, od tri poziva, ne postoje tri modifikacije informacija koje se nalaze na serveru, već samo jedna.
Kako bi natjerali pretraživač da svaki put zatraži stranicu na serveru, potrebno je spriječiti pretraživač da unese ovaj resurs u keš memoriju. Sljedeće su najčešće metode za onemogućavanje ili zaobilaženje keširanja.
Generiranje novog URL-a
Recimo da traženi resurs ima sljedeći URL: test.html? Id = 7. Kao što možete vidjeti iz url-a, jedan parametar mu se prosljeđuje. Dodajmo, na primjer, korištenjem JavaScript-a, na url još jedan parametar, pa ćemo njegovu vrijednost učiniti slučajnim brojem. Rezultirajući URL će izgledati ovako: test.html?Id = 7 & rnd = 0,6700820127538827. Nasumični parametar će se svaki put generirati iznova. Ispod je lista koja demonstrira ovaj pristup:
Svaki put će se rezultat takvog zahtjeva keširati, ali budući da se keširanje izvodi kroz cijeli url, svaki put će se primiti novi url i pretraživač će biti primoran da zatraži resurs od servera, jer url od dva zahtjevi se neće tačno podudarati.
Polja zaglavlja
Takođe možete upravljati keširanjem sa strane servera. Da biste to učinili, resurs koji se šalje pretraživaču popraćen je poljima zaglavlja. Detaljan opis polja zaglavlja može se naći u standardu RFC 2068, koji opisuje HTTP 1.1 protokol.
Ističe polje zaglavlja
Vrijednost ovog zaglavlja je datum nakon kojeg će sadržaj resursa isteći. Ako korisnik nakon ovog datuma pristupi resursu, pretraživač mora zatražiti resurs od servera, a ne iz lokalne keš memorije.
Ako polje> ističe< содержит дату, прошедшую, по отношению к текущей, то при следующем обращении к ресурсу браузер будет вынужден снова обратиться к серверу. Это произойдет вследствие того, что либо документ не будет занесен в кэш — как уже устаревший, либо при обращении к кэшу браузер определит, что документ уже устарел. Следующий листинг на PHP демонстрирует использование заголовка Expires:
Polje zaglavlja posljednje izmjene
Vrijednost ovog zaglavlja je datum posljednjeg ažuriranja resursa. Većina modernih pretraživača koristi sljedeći algoritam kada je resurs već u lokalnoj predmemoriji:
* zahtijeva od servera datum posljednjeg ažuriranja resursa
* uspoređuje primljeni datum i datum resursa u lokalnoj predmemoriji
* ako je resurs na serveru noviji od resursa u kešu, resurs se traži od servera
Ako resurs koji se nalazi na serveru sadrži trenutni datum u ovom polju, pretraživač će svaki put tražiti resurs sa servera, a ne iz lokalne keš memorije. Sljedeći popis pokazuje upotrebu polja zaglavlja Last-Modified:
zaglavlje ("Last-Modified:". gmdate ("D, d M Y H: i: s"). "GMT");
Cache-Control i polja zaglavlja Pragma
Konačno, tu su polja zaglavlja koja su direktno odgovorna za keširanje resursa. Polje
Drugo polje je definisano u standardu RFC 2068, koji opisuje HTTP 1.1 protokol. Ovo polje zaglavlja vam omogućava da onemogućite keširanje i svaki put zatražite resurs od servera. Sljedeći popis pokazuje upotrebu polja zaglavlja Cache-Control i Pragma za onemogućavanje keširanja:
zaglavlje ("Kontrola predmemorije: nema predmemorije, mora se ponovo potvrditi"); zaglavlje ("Pragma: bez predmemorije");
Dobro loše
U stara dobra vremena, kreiranje web stranica bilo je jednostavno kao i kucanje nekoliko Html-pages, slanje web stranica u pretraživač je bilo jednostavno slanje datoteke od strane web servera. Posjetioci stranice su mogli vidjeti ove male stranice samo za tekst (osim za korisnike sporih modema). Čim se stranica učita, pretraživač je kešira negdje na lokalnom računaru tako da, ako se stranica ponovo zatraži, može uzeti njenu lokalnu verziju iz keša slanjem samo kratkog zahtjeva kako bi se uvjerio da je stranica na server nije promijenjen. Zahtjevi su obrađeni brzo i što efikasnije i svi su bili zadovoljni (osim onih koji koriste 9600 baud modeme).
Pojava dinamičkih web stranica preokrenula je stvari na gore, efektivno razbijajući ovaj model posluživanja web stranica kroz dva problema:
- Kada server primi zahtjev za dinamičku web stranicu, obavlja se neka srednja obrada, na primjer, raščlanjivanje (parsiranje) skripte od strane motora PHP da se završi. Zahvaljujući tome, dobijamo kašnjenje pre nego što web server počne da šalje izlaz u pretraživač. Za jednostavno PHP-skripta nije neophodna, ali za složeniju aplikaciju, motor PHP može poduzeti mnogo radnji prije nego što stranica bude spremna za podnošenje. Ovi dodatni koraci uvode primjetno kašnjenje između zahtjeva korisnika i stvarnog prikazivanja stranica u njihovim pretraživačima.
- Tipičan web server, kao što je Apache, koristi vrijeme modifikacije datoteke kako bi ispravno obavijestio web pretraživač o statusu keš memorije tražene stranice. Za dinamičke web stranice, zapravo PHP-skripta se može mijenjati samo povremeno, dok se sadržaj koji prikazuje, eventualno nalazi u bazi podataka, često mijenja. Web server nema načina da sazna da li se baza podataka promijenila, međutim, ne šalje datum posljednje izmjene. Ukoliko klijent (pretraživač) ne dobije nikakvu naznaku koliko dugo su podaci tačni, pretpostavlja da je sljedeći put potrebno zatražiti novu stranicu. Web server će uvijek odgovoriti ažuriranom verzijom stranice, bez obzira na to da li su se podaci promijenili. Kako bi izbjegli ovaj nedostatak, većina web programera koristi meta tagove ili HTTP-headers da kažu pretraživaču da nikada ne koristi keširanu verziju stranice. Međutim, ovo negira prirodnu sposobnost web pretraživača da kešira web stranice i ima neke značajne nedostatke. Na primjer, sadržaj dinamičke stranice može se mijenjati jednom dnevno, tako da su prednosti 24-satnog keširanja stranice očigledne.
Općenito je moguće da male PHP aplikacije ignorišu ove probleme, ali kako se kompleksnost i promet vaše stranice povećavaju, možete naići na probleme. Međutim, oba ova problema se mogu riješiti, prvi keširanjem na strani servera, a drugi kontroliranjem keširanja na strani klijenta iz vaše aplikacije. Pristup koji koristite za rješavanje problema ovisit će o vašoj aplikaciji, ali u ovom poglavlju ćemo vidjeti kako možete riješiti oba problema koristeći PHP i neke bibliotečke klase. KRUŠKA.
Kako da spriječim pretraživače da keširaju stranicu?
Prije nego što pogledamo metode keširanja klijenta i servera, prvo moramo razumjeti kako spriječiti web pretraživač (i proksije) da uopće keširaju stranice. Glavni način da se to postigne je korištenje HTML meta tagova:
Umetanjem prošlog datuma u metaoznaku Expires, govorite pretraživaču da je keširana kopija stranice uvijek zastarjela. To znači da pretraživač nikada ne bi trebao keširati stranicu. Meta tag Pragma: bez keša prilično dobro održavana konvencija koju slijedi većina web pretraživača. Jednom kada pronađu ovu oznaku, obično ne keširaju stranicu (iako nema garancija, ovo je samo konvencija).
Ovo zvuči dobro, ali postoje dva problema s upotrebom meta tagova:
- Ako oznaka nije postojala kada je stranicu prvi put zatražio pretraživač, ali se pojavi kasnije (na primjer, izmijenili ste datoteku uključivanja pageheader.php koji je zaglavlje svake web stranice), pretraživač će biti blaženo neznalica i koristiti svoje keširane kopije originala.
- Proksiji koji keširaju web stranice, kao što su dijeljene ISP uopće neće direktno ispitivati sadržaj Html-dokument. Umjesto toga, oslanjaju se samo na web server s kojeg su dokumenti došli i protokol HTTP... Drugim riječima, web pretraživač može misliti da ne bi trebao keširati stranicu, ali proxy između pretraživača i vašeg web servera to vjerovatno ne zna — i nastavit će slati istu zastarjelu stranicu klijentu.
Najbolji pristup je direktno korištenje protokola HTTP koristeći PHP funkciju zaglavlje (), što je ekvivalentno gornje dvije meta oznake:
Možemo otići korak dalje koristeći naslov Cache-Control kompatibilan sa pretraživačima koji podržavaju HTTP 1.1:
Zaglavlje ("Ističe: pon, 26. jul 1997. 05:00:00 GMT"); zaglavlje ("Kontrola predmemorije: nema skladištenja, nema predmemorije, mora se ponovo potvrditi"); zaglavlje ("Keš-Kontrola: naknadna provjera = 0, pretprovjera = 0", FALSE); zaglavlje ("Pragma: bez predmemorije");
Ovo osigurava da nijedan web pretraživač ili posredni proxy server ne keširaju stranicu, tako da posjetitelji uvijek dobiju najnoviju verziju sadržaja. U stvari, prvo zaglavlje treba da bude samostalno, ovo je najbolji način da osigurate da stranica nije keširana. Naslovi Cache-Control i Pragma dodano u svrhu "igranja na sigurno". Iako ne rade u svim pretraživačima ili proksijima, uhvatit će neke slučajeve gdje Ističe ne radi kako se očekuje (na primjer, ako datum na klijentskom računaru nije ispravno postavljen).
Naravno, potpuno eliminisanje keširanja donosi nam probleme o kojima smo govorili na početku ovog poglavlja. Sada ćemo pogledati rješenje za ove probleme.
Internet Explorer i keširanje preuzimanja datoteka
Ako tokom usluge upload-ovanja datoteka PHP-script koristi zaglavlja kao što su Dispozicija sadržaja: prilog, naziv datoteke = myFile.pdf ili Dispozicija sadržaja: inline, naziv datoteke = myFile.pdf imaćete problema sa Internet Explorer'Ohm ako kažete pretraživaču da ne kešira stranicu.
Internet Explorer upravlja učitavanjem na prilično neobičan način, postavljajući dva zahtjeva web stranici. Prvi zahtjev preuzima datoteku i pohranjuje je u keš memoriju dok se drugi zahtjev ne kreira (bez pohranjivanja odgovora). Ovaj zahtjev pokreće proces prijenosa datoteke do krajnjeg korisnika prema tipu datoteke (na primjer, pokreće Acrobat Reader ako je fajl PDF-dokument). To znači da ako ste poslali zaglavlja koja sprečavaju pretraživač da kešira stranicu, Internet Explorerće izbrisati datoteku između prvog i drugog zahtjeva, što rezultira da krajnji korisnik neće dobiti ništa. Ako je fajl koji učitavate PHP-script, se ne mijenja, jedno od najjednostavnijih rješenja će biti uklanjanje zaglavlja "zabrani keširanje" iz skripte.
Ako se datoteka koju preuzimate redovno mijenja (tj. želite da pretraživač preuzme najnoviju verziju), trebate koristiti zaglavlje Zadnja izmjena, što će biti pokriveno kasnije u ovom poglavlju, i osigurati da se vrijeme modifikacije između dva uzastopna zahtjeva ne promijeni. Ovo morate učiniti na način koji ne utiče na korisnike pretraživača koji se ispravno učitavaju. Jedno rješenje u ovom slučaju je pohraniti datoteku na vaš web server i pružiti jednostavnu vezu do nje, dopuštajući web serveru da za vas prijavi zaglavlja keša. Naravno, ovo rješenje možda neće biti prihvatljivo ako se pretpostavlja ovlašteni pristup datoteci, ovo rješenje omogućava direktno učitavanje sačuvane datoteke.
Kako mogu uzeti podatke sa strane servera za keširanje?
Vrijeme je da pogledamo kako možemo smanjiti kašnjenje korištenjem keširanja izlaza na strani servera. Opći pristup je da počnete prikazivati stranicu kao i obično, obavljajući upite baze podataka i tako dalje PHP... Međutim, prije slanja rezultata pregledniku, zgrabimo ga i spremimo gotovu stranicu, na primjer, u datoteku. Na sljedeći zahtjev, PHP-script prvo provjerava keširanu verziju stranice. Ako postoji, skripta šalje keš verziju pretraživaču, čime se eliminiše kašnjenje u ponovnom kreiranju stranice.
Nekoliko riječi o keširanju sa šablonima
Kako mogu upravljati keširanjem na strani klijenta pomoću PHP-a?
Vrijeme je da pogledamo mehanizam koji će nam omogućiti da kontrolišemo keš na strani klijenta pomoću sredstava PHP... Ovaj pristup će raditi samo ako koristite PHP u vezi sa serverom Apache jer ćemo koristiti funkciju getallheaders () da bismo zaglavlja proslijedili pretraživaču. Ova funkcija radi samo u Apache.
Nova imena funkcija
Ako koristite PHP 4.3.0 s Apache HTTP zaglavlja su dostupna sa apache_request_headers () i apache_response_headers (). Funkcija getallheaders () postala je pseudonim za novu funkciju apache_request_headers ().
Mehanizam za rad sa kešom web pretraživača je ponovo HTTP... Mnoga zaglavlja uključena su u upućivanje web preglednika i proxyja da samostalno keširaju stranicu, što je komplikovano činjenicom da su neka od njih dostupna samo sa HTTP 1.1.
Provjera HTTP zaglavlja u vašem pretraživaču
Jednostavan, ali vrlo zgodan alat za provjeru zaglavlja zahtjeva i odgovora je LiveHttpHeaders- dodatak za pretraživač Mozilla... Znajte tačno koja zaglavlja vaša skripta šalje, posebno kada imate posla sa zaglavljima keša. HTTP.
Radi jednostavnosti, razmotrićemo samo HTTP 1.0 zaglavlja predmemorije, tj. Ističe, Zadnja izmjena i Ako-Modificirano-Od kao i statusni kod HTTP 304 (nije izmijenjeno).
Ostali naslovi dostupni sa HTTP 1.1, na primjer Cache-Control i ETag imaju za cilj da obezbede napredni mehanizam koji se može koristiti u vezi sa stanjem web sesije, drugim rečima, verzija date stranice prikazana neovlašćenom posetiocu može se značajno razlikovati od one koja se prikazuje ovlašćenom korisniku. Naslovi HTTP 1.1 su prvobitno dodani kako bi se omogućilo keširanje takvih stranica.
Istek stranice
Naslov koji se najlakše koristi je naslov Istek koji postavlja datum (možda budući) kada će stranica isteći. Do tada, web pretraživaču je dozvoljeno da koristi keširanu verziju stranice.
Primjer 7. 6.php
"; echo" Sada ". gmdate (" H: i: s ")." GMT"; echo" Pogledaj ponovo
"; ?>
Funkcija setExpiresšalje zaglavlje HTTP Ističe sa budućim vremenom navedenim u sekundama. Gornji primjer prikazuje trenutno GMT vrijeme i daje vezu koja vam omogućava da ponovo odete na stranicu. Koristeći dugme za osvežavanje vašeg pretraživača, možete reći pretraživaču da želite da osveži keš memoriju. Koristeći link, vidjet ćete da se vrijeme mijenja samo jednom svakih 10 sekundi.
Datumi i vremena u HTTP-u
Datumi u HTTP-u se uvijek izračunavaju u odnosu na srednje vrijeme po Griniču (GMT). PHP-ova funkcija gmdate () je potpuno ista funkcija kao i date (), osim što automatski kompenzuje GMT na osnovu sistemskog sata i podešavanja regiona vašeg servera.
Kada pretraživač naiđe na zaglavlje Ističe, kešira stranicu. Svi naredni zahtjevi za stranicu napravljeni prije određenog vremena isteka koriste verziju keš memorije stranice, ne pojavljuju se zahtjevi prema web serveru.
Naslov Ističe uglavnom lako implementirati, ali u većini slučajeva, osim ako niste visoko organizirana osoba, ne možete točno znati kada je određena stranica vaše stranice ažurirana. Pošto će pretraživač kontaktirati server tek nakon što stranica istekne, ne postoji način da kažete pretraživaču da je stranica u njegovoj keš memoriji zastarjela. Također gubite dio prometa na vašoj web stranici jer pretraživač ne kontaktira server kada traži stranicu iz keša.
Vrijeme promjene stranice
Praktičnije je koristiti zaglavlja Zadnja izmjena i Ako-Modificirano-Od dostupno u HTTP 1.0. Tehnički, to je poznato kao uslovni GET zahtjev, vraćate bilo koji sadržaj na osnovu stanja zaglavlja primljenog zahtjeva Ako-Modificirano-Od.
Kada koristite ovu metodu, morate poslati zaglavlje Zadnja izmjena svaki put kada se pristupi vašoj PHP skripti. Sljedeći put kada pretraživač zatraži stranicu, poslat će zaglavlje Ako-Modificirano-Od koji sadrži vrijeme do kojeg vaša skripta može odrediti da li je stranica osvježena od posljednjeg zahtjeva. Ako nije, vaša skripta šalje statusni kod HTTP 304 da označi da se stranica nije promijenila bez prikaza sadržaja stranice.
Postavljamo vrijeme modifikacije keš datoteke sa ovom linijom: $ lastModified = filemtime ($ cache_file);
Zatim, koristeći vrijeme modifikacije keš datoteke, šaljemo zaglavlje Zadnja izmjena... Moramo ga poslati za svaku stranicu koju pružimo kako bismo natjerali pretraživač da nam pošalje zaglavlje. Ako-Modificirano-Od sa svakim zahtevom.
// Uzmite HTTP zaglavlje Last-Modified ("Last-Modified:". Gmdate ("D, d M Y H: i: s", $ lastModified). "GMT");\ n \ n "; eho"
\ n "; eho" \ n "; eho" \ n ";?>Ako kombinirate pristup posljednjem modificiranom vremenu sa vremenom koje je već dostupno u vašoj aplikaciji (na primjer, vrijeme najnovijeg članka vijesti ili vrijeme čekanja u keširanju na strani servera koje smo vidjeli u posljednjem rješenju), možete uzeti prednost predmemorije web pretraživača i rasteretite kanal za prijenos podataka, štedeći promet informacija sa vaše stranice i poboljšavajući njegove performanse ako je moguće.
Budite oprezni kada testirate bilo kakvo keširanje urađeno u ovom stilu, ako to učinite pogrešno, možete natjerati svoje posjetitelje da uvijek imaju zastarjele kopije vaše stranice.
Keširanje vaših stranica u 5 koraka
Original: Objavljeno u PHP / JavaScript od strane ibzi 17. februara 2007Prevod: Kuzma Feskov ( [email protected], http: //kuzma.russofile.ru)
Keširanje vaših stranica može biti lijep i koristan mehanizam, posebno ako su generirane pomoću PHP-a i rade puno SQL upita. Čim primenite keširanje, vaš server će odmah smanjiti opterećenje i prestati da troši mnogo memorije za generisanje stranica - jednostavno će ih učitati iz keša. Pokazat ću vam kako PHP može keširati stranice i, u budućnosti, možete potrošiti oko 5 minuta na to.
Pogledajmo tehnologiju keširanja u koracima:
- Kreirajte datoteke u početnom direktoriju .htaccess, start_cache.php, end_cache.php kao i folder sa imenom cache_files.
- Folder cache_files potrebno je upisati atribute 777 .
- Unutra .htaccess file napišite sljedeće redove: php_value auto_prepend_file /home/username/public_html/start_cache.php php_value auto_append_file /home/username/public_html/end_cache.php Linija / home / korisničko ime / public_html / mora biti zamijenjen putanjom do vašeg matičnog direktorija.
- U scenario start_cache.php stavi sljedeći kod:Ne zaboravite popraviti stazu / home / korisničko ime / public_html / do putanje do vašeg matičnog direktorija.
- Postavite sljedeći kod u skriptu end_cache.php:
Sve vaše stranice će biti keširane 3600 sekundi = 1 sat. Ovaj parametar možete lako promijeniti u skripti. start_cache.php... Predmemorija stranice će biti sačuvana u folderu cache_files.
Sasvim je očigledno da su u ovom slučaju atributi 777 predstavljaju definitivno kršenje sigurnosti. S tim u vezi, preporučujem da izvadite folder cahce_files izvan granica public_html, na primjer, postavite jedan nivo više. Ovo će zatvoriti pristup datotekama koje se nalaze u njemu za korisnike vaše stranice, ali ni na koji način neće uticati na performanse sistema.
Također, ova metoda ima još jedan ozbiljan nedostatak: autor članka stavlja cijelu keš memoriju u jednu mapu, što će, uz dovoljan broj stranica na vašoj web stranici, uzrokovati problem, na primjer, na Unix sistemima postoji dovoljan usporavanje performansi kada postoji više od 1000 fajlova u folderu... S tim u vezi, potrebno je izvršiti brojne promjene u algoritmu i datoteke moraju biti stavljene u posebne podfoldere unutar foldera. cache_files... Na primjer, za ovo koristite prva 3-4 znaka md5 keša.
Za dinamičke resurse sasvim je moguće odabrati vrijeme keširanja od nekoliko (5-10) sekundi ili 1-2 minute, što će značajno smanjiti opterećenje servera, ali neće štetiti interaktivnosti stranice.
Za stranice za koje je interaktivnost posebno važna, možete uvesti izuzetke .htaccess, što će im omogućiti da se stalno mijenjaju, a za ostale stranice možete primijeniti keširanje.
Regeneracija sadržaja u hodu
Dinamički generirane, ali statički servirane stranice, tj. stranice koje bi trebale biti servirane kao čisto statične (čitane iz sistema datoteka i zatim poslane na zahtjev), ali moraju biti dinamički generirane od strane web servera ako nisu prisutne u sistemu datoteka. Na ovaj način možete imati PHP generirane stranice koje se statički poslužuju osim ako neko (ili planer) ne ukloni statički sadržaj. U tom slučaju sadržaj se ažurira.
To se radi sa sljedećim skupom direktiva:
RewriteCond% (REQUEST_FILENAME)! -S RewriteRule ^ stranica \ .html $ page.php
Ovdje zahtjev za page.html uzrokuje interno pokretanje odgovarajuće stranice.php ako stranica.html još uvijek nedostaje ili ima nultu veličinu. Trik je u tome što je page.php obična PHP skripta koja, pored sopstvenog izlaza, upisuje svoj izlaz u datoteku page.html. Jednom pokretanjem, server prenosi podatke page.html. Kada webmaster želi ažurirati sadržaj, on jednostavno briše stranicu.html (obično sa cronjob).
Problem sa keširanjem stranice Internet Explorera.
IE ima gadnu grešku u keširanju stranice kada radi sa zaglavljem "Vary". Problem je riješen dodavanjem sljedećih redova u .htaccess:
Glavni problem keširanja je brzina odgovora na zahtjeve prema glavnim sistemima skladištenja i obrada dolaznih i odlaznih strukturiranih informacija.
Zamislite da trebate izvršiti brz prijenos informacija, ali je brzina pristupa podacima izuzetno mala. Ili druga situacija: brzina je dobra, ali ima malo dostupne memorije ili je širina kanala nedovoljna, ili faktori procesora i diska ometaju zadatak. U ovom slučaju, keširanje je jedini izlaz iz situacije.
Vrste keširanja
Keširanje (ili keširanje) To je vrsta srednjeg bafera u kojem se pohranjuju podaci. Zahvaljujući keširanju, stranica stranice se ne kreira ponovo za svakog korisnika. Keširanje vam omogućava da radite sa velikom količinom podataka u najkraćem mogućem vremenu i sa ograničenim resursima (server i korisnik).Potrebno je shvatiti da se rad sa podacima može obavljati i na strani klijenta i na serveru. Štaviše, obrada podataka na strani servera je centralizovana i ima niz nesumnjivih prednosti (posebno za uslugu podrške).
Postoji nekoliko vrsta keširanja, predlažemo da razmotrimo svaki tip, njegove karakteristike i preporuke za upotrebu:
1. Keširanje pretraživača ili keširanje klijenta
To je kompajliranje naredbe za pretraživač da koristi postojeću keširanu kopiju. Rad takvog keširanja zasniva se na činjenici da se prilikom druge posjete zaglavlje 304 Not Modified vraća u pretraživač, a sama stranica ili slika se učitavaju iz lokalne korisničke keš memorije. Ispostavilo se da štedite na prometu između pretraživača posjetitelja i hostinga stranice. U skladu s tim, stranica vaše web stranice počinje se brže učitavati.1.1 Keširanje datoteka i slika
Keširanje pretraživača je najprikladnije za web lokacije koje sadrže veliki broj slika: slika se ne preuzima svaki put kada otvorite web lokaciju, već se jednostavno učitava kroz keš pretraživača.
Ovo je prvi nivo keširanja, koji se sastoji u serviranju zaglavlja "istekao" i naslov "304 Nije modificirano"... Keširanje u trajanju od 2 sedmice smatra se najefikasnijim.
Međutim, u ovom slučaju postoji važna nijansa: ako se slika na web-mjestu promijeni, pretraživač neće odmah znati za to, već samo ako čekate da istekne ili resetujete keš memoriju u samom pretraživaču. Nije baš efikasno ako se datoteka stalno mijenja i morate stalno služiti njenu trenutnu verziju.
1.2 Keširanje https
Posebna zaglavlja poput strict-security. Dozvoljava pretraživaču da se uvijek poziva na odabranu domenu putem https. Ovo stanje održava prilično krutim i, ako se ova vrsta keš memorije otkaže, pretraživač će i dalje pokušavati da učita stranicu putem https-a neko vrijeme, ignorirajući trenutna zaglavlja.1.3 Keširanje ovlaštenog certifikata
Takozvani pečat certifikacijskog tijela.Ova vrsta keširanja smatra se obaveznom ako ne želite da korisnici vaše stranice čekaju da certifikacijski organ (a to je određeni server koji je odgovoran za valjanost vašeg certifikata) obradi zahtjev iz pretraživača korisnika i potvrdi da vaš stranica je zaista potvrđena time.
1.4 Keširanje stranice
Kada je stranica već generirana, potrebno je stalno pratiti njenu relevantnost. Da biste to učinili, morate koristiti keš memoriju na strani servera sa praćenjem vremena promjene pojedinih dijelova stranice (ako je stranica izgrađena od mnogo dinamički generiranih blokova). Ovim pristupom, u svakom odgovoru sa servera, postavljaju se posebna zaglavlja koja označavaju vrijeme kada je stranica promijenjena, a zatim ih korisnikov pretraživač šalje kada se stranici stranice ponovo pristupi. Prilikom primanja takvih zaglavlja, server može analizirati trenutno stanje stranice (možda ga čak i renderirati), ali umjesto sadržaja stranice, daje zaglavlje "304 Nije modificirano", što za pretraživač korisnika znači da je moguće prikazati stranicu iz keš memorije (pretraživača korisnika).Naravno, moguće je poslati odgovarajuća zaglavlja bez upotrebe keša za praćenje na strani servera, ali u ovom slučaju većina korisnika će primiti ažuriranje sadržaja stranice prilično kasno. Sa ovim pristupom, pretraživač ponekad traži ažuriranja od servera, ali učestalost i pravila za svaki pretraživač konfiguriše njegov programer, tako da nema potrebe da se nadate da će vaši korisnici dobiti ažuriranja na vreme.
Tipično, predmemorija je kategorizirana prema tipu korisnika:
Ova podjela je zbog jedinstvenosti sadržaja za svakog ovlaštenog korisnika i općenitosti sadržaja za gostujuće korisnike. Na većini stranica, neovlašteni korisnik ne može promijeniti sadržaj stranice, a samim tim i utjecati na njen sadržaj.
Keširanje pretraživača vam omogućava da uštedite promet i vrijeme provedeno na učitavanju stranica. Ali da bi postigao učinak uštede, korisnik mora barem jednom posjetiti našu stranicu, što znači da će se opterećenje serverskih resursa smanjiti, ali ne značajno.
2. Keširanje servera
Serversko keširanje se odnosi na sve vrste keširanja u kojima se podaci pohranjuju na strani servera. Ovi podaci nisu dostupni klijentskim pretraživačima. Keš memorija se kreira i pohranjuje na bazi jedan-prema-više (mnogi su, u ovom slučaju, klijentski uređaji).
2.1 Keširanje cijele stranice
Najefikasniji keš. Zašto je zanimljivo? Njegova najveća prednost je što se stranica vraća gotovo u trenutku pristupa, kao rezultat toga, moguće je obraditi milione zahtjeva čak i na najslabijem serveru brzinom memorije i uz malo CPU-a.Možda je neko ikada sanjao o web lokaciji koja radi "ping" brzinom ili brže.
Ali ova vrsta keš memorije ima i svoje nedostatke: na primjer, nemogućnost keširanja stranica za ovlaštenog korisnika, ili za korisnika čiji sadržaj stranice ovisi o trenutnim korisničkim varijablama.
Koristite ovu keš memoriju ako server poznaje sva statička stanja eksternih podataka, kao što su: uri, get (bez dodatnih parametara), korisnik nije autorizovan – to je, zapravo, idealno stanje stranice za gostujuće korisnike. Imajte na umu da s takvim keširanjem arhitektura web-mjesta ili aplikacije uvijek mora obraditi dolazne zahtjeve na isti način i dati istu vrstu odgovora. Takvo stanje postoji u bilo kojoj aplikaciji ili lokaciji, samo ga treba pratiti i primijeniti na keš memoriju.
Keširanje čitavih stranica se najčešće koristi u nekoj vrsti hitnosti, dok se keš stranica čuva na unaprijed određeno vrijeme (od 2 minute), tokom kojeg su odgovori sa servera istog tipa (ne dozvolite pretraživaču da kešira ovo).
2.2 Keširanje rezultata kompajliranja php fajlova
Pravi se razlika između čiste kompilacije koda i njegove optimizacije tokom kompilacije (zamjena skripti). Najupečatljiviji primjeri:Obje vrste keširanja mogu se koristiti u projektu, ali svaka ima svoje nijanse koje se moraju uzeti u obzir prilikom pisanja koda.
2.3 Keširanje pojedinačnih blokova stranice
Ovo je možda najzanimljiviji, ali i najteži tip keširanja. Međutim, to takođe može biti efikasno i najlakši je način da se objasne principi keširanja uopšte.Potrebno je pratiti: stanje tabela, stanje sesije korisnika, da li da se isključi keširanje tokom POST ili GET zahtjeva (http upit), ovisnost o trenutnoj adresi, postojanost keširanja (ako se promijene prethodni uslovi) ili njegovo dinamičko prilagođavanje.
Keširanje pojedinačnih blokova stranica je bolje od drugih tipova keširanja ako trebate, na primjer, smanjiti broj zahtjeva prema bazi podataka od stvarnih (ovlaštenih) korisnika. Usput, s ispravnim ovisnostima, radit će čak i efikasnije od svih narednih vrsta keširanja.
Zašto je ova vrsta keširanja toliko važna? Stvar je u tome što je proširenje bazena servera baze podataka mnogo teže od proširenja bazena servera php dijela stranice. Štaviše, sukobe stanja php keširanja je mnogo lakše riješiti nego sukobe s više baza podataka.
2.4 Keširanje php-a na osnovu nedijeljenih resursa
Najprikladniji je za standardizaciju zahtjeva, preuzimanje podataka iz zajedničkih resursa, posjedovanje internih varijabli kojima php resursi pristupaju nekoliko puta tokom generiranja stranice.2.5 Keširanje php-a na osnovu zajedničkih resursa
Koristite ovo keširanje za pohranu serijaliziranih podataka. Na primjer: konfiguracijska datoteka, stanje tablica, liste sistema datoteka.2.6 Keširanje mysql-a na osnovu predmemorije upita
Ovo je prilično poznata i najčešće obrađena tema. Ipak, želio bih razmotriti specifičnosti rada s vremenskom oznakom i kako možete izbjeći stalno ispiranje keša upita.Sigurno se redovno susrećete u situaciji kada trebate dati nove materijale, čiji datum objavljivanja već dozvoljava trenutna vremenska oznaka? jednostavno rečeno,
WHERE show_ts<=UNIX_TIMESTAMP()
Ako u takvim upitima koristite vremensku oznaku koja se stalno mijenja, tada sql keš neće biti samo beskorisan, već čak i štetan, jer će se akumulirati broj keširanih upita čiji su podaci zastarjeli u vrijeme kada je keš stvoren.
Nudimo sledeći izlaz iz situacije:
Po pravilu, bilo koji materijal se objavljuje u određenim vremenskim periodima. Na primjer, 00:00. Sve što trebate učiniti je kreirati upit koji će procijeniti tabelu po maksimalnom datumu, a manjem od trenutnog.
Nešto kao:
SELECT SQL_NO_CACHE MAX (show_ts)... WHERE show_ts<=UNIX_TIMESTAMP();
Da, ovaj upit neće biti keširan, ali će se svi upiti ovoj tablici keširati ako je njihov broj više od jednog. Ova jednostavna operacija će uvelike poboljšati vijek trajanja sql keširanja.
Ima smisla keširati ove upite ako ima nešto više čitanja iz tabele nego zapisa.
2.7 Keširanje mysql izlaza, agregiranje tabela
Postoji pravilo: treba biti znatno manje ažuriranja podataka nego čitanja da bi se oni vratili.Odnosno, nema smisla agregirati šta će se promijeniti u istom trenutku, dok je relevantnost agregiranih podataka važna.
Šta odabrati za agregaciju? Obično je to neka vrsta statističkih podataka o broju zapisa, datumu posljednjeg ažuriranja, autoru posljednjeg ažuriranja i slično.
Zaključak
S obzirom na konstantno opterećenje mreže, ne možete kreirati nijedan projekat bez keširanja. Keširanje omogućava isporuku podataka velikom krugu klijenata koristeći minimalne resurse. U ovom članku smo ispitali mnoge vrste keširanja, među kojima smo sigurni da će se naći odgovarajuće rješenje za vaš projekt.Za optimizaciju rada sa mrežom koristi se mehanizam za spremanje dokumenata jednom primljenih putem HTTP-a u keš memoriju s ciljem njihovog ponovnog korištenja bez kontaktiranja izvornog servera. Dokument sačuvan u keš memoriji biće dostupan sledeći put kada mu se pristupi, bez istovara sa izvornog servera, koji je dizajniran da poveća brzinu pristupa klijenta njemu i smanji potrošnju mrežnog saobraćaja.
Same keš memorije su dvije vrste - lokalne i zajedničke. Lokalno je keš memorija pohranjena direktno na disku kod klijenta, kreirana i kojom upravlja njegov pretraživač. Shared je keš proxy servera organizacije ili provajdera i može se sastojati od jednog ili više proxy servera. Lokalni keš je prisutan, vjerovatno u svakom pretraživaču; značajan dio ljudi koji koriste Internet koristi zajednički keš. A ako se sada mali dio web stranica procjenjuje prema potrošnji prometa, onda je brzina preuzimanja važan kriterij koji treba uzeti u obzir pri razvoju vašeg web projekta.
Čini se da je keširanje štetno za dinamičke stranice stvorene kao rezultat PHP programa. Sadržaj stranice se generira na zahtjev korisnika na osnovu izvora podataka. Međutim, keširanje može biti korisno. Upravljajući njime, možete učiniti rad sa svojim serverom ugodnijim za korisnika tako što ćete dozvoliti učitavanje određenih stranica iz keša, čime ćete spriječiti njihovo ponovno učitavanje sa vašeg servera i uštedjeti korisničko vrijeme i promet.
Trebam li keširati ili ne?
Sposobnost keširanja stranice određena je dinamikom informacija u izvoru podataka. Dakle, potrebu za korištenjem keša određujete vi na osnovu planiranog vijeka trajanja stranice.
Ako govorimo o formiranju selekcije prema bazi podataka (na primjer, traženje riječi koju je unio korisnik), onda se takva stranica mora zahtijevati od servera pri svakom pozivu bez korištenja keš memorije, jer je broj opcija za tražene riječi su ogromne, a ako imamo posla i sa promjenom niza podataka, onda je keširanje besmisleno. Ili govorimo o formiranju, recimo, rasporeda dolaznih posetilaca (koji se menja sa svakom posetom, odnosno sa skoro svakim pozivom), tada je keširanje već jednostavno štetno.
Međutim, ako govorimo o istom rasporedu ali za jučer, onda se preporučuje keširanje, jer se podaci više neće mijenjati i možemo uštedjeti sebi i korisnicima resurse i vrijeme za učitavanje ovakvih stranica tako što ćemo ih smjestiti u lokalnu ili dijeljenu keš memoriju . Kao nastavak ove situacije, formiranje grafikona nije u realnom vremenu, već po satu. Ovdje možete unaprijed predvidjeti datum isteka "datum isteka" generiranih podataka.
Opći principi spremanja stranica u keš memoriju
PHP program može kontrolisati keširanje svojih rezultata rada formiranjem dodatnih polja u zaglavlju HTTP odgovora pozivanjem funkcije Header ().
Nekoliko opštih izjava koje nisu jedinstvene za PHP programe:
- POST stranice se nikada ne keširaju.
- Stranice koje zahtijeva GET i koje sadrže parametre („?“ je prisutan u URL-u) se ne pohranjuju u keš memoriju osim ako nije drugačije navedeno.
Stoga, u većini situacija, dodatne upute ne moraju biti dodane u program. Glavne tačke na koje biste trebali obratiti pažnju mogu se svesti na dvije:
- zabrani keširanje dokumenata koji su podrazumevano keširani
- keširanje dokumenata koji nisu keširani po defaultu.
Spriječite keširanje dokumenata keširanih po defaultu
Ovaj zadatak se javlja za PHP skripte koje se pozivaju bez parametara ili koje su indeksi direktorijuma, međutim, generišu podatke lično za korisnika (na primer, na osnovu kolačića ili korisničkog agenta) ili rade na osnovu podataka koji se brzo menjaju. Prema HTTP / 1.1 specifikaciji, možemo kontrolisati sljedeća polja:
Ističe
Određuje datum isteka dokumenta. Postavljanje u prošlost određuje zabranu keša za ovu stranicu.
Kontrola predmemorije: bez predmemorije
Upravljanje kešom. Vrijednost bez predmemorije specificira zabranu keša za ovu stranicu. Za verziju HTTP / 1.0 protokola na snazi je "Pragma: bez keša".
Zadnja izmjena
Datum posljednje izmjene sadržaja. Polje je relevantno samo za statične stranice. Apache zamjenjuje ovo polje vrijednošću polja Datum za dinamički generirane stranice, uključujući stranice koje sadrže SSI.
Stranica www.php.net pruža sljedeći kod za onemogućavanje keširanja.
zaglavlje ("Ističe: pon, 26. jul 1997. 05:00:00 GMT"); // Datum u prošlosti
zaglavlje ("Last-Modified:". gmdate ("D, d M Y H: i: s"). "GMT"); // uvijek modificirano
zaglavlje ("Kontrola predmemorije: nema predmemorije, mora se ponovo potvrditi"); // HTTP / 1.1
zaglavlje ("Pragma: bez predmemorije"); // HTTP / 1.0
Međutim, ovo zaglavlje je suvišno. U većini slučajeva dovoljno je:
Da biste označili dokument kao "već zastario", postavite Expires jednako polju Datum.
zaglavlje ("Ističe:". gmdate ("D, d M Y H: i: s"). "GMT");
Također, imajte na umu da obrasci koji se traže POST-om također ne podliježu keširanju.
Keširanje dokumenata koji nisu keširani po defaultu
Inverzni problem na prvi pogled može izgledati apsurdno. Međutim, postoji potreba i za ovim. Osim jednostavnog minimiziranja prometa, prilikom izrade web programa treba voditi računa o udobnosti korisnika koji s njim rade. Na primjer, neke stranice na vašem serveru se generiraju na osnovu velikih statičkih podataka. Mogućnost njihovog uključivanja u keš memoriju značajno će poboljšati brzinu servera za korisnika i djelomično osloboditi vašu od brojnih ponovljenih generacija takve stranice. Zaglavlje koje omogućava spremanje na proxy serverima:
Povezani članak: Promocija online trgovine na pretraživačima u Yandexu i Googleu: revizijska kontrolna lista faktora rangiranja
Ako stranica uzima u obzir informacije pohranjene u korisnikovom pretraživaču (tip i verzija pretraživača, ključevi, autorizacija, itd.), takva stranica se ne može pohraniti na proxy, ali se može spremiti u keš lokalnog pretraživača:
zaglavlje ("Kontrola predmemorije: privatno");
Keširanje do isteka valjanosti
Gore opisana rješenja su prilično jednostavna, iako su pogodna za većinu zadataka. Ali HTTP / 1.1 protokol ima mogućnosti za finiju kontrolu keša stranice, a postoje zadaci koji zahtijevaju korištenje ovih mehanizama. Kao primjer - web aplikacije koje rade s velikim podacima i predvidljivom dinamikom. Ispravnost podataka može se utvrditi kako po datumu predviđenog ažuriranja tako i po promjeni sadržaja. Za ove slučajeve koriste se različita zaglavlja kontrole predmemorije.
Prediktivno keširanje ažuriranja
Razmotrimo primjer - cjenik koji se ažurira ponedjeljkom. Unaprijed znate da se sadržaj stranice može pohraniti u keš memoriju do sljedeće sedmice, što treba navesti u zaglavlju odgovora kako bi se osiguralo željeno ponašanje stranice u kešu.
Glavni zadatak je dobiti datum idućeg ponedjeljka u RFC-1123 formatu
$ dt_tmp = getdate (datum ("U"));
zaglavlje ("Ističe:". gmdate ("D, d M Y H: i: s", datum ("U") - (86400 * ($ dt_tmp ["wday"] - 8))). "GMT");
zaglavlje ("Kontrola predmemorije: javno");
Ova metoda može efikasno kontrolirati ponašanje stranice u kešu i korisna je za veliki broj stranica - na ovaj ili onaj način možete dodijeliti vremenske intervale tokom kojih sadržaj stranice ostaje konstantan. Realnost je da stranice najdinamičnijih sajtova imaju određeni vijek trajanja, na osnovu kojeg programer može učiniti server ugodnijim za rad.
Drugi pristup koji se koristi za brže ažuriranje informacija i visok promet servera u isto vrijeme (inače keširanje neće biti efikasno) je korištenje zaglavlja Cache-control: max-age = seconds, koje određuje vrijeme nakon kojeg se dokument smatra zastarjelim i ima veći prioritet pri izračunavanju "svježine" dokumenta.
