Në artikullin e mëparshëm në lidhje me teknologjitë në internet, ne përmendëm një artikull të dobishëm Caching në HTTP (në tekstin e mëtejmë: "Artikulli nga nomagic.ru"). Në artikull, megjithatë, ne kishim disa pyetje dhe diskutimi atje u shua, kështu që ne duhej t'i kërkonim të gjitha përgjigjet vetë. Pyetjet, në fakt, nuk lidhen posaçërisht me artikullin - ato janë grumbulluar për disa vite. Të lodhur nga pazgjidhja e tyre, dhe artikulli thjesht dha një arsye për të kërkuar zgjidhje në mënyrë më aktive.
Mjetet
Pyetja e parë është se si të shikohen titujt HTTP të kërkesave të shfletuesit dhe përgjigjet e serverit? Autori i artikullit nga nomagic.ru rekomandon përdorimin e "veglave të zhvilluesit të uebit" në Firefox "për këtë qëllim dhe një lloj "DevToolbar" me baltë "për IE. Dora zgjati për të klikuar në lidhje, por u var në ajër:
1) Zhvilluesi i Uebit mjetet për FF ne tashmë i kemi, dhe nuk ka asnjë mjet për të parë titujt HTTP, madje edhe inspektori DOM në versionin 3 u hoq për disa arsye!
3) Dhe një mendim shumë i zymtë: në rregull, le të themi se kemi LiveHTTPHeaders për FF; me IE - papritmas po ju jeni me fat; mirë, po për Operan? Po në lidhje me Google Chrome?
Pse të mos shfaqni të gjitha titujt HTTP direkt në sajt duke përdorur mjetet PHP? Në fund të fundit, ekziston variablat e mjedisit, variabla për të punuar me serverin dhe të gjitha këto. Kjo do të thotë, ne e dimë saktësisht se çfarë ka, për shembull, $ _SERVER ["HTTP_HOST"] dhe HTTP_REFERER (ne e përdorim atë në çdo sajt). Të gjitha të tjerat duhet të shtohen HTTP_- këtu do të jenë titujt e kërkesës. Për më tepër, PHP ka një funksion të veçantë getallheaders () për këtë. Ose apache_request_headers (). Dhe apache_response_headers (). Po. Kjo do të shfaqë të gjitha titujt HTTP. Me sa duket. Por ne kishim një goditje të rëndë poshtë rripit dhe 15 minuta mundim, që rezultoi në zbulimin: në hostin tonë PHP është instaluar si cgi (dhe jo si një modul Apache) && në këtë konfigurim të gjitha këto funksione ... headers () nuk punojnë!
Duke ekzekutuar skenarin me echo phpinfo () dhe duke parë rezultatin, ne zbulojmë se titujt e kërkuar të kërkesës HTTP janë në grup $ _ENV(dhe askund tjetër). Mirë, _env është aq _env. Por ka shumë të gjitha llojet e mbeturinave (për momentin është e tepërt për ne), kështu që ne krijojmë një grup të ri $ varrvis dhe prerë me kujdes pjesët pak a shumë të nevojshme nga _env atje:
Foreach ($ _ ENV si $ ke => $ va) (nëse (preg_match ("/ ^ HTTP \ _ / i", $ ke) &&! Preg_match ("/ COOKIE / i", $ ke)) $ varrvis [" $ ke "] = $ va;)
Por për të marrë titujt e përgjigjeve të serverit tonë - mirë, më në fund, asgjë, përveç funksionit lista_titujsh ()... Dhe vetëm ato tituj që ne vetë do t'i dërgojmë në skriptin PHP duke përdorur funksionin kokë ()... Në teori, funksioni lista_titujsh () duhet të ekzekutohet pasi të jenë shkruar të gjitha titujt. Ne e bëmë këtë përafërsisht, megjithëse, ka shumë të ngjarë, për këtë faqe (faqja në të cilën janë bërë eksperimentet) nuk ka rëndësi, sepse kudo përdoret ob_start ("ob_gzhandler")... Shtoni ndërtimin e mëposhtëm në fund të skripteve që po testohen:
Foreach (lista_headers () si $ ke => $ va) ($ varrvis [$ ke] = $ va;)
Dhe ne plotësojmë grupin tonë të titujve me përgjigjet e serverit. Dhe midis Kërkesës dhe Përgjigjes, për lexueshmëri, futni rreshtin:
$ varrvis ["Përgjigje"] = "=============================";
Mbetet në fund të skripteve për t'u testuar për të shkruar print_r ($ varrvis)- dhe më pas shfletoni me gëzim faqet e faqes në të gjithë shfletuesit e disponueshëm, duke admiruar titujt HTTP.
Memoria e HTTP me udhëzime Apache
Artikulli nga nomagic.ru tregon dy burime të udhëzimeve të memorizimit: skedarët e konfigurimit të Apache (http.conf && .htacces) dhe një skript PHP drejtpërdrejt me komanda si titulli ("Pragma: pa cache"). Por ka ende një burim të tretë - ai mund të zbulohet nga përvoja e thjeshtë:
1) shkruani (zhkomentoni) në httpd.conf(Apache 1.3.39) rreshtat:
LoadModule expires_module modules / mod_expires.so LoadModule headers_module modules / mod_headers.so AddModule mod_expires.c AddModule mod_headers.c
2) në dosjen e faqes sonë në .htaccess shtoni udhëzime:
Header shto Cache-Control "public" ExpiresActive On ExpiresDefault "qasje plus 1 orë"
3) shkruani një skenar të thjeshtë pi.php nga dy rreshta:
4) hapni faqen pi.php në Firefox dhe shikoni atë në LiveHTTPHeaders ("Mjeti" ynë PHP mund të tregojë vetëm titujt e dërguar nga funksioni header (), nuk po e përdorim për momentin). rreshtat e mëposhtëm në lidhje me caching:
Cache-Control: pa dyqan, pa memorie, duhet të rivlerësohet, pas-kontroll = 0, kontroll paraprak = 0 Skadon: Pej, 19 nëntor 1981 08:52:00 GMT Pragma: pa memorie
Voila. Dhe ju nuk keni nevojë për ndonjë Wikipedia - këtu ata janë titujt që vrasin cachimin. Ato vijnë nga një burim i tretë - skedari php.ini. Në të, si parazgjedhje, kur instaloni PHP, shkruhet udhëzimi i mëposhtëm, në veçanti:
Session.cache_limiter = nocache
Është ajo që bën PHP të dërgojë tituj anti-cache në kushte të caktuara (për shembull, kur përdorni funksionin session_register ()). Sigurisht që kemi mashtruar pak duke ia përshtatur situatën këtyre kushteve. Por kush mund të garantojë që ai kurrë nuk do ta përdorë funksionin në skenarët e tij sesioni_regjistrohu ()? Po, në përgjithësi, dhe pa të, situata është shumë e keqe: hiqni rreshtin e parë nga skripti pi.php (duke lënë vetëm echo phpinfo ();) - gjithashtu asgjë e mirë:
Dhe kjo është e gjitha që japin udhëzimet për caching Apache në kombinim me "session.cache_limiter = nocache" në php.ini. Titulli më i rëndësishëm mungon - E modifikuara e fundit(data kur faqja është modifikuar për herë të fundit), pa të cilën është e pamundur të instaloni siç duhet ose të shkatërroni siç duhet memorien në shfletues.
Rezultati më qesharak merret nëse "tërheqni papagallin nga të dyja këmbët menjëherë" - shkruani "session.cache_limiter = private" në php.ini (duhet të rinisni Apache) dhe lini rreshtin session_register ("var1") në skript. :
Cache-Control: private, max-moshë = 300, kontroll paraprak = 300 Skadon: e enjte, 19 nëntor 1981 08:52:00 GMT-Ndryshuar së fundi: Hënë, 06 korrik 2009 15:13:40 GMT
Duket E modifikuara e fundit e cila tregon kohën e modifikimit të fundit të skriptit php, dhe Cache-Control kundërshton Skadon... Sjellja e shfletuesit do të jetë e paparashikueshme.
Korrigjo memorien e HTTP
Në titujt e fundit që kemi marrë gjatë përvojës sonë, mospërputhja në përgjithësi nuk është aspak fatale: shfletuesit nuk e kanë parë ende këtë, ata janë mjaft "imun ndaj zhurmës" ndaj gjërave të tilla. Problemi më i madh është vetëm E modifikuara e fundit, e cila është e nevojshme si nga përdoruesit (shfletuesit) ashtu edhe nga motorët e kërkimit. Është e qartë se data e modifikimit të skedarit PHP nuk mund të përdoret për të - sepse përmbajtja aktuale e faqes mund të mos ketë të bëjë fare me këtë datë: zakonisht përmbajtja e faqes merret nga baza e të dhënave, dhe data e modifikimit të tij gjithashtu duhet të merret prej andej (nga DB).
Nëse ky është një artikull specifik nga faqja jonë, thjesht marrim datën e postimit aktual nga fusha "datrec" e tabelës së "artikujve". Nëse kjo është një listë artikujsh (në faqen kryesore të faqes), ne po kërkojmë datën më të lartë të të gjitha hyrjeve duke përdorur formulën "zgjidh max (`datrec`) nga "artikujt" - do të jetë data e ndryshimi i faqes së fundit, të cilin do ta kalojmë në titull E modifikuara e fundit.
Ekzistojnë edhe dy "pika kontrolli" për përmbajtjen që zbatohen duke përdorur titujt HTTP:
1) Etag- hash i përmbajtjes së faqes, i marrë, për shembull, duke përdorur funksionin md5(teksti i faqes);
2) gjatësia e përmbajtjes- gjatësia totale e tekstit të dërguar në shfletues në përgjigje të kërkesës së tij.
Nuk mund të përdorim gjatësia e përmbajtjes, sepse ky parametër ndryshon vazhdimisht: në kolonën e djathtë të secilës faqe kemi një kujtesë se në fund të fundit kjo është faqja e gazetës reklamuese "Delovaya Nedelya" - një listë e produkteve nga numri i fundit i gazetës. Kjo listë është mjaft e madhe, kështu që faqja shfaq vetëm një pjesë të vogël të listës së zgjedhur rastësisht.
Si, ju pyesni, a përdorim ne Etag- Edhe ai, pastaj ndryshon vazhdimisht rastësisht? Është shumë e thjeshtë: ne nuk e përfshijmë pjesën e ndryshueshme të faqes në hash, por krijojmë një hash vetëm "nga materialet e bazës së të dhënave të artikujve". Pse nuk mund të bëni të njëjtën gjë me gjatësia e përmbajtjes? Sepse gjatësia e përmbajtjes shfletuesi mund të kontrollojë lehtësisht (IE bën pikërisht këtë - ai dërgon përsëri gjatësinë aktuale të përmbajtjes së marrë në server). Dhe hash-i mund të shkruhet në mënyrë të rastësishme (gjëja kryesore është se ai ndryshon kur ndryshon pjesa e gjurmuar e faqes), shfletuesi nuk e di se cilin algoritëm po përdorim dhe është i detyruar të pranojë thjesht tonën Etag mbi besimin.
Ne përdorim dy metoda të hashimit:
1) në rastin e një liste tekstesh të marra nga shumë rreshta të tabelës, ne krijojmë Etag* sipas formulës $ etag = md5 (lista $);
2) në një rast më të thjeshtë (vetëm një rekord merret nga tabela), ne e bëjmë mysql të funksionojë duke shtuar një vlerë shtesë në pyetjen: "select` id", "title"," text", "autor", "datrec". `, vjetër_fjalëkalim (koncat ('titull',' tekst', `autor`)) si` etag` nga "artikujt" ...".
Kur dërgoni tituj duke përdorur funksionin header (), duhet të siguroheni që këto veprime janë kryer përparaçdo lloj përmbajtjeje që dërgohet në shfletues (nëpërmjet echo, printim PHP ose thjesht HTML të thjeshtë). Kjo do të thotë, së pari, e gjithë pjesa që do të kontrollohet vendoset në një ndryshore, e llogaritur Etag*, të gjithë titujt dërgohen dhe vetëm atëherë mund të shfaqet përmbajtja. Përveç nëse, sigurisht, keni shkruar ob_start ("ob_gzhandler") në fillim të faqes. Ne thjesht e shkruam atë, kështu që ne i dërgojmë titujt sido që të jetë dhe kurdo. Kjo ob_gzhandler gjithashtu ju lejon të merrni të gjithë përmbajtjen e dërguar në shfletues menjëherë - nga funksioni ob_get_contents () si dhe gjatësinë e vërtetë të përmbajtjes (për kokën gjatësia e përmbajtjes) - funksion ob_get_length ()... Ne, siç u tha tashmë, nuk mund të përdorim në këtë faqe të gjitha përmbajtjen e faqes për të formuar këto tituj. Por në faqet e tjera - mjaft.
304 Nuk është modifikuar
Kështu që ne u dërgojmë klientëve datën e saktë të ndryshimit të faqes dhe Etag... Klientët po kuptojnë - ata dërgojnë tituj në thirrjet e ardhshme në këtë faqe Nëse-Modifikuar-Që dhe Nëse-Asnjë-Përputhje, të cilin mund ta shihni vetë në fund të secilit prej artikujve tanë (pasi të shtypni tastin F5, sigurisht). Por rezultati i dëshiruar nuk u arrit: serveri në përgjigje të të gjitha kërkesave të shfletuesit dërgon rregullisht kokën HTTP / 1.x 200 OK dhe jo 304 ... "Mjeti" ynë nuk shfaq titujt "200 OK", sepse ne nuk i gjenerojmë ato me funksionin header ().
Drejtimi 304 mund të shihet në numër të madh përmes LiveHTTPHeaders - për skedarët e imazheve, Javascript, css dhe faqet e thjeshta HTML. Ky titull dërgohet nga vetë Apache, dhe e bën atë pa asnjë ndryshim tonë me modulin headers.so dhe pa udhëzime shtesë si "ExpiresActive On". Por jo për faqet e krijuara nga PHP.
Ne vetë kemi shkruar dërgimin e titujve në shfletues në skriptin PHP, dhe ne vetë duhet të kontrollojmë praninë ose mungesën e vlefshmërisë së kërkesave të mëvonshme të shfletuesit, dhe më pas ne vetë krahasojmë parametrat e kontrollit dhe, në varësi të rezultatit, dërgojmë kokën 200 ose 304 në shfletues. Më saktë, kokën e PHP 200 e dërgon gjithmonë vetë, na duhet vetëm të llogarisim situatën e nevojës 304. Këtë e bëjmë në skedarin kryesor të konfigurimit të të gjitha sajteve configbase.php.
Vështirësia në marrjen e informacionit në lidhje me titujt është se në një host PHP funksionon si cgi, dhe në tjetrin si një modul Apache, kështu që së pari duhet të kontrolloni për praninë e variablave në grupet "superglobal". Env dhe Serveri, dhe në varësi të rezultatit, krijoni një referencë për grupin e duhur:
$ h304 = "HTTP / 1.x 304 Nuk është modifikuar"; $ ndeshje = ""; $ pasi = ""; $ varr = grup (); $ varrvis = grup (); nëse (kyçi_array_ekziston ("HTTP_HOST", $ _ ENV)) $ varr = & $ _ENV; nëse (kyç_array_ekziston ("HTTP_HOST", $ _ SERVER)) $ varr = & $ _SERVER; nëse (isset ($ varr ["HTTP_IF_NONE_MATCH"])) $ përputhje = $ varr ["HTTP_IF_NONE_MATCH"]; $ ndeshje = trim (strval ($ ndeshje)); if (isset ($ varr ["HTTP_IF_MODIFIED_SINCE"])) $ since = $ varr ["HTTP_IF_MODIFIED_SINCE"]; $ since = shpërthejnë (";", $ pasi); $ since = strtotime (trim ($ që nga));
Rreshti i parafundit është i nevojshëm për shkak të IE, i cili dërgon gjithashtu gjatësinë e faqes në kokën IF_MODIFIED_SINCE: "Premte, 03 korrik 2009 15:42:30 GMT; gjatësia = 20994" - ne kemi shkëputur gjithçka nga ky titull që ndoshta pas pikëpresjes. Pastaj ne krijojmë një grup të titujve HTTP të pavarur nga hosti:
Foreach ($ varr si $ ke => $ va) (if (preg_match ("/ ^ HTTP \ _ / i", $ ke) &&! Preg_match ("/ COOKIE / i", $ ke)) $ varrvis ["$ ke "] = $ va;) $ varrvis [" Përgjigje "] =" =================================================================================================================================================================================================================================================================== ";
Epo, dhe fragmenti kryesor i caching, thelbi i të gjithë sistemit tonë, i vendosur brenda faqeve PHP (ku $ dat është koha nga tabela mysql, e konvertuar në sekonda nga funksioni strtotime):
Header ("Etag: $ etag"); header ("Cache-Control: private, max-age = 0"); header ("Skadon:" .gmdate ("r"). "GMT"); header ("Lidhja: Keep-Alive"); header ("Keep-Alive: timeout = 5, max = 100"); if ($ since == $ dat) (nëse (! $ match || $ match == $ etag) ($ varrvis = $ h304; përfshi "bottom.php"; kokën ($ h304); kokën ("Lidhja: Mbylle "); dalje;)) else (titulli ("Ndryshimi i fundit: ".gmdate (" r ", $ dat)." GMT ");)
Sistemi funksionon në mënyrë korrekte në të gjithë shfletuesit e përmendur në këtë artikull: ai ruan në memorie kur nevojitet dhe dërgon informacion të ri në shfletues, nëse ka. Për shembull, nëse pasi hapni faqen kryesore të faqes (me një listë artikujsh) shtypni F5 (jo në Opera! :-), në fund të faqes mund të shihni titullin e shumëpritur 304 (Në Opera, mund ta shihni gjithashtu nëse shkoni në këtë faqe duke klikuar në lidhjen në një faqe tjetër të faqes). Nëse janë bërë ndryshime në titullin e një artikulli, ose, për shembull, është shtuar një artikull i ri, skripti, pasi të marrë një kërkesë vërtetimi nga shfletuesi, do të zbulojë ndryshimin në të dhëna dhe do t'i dërgojë shfletuesit përmbajtjen e faqes së re , jo titullin 304 .
Në terma njerëzorë, ajo që bëjmë me këta tituj mund të përmblidhet si më poshtë:
1) ne i dërgojmë shfletuesit (në përgjithësi për çdo klient) dy shenja identifikimi: kohën e ndryshimit të fundit të përmbajtjes së faqes dhe hash-in e faqes (checksum); ne dërgojmë gjithashtu një udhëzim për të lejuar cachimin vetëm tek klienti fundor (Cache-Control: private); në të njëjtin titull (max-mosha = 0), themi se klienti nuk duhet të kërkojë përmbajtje të re për 0 sekonda (d.m.th., duhet ta kërkojë gjithmonë atë); në kokën tjetër (Skadon) i themi klientit të njëjtën gjë: faqja skadon menjëherë, pikërisht tani;
2) shfletuesi e vendos me bindje faqen në cache-in e saj, së bashku me fotografitë dhe skedarët css; në thirrjet pasuese në faqe, shfletuesi pyet serverin nëse data (IF_MODIFIED_SINCE) ka ndryshuar dhe, ndonjëherë, shuma e kontrollit (IF_NONE_MATCH) - IE, për shembull, nuk pyet për shumën e kontrollit;
3) nëse data ka ndryshuar, ne kontrollojmë nëse ka pasur një kërkesë për një shumë kontrolli nga shfletuesi, dhe nëse po, kontrollojmë gjithashtu ndryshimin e saj; nëse asgjë nuk ka ndryshuar, dërgoni kokën në shfletues 304 ; nëse ndryshohet - ne nuk dërgojmë 304 (dhe vetë PHP dërgon 200 OK);
Po, dhe një detaj më shumë për "mjetin" tonë: titulli i parë (i statusit HTTP) për disa arsye nuk merret nga funksioni lista_titujsh ()... Kur ai 200 , kjo nuk është shumë e rëndësishme, por 304 Do të doja të shikoja (për t'u siguruar që sistemi ynë i memorizimit po funksionon). Prandaj, ju duhet ta "pikturoni" këtë titull në grupin e titujve me dorë në rresht
$ varrvis = $ h304;,dhe më pas për të gjitha të tjerat e marra nga funksioni lista_titujsh () kokat e rrisin indeksin me një ($ ke + 1):
Foreach (lista_headers () si $ ke => $ va) ($ varrvis [$ ke + 1] = $ va;)
Nuanca e fundit. Si të shihni titullin 304 në shfletues nëse shfletuesi e ka marrë këtë titull nga serveri dhe nuk ka marrë ndonjë përmbajtje faqeje (faqja nuk duhet të ndryshojë në ekran)? Le të mbetet ky sekreti ynë i vogël.
© 2009, "Java e Biznesit", Mikhail Gutentog
501. SlipkeR
Faleminderit) gjithçka është e qartë dhe e shkruar në mënyrë të kuptueshme) për autorin e ATP)
Shfletuesit modernë shpesh përdorin një cache lokale në punën e tyre. Çfarë do të thotë kjo? Kjo do të thotë që shfletuesi, pasi ka marrë një dokument html, foto ose burim tjetër nga serveri, e vendos atë në cache-in e tij lokal (me fjalë të tjera, ai e shkruan burimin e marrë në hard diskun e makinës së përdoruesit) dhe, sipas kërkesave të mëvonshme në një burim të tillë, ai nuk i drejtohet serverit, por merr burim nga cache lokale.
Ky algoritëm i shfletuesit rrit në mënyrë dramatike shpejtësinë e ngarkimit të dokumenteve html. Meqenëse burimi është ngarkuar tashmë, dhe si rezultat ndodhet në cache lokale, atëherë koha e hyrjes përcaktohet jo nga gjerësia e brezit të kanalit të komunikimit (për shembull, një lidhje modem), por nga shpejtësia e harduerit disk.
Megjithatë, krahas avantazheve të saj, kjo metodë ngre edhe një sërë problemesh. Në veçanti, shumica e programuesve fillestarë në internet, kur zhvillojnë faqe dinamike, përballen me të njëjtin problem. Thelbi i këtij problemi është se në vend që të ri-akses serverin për një faqe që ekzekuton një skript në server që modifikon disa informacione, shfletuesi hyn në cache lokale. Dhe si rezultat, për shembull, nga tre thirrje, nuk ka tre modifikime të informacionit të vendosur në server, por vetëm një.
Për të detyruar shfletuesin të kërkojë një faqe në server çdo herë, është e nevojshme të parandaloni që shfletuesi të futë këtë burim në cache. Më poshtë janë metodat më të zakonshme për të çaktivizuar ose anashkaluar ruajtjen memorike.
Gjenerimi i një URL të re
Le të themi se burimi i kërkuar ka url-në e mëposhtme: test.html? Id = 7. Siç mund ta shihni nga url, një parametër i kalohet asaj. Le të shtojmë, për shembull, duke përdorur JavaScript, në url një parametër më shumë dhe do ta bëjmë vlerën e tij një numër të rastësishëm. Url-ja që rezulton do të duket kështu: test.html?Id = 7 & rnd = 0.6700820127538827. Parametri i rastësishëm do të gjenerohet përsëri çdo herë. Më poshtë është një listë që demonstron këtë qasje:
Çdo herë që rezultati i një kërkese të tillë do të ruhet në memorien specifike, por duke qenë se memoria e fshehtë kryhet në të gjithë url-në, sa herë që do të merret një url e re dhe shfletuesi do të detyrohet të kërkojë një burim nga serveri, pasi url-ja e të dyve kërkesat nuk do të përputhen saktësisht.
Fushat e kokës
Ju gjithashtu mund të menaxhoni caching nga ana e serverit. Për ta bërë këtë, burimi i dërguar në shfletues shoqërohet nga fushat e kokës. Një përshkrim i detajuar i fushave të kokës mund të gjendet në standardin RFC 2068, i cili përshkruan protokollin HTTP 1.1.
Skadon fusha e kokës
Vlera e këtij titulli është data pas së cilës do të skadojë përmbajtja e burimit. Nëse një përdorues pas kësaj date i qaset burimit, shfletuesi duhet të kërkojë burimin nga serveri, jo nga cache lokale.
Nëse fusha> Skadon< содержит дату, прошедшую, по отношению к текущей, то при следующем обращении к ресурсу браузер будет вынужден снова обратиться к серверу. Это произойдет вследствие того, что либо документ не будет занесен в кэш — как уже устаревший, либо при обращении к кэшу браузер определит, что документ уже устарел. Следующий листинг на PHP демонстрирует использование заголовка Expires:
Fusha e kokës e modifikuar së fundi
Vlera e këtij titulli është data kur burimi është përditësuar për herë të fundit. Shumica e shfletuesve modern përdorin algoritmin e mëposhtëm kur burimi është tashmë në cache lokale:
* kërkon nga serveri datën e përditësimit të fundit të burimit
* krahason datën e marrë dhe datën e burimit në cache lokale
* nëse burimi në server është më i ri se burimi në cache, burimi kërkohet nga serveri
Nëse një burim i vendosur në server përmban datën aktuale në këtë fushë, atëherë shfletuesi do të kërkojë çdo herë burimin nga serveri dhe jo nga cache lokale. Lista e mëposhtme demonstron përdorimin e fushës së kokës së modifikuar së fundi:
header ("Modifikimi i fundit:". gmdate ("D, d M Y H: i: s"). "GMT");
Cache-Control dhe Pragma Header Fields
Së fundi, ka fushat e kokës që janë drejtpërdrejt përgjegjëse për ruajtjen e burimit në memorie. Fusha
Fusha e dytë është përcaktuar në standardin RFC 2068, i cili përshkruan protokollin HTTP 1.1. Kjo fushë e kokës ju lejon të çaktivizoni caching-un dhe çdo herë të kërkoni një burim nga serveri. Lista e mëposhtme demonstron përdorimin e fushave të titullit Cache-Control dhe Pragma për të çaktivizuar ruajtjen e memories:
header ("Cache-Control: pa-cache, duhet të rivlerësohet"); header ("Pragma: pa cache");
Mire keq
Në ditët e mira të vjetra, krijimi i faqeve të internetit ishte po aq i thjeshtë sa të shkruante disa HTML-pages, dërgimi i faqeve të internetit në shfletues ishte një dërgim i thjeshtë skedari nga serveri i uebit. Vizitorët e faqes mund t'i shihnin këto faqe të vogla, vetëm me tekst pothuajse menjëherë (përveç përdoruesve të modemëve të ngadaltë). Sapo faqja të jetë ngarkuar, shfletuesi e ruan atë diku në kompjuterin lokal në mënyrë që nëse faqja kërkohet përsëri, mund të marrë versionin e saj lokal nga cache duke dërguar vetëm një kërkesë të shkurtër për t'u siguruar që faqja në serveri nuk është ndryshuar. Kërkesat u përpunuan shpejt dhe me sa më efikasitet të ishte e mundur, dhe të gjithë ishin të kënaqur (përveç atyre që përdorin modemë 9600 baud).
Shfaqja e faqeve dinamike të internetit i ka kthyer gjërat për keq, duke thyer efektivisht këtë model të shërbimit të faqeve të internetit përmes dy problemeve:
- Kur serveri merr një kërkesë për një faqe interneti dinamike, bëhet një përpunim i ndërmjetëm, për shembull, analizimi (parzimi) i skriptit nga motori PHP për t'u përfunduar. Falë kësaj, ne kemi një vonesë përpara se serveri në internet të fillojë të dërgojë dalje në shfletues. Për të thjeshtë PHP-skripti nuk është thelbësor, por për një aplikim më kompleks, motori PHP mund të ndërmarrë shumë veprime përpara se faqja të jetë gati për paraqitje. Këta hapa shtesë sjellin një vonesë të dukshme midis kërkesave të përdoruesve dhe paraqitjes aktuale të faqeve në shfletuesit e tyre.
- Një server tipik ueb, si Apache, përdor kohën e modifikimit të skedarit për të informuar saktë shfletuesin e internetit për statusin e cache-it të faqes së kërkuar. Për faqet dinamike të internetit, në fakt PHP-skripti mund të ndryshohet vetëm herë pas here, ndërsa përmbajtja që shfaq, ndoshta e vendosur në bazën e të dhënave, ndryshon shpesh. Serveri i uebit nuk ka asnjë mënyrë për të ditur nëse baza e të dhënave ka ndryshuar, megjithatë, ai nuk dërgon datën e modifikimit të fundit. Nëse klienti (shfletuesi) nuk merr asnjë tregues se sa kohë janë të sakta të dhënat, ai supozon se herën tjetër është e nevojshme të kërkohet një faqe e re. Serveri i uebit gjithmonë do të përgjigjet me një version të përditësuar të faqes, pavarësisht nëse të dhënat kanë ndryshuar. Për të shmangur këtë disavantazh, shumica e zhvilluesve të uebit përdorin meta etiketat ose HTTP-headers për t'i thënë shfletuesit që të mos përdorë kurrë versionin e faqes në memorie të fshehtë. Megjithatë, kjo mohon aftësinë e natyrshme të shfletuesit të internetit për të memorizuar faqet e internetit dhe ka disa disavantazhe të rëndësishme. Për shembull, përmbajtja e një faqeje dinamike mund të ndryshojë një herë në ditë, kështu që përfitimet e ruajtjes së faqes në shfletuesin 24-orësh janë të dukshme.
Në përgjithësi është e mundur që aplikacionet e vogla PHP t'i shpërfillin këto probleme, por ndërsa kompleksiteti dhe trafiku i faqes suaj rritet, ju mund të hasni probleme. Megjithatë, të dyja këto probleme mund të zgjidhen, i pari nga cachimi nga serveri dhe i dyti duke kontrolluar cachimin nga ana e klientit nga aplikacioni juaj. Qasja që përdorni për të zgjidhur problemet do të varet nga aplikacioni juaj, por në këtë kapitull do të shohim se si mund t'i zgjidhni të dyja problemet duke përdorur PHP dhe disa klasa të bibliotekës. DARDHË.
Si mund të parandaloj që shfletuesit të ruajnë faqen në memorie?
Përpara se të shikojmë metodat e ruajtjes në memorien e klientit dhe serverit, së pari duhet të kuptojmë se si të parandalojmë fare që shfletuesi i internetit (dhe proxies) të ruajë faqet në memorie. Mënyra kryesore për ta arritur këtë është përdorimi i meta etiketave HTML:
Duke futur një datë të kaluar në meta-etiketën Expires, ju i tregoni shfletuesit se kopja e ruajtur në memorie e faqes është gjithmonë e vjetëruar. Kjo do të thotë që shfletuesi nuk duhet kurrë të ruajë memorien e faqes. Etiketa meta Pragma: pa memorie një konventë mjaft e mirëmbajtur që ndjekin shumica e shfletuesve të internetit. Pasi të gjejnë këtë etiketë, ata zakonisht nuk e ruajnë faqen në cache (megjithëse nuk ka garanci, kjo është vetëm një konventë).
Kjo tingëllon mirë, por ka dy probleme me përdorimin e meta etiketave:
- Nëse etiketa nuk ekzistonte kur faqja u kërkua nga shfletuesi për herë të parë, por shfaqet më vonë (për shembull, keni modifikuar skedarin e përfshirjes faqe faqe.php i cili është titulli i çdo faqe interneti), shfletuesi do të jetë jashtëzakonisht i paditur dhe do të përdorë kopjet e tij të ruajtura në memorie origjinale.
- Proxies që ruajnë memorien e faqeve të internetit, të tilla si të përbashkëta ISP nuk do të ekzaminojë drejtpërdrejt përmbajtjen fare HTML-dokument. Në vend të kësaj, ata mbështeten vetëm në serverin në internet nga i cili erdhën dokumentet dhe protokollin HTTP... Me fjalë të tjera, shfletuesi i uebit mund të mendojë se nuk duhet të ruajë memorien e faqes, por përfaqësuesi ndërmjet shfletuesit dhe serverit tuaj të internetit ndoshta nuk e di këtë - dhe do të vazhdojë t'i dërgojë klientit të njëjtën faqe të vjetëruar.
Qasja më e mirë është përdorimi i drejtpërdrejtë i protokollit HTTP duke përdorur funksionin PHP kokë (), ekuivalente me dy meta etiketat e mësipërme:
Mund të shkojmë një hap më tej duke përdorur titullin Cache-Control në përputhje me shfletuesit që mbështesin HTTP 1.1:
Header ("Skadon: Hënë, 26 korrik 1997 05:00:00 GMT"); header ("Cache-Control: pa-store, pa-cache, duhet të rivlerësohet"); header ("Cache-Control: post-check = 0, para-check = 0", FALSE); header ("Pragma: pa cache");
Kjo siguron që asnjë shfletues uebi ose server i ndërmjetëm proxy nuk po e ruan faqen, kështu që vizitorët marrin gjithmonë versionin më të fundit të përmbajtjes. Në fakt, titulli i parë duhet të jetë i pavarur, kjo është mënyra më e mirë për të siguruar që faqja të mos ruhet në memorie. Titujt Cache-Control dhe Pragma shtuar me qëllim të "luajtjes së sigurt". Ndërsa ata nuk funksionojnë në të gjithë shfletuesit ose proxies, ata do të kapin disa raste kur Skadon nuk funksionon siç pritej (për shembull, nëse data në kompjuterin e klientit nuk është vendosur saktë).
Sigurisht, eliminimi i plotë i caching-ut na siguron problemet që diskutuam në fillim të këtij kapitulli. Tani do të shikojmë një zgjidhje për këto probleme.
Internet Explorer dhe memoria e shkarkimit të skedarëve
Nëse gjatë shërbimit të ngarkimit të skedarëve PHP-skripti përdor kokë si p.sh Përmbajtja-Disposition: bashkëngjitja, emri i skedarit = myFile.pdf ose Përmbajtja-Disposition: inline, emri i skedarit = myFile.pdf do keni probleme me Internet Explorer Ohm nëse i thoni shfletuesit të mos e ruajë faqen në memorie.
Internet Explorer trajton ngarkimin në një mënyrë mjaft të pazakontë, duke bërë dy kërkesa në faqen e internetit. Kërkesa e parë shkarkon skedarin dhe e ruan atë në cache derisa të krijohet kërkesa e dytë (pa ruajtur përgjigjen). Kjo kërkesë thërret procesin e transferimit të skedarit te përdoruesi fundor sipas llojit të skedarit (për shembull, fillon Acrobat Reader nëse skedari është PDF-dokument). Kjo do të thotë që nëse keni dërguar tituj që pengojnë shfletuesin të ruajë faqen në memorie, Internet Explorer do të fshijë skedarin midis kërkesës së parë dhe të dytë, me rezultat që përdoruesi përfundimtar nuk do të marrë asgjë. Nëse skedari që po ngarkoni PHP-skripti, nuk ndryshon, një nga zgjidhjet më të thjeshta do të jetë heqja e titujve "të ndalojë caching" nga skripti.
Nëse skedari që shkarkoni ndryshon rregullisht (d.m.th. dëshironi që shfletuesi të shkarkojë versionin më të ri), duhet të përdorni kokën E modifikuara e fundit, i cili do të trajtohet më vonë në këtë kapitull dhe sigurohuni që koha e modifikimit ndërmjet dy kërkesave të njëpasnjëshme të mos ndryshojë. Ju duhet ta bëni këtë në një mënyrë që të mos ndikojë përdoruesit e shfletuesit që ngarkojnë saktë. Një zgjidhje në këtë rast është të ruani skedarin në serverin tuaj të internetit dhe të siguroni një lidhje të thjeshtë me të, duke lejuar që serveri i uebit të raportojë titujt e cache-it për ju. Sigurisht, kjo zgjidhje mund të mos jetë e pranueshme nëse supozohet qasja e autorizuar në skedar, kjo zgjidhje lejon ngarkimin e drejtpërdrejtë të skedarit të ruajtur.
Si mund të rrëmbej të dhënat e serverit për memorie?
Është koha të hedhim një vështrim se si mund të zvogëlojmë vonesën duke përdorur cachimin e daljes nga serveri. Qasja e përgjithshme është të filloni të jepni faqen si zakonisht duke bërë pyetje në bazën e të dhënave dhe kështu me radhë PHP... Sidoqoftë, përpara se të dërgojmë rezultatin në shfletues, ne e kapim atë dhe ruajmë faqen e përfunduar, për shembull, në një skedar. Në kërkesën e radhës, PHP-Script fillimisht kontrollon për një version të ruajtur në memorie të faqes. Nëse ekziston, skripti dërgon versionin e cache-it në shfletues, duke eliminuar kështu vonesën në rikrijimin e faqes.
Disa fjalë për ruajtjen e memories me shabllone
Si mund të menaxhoj cachimin e klientit me PHP?
Është koha për të parë një mekanizëm që do të na lejojë të kontrollojmë cache-në e klientit me mjete PHP... Kjo qasje do të funksionojë vetëm nëse e përdorni PHP në lidhje me serverin Apache pasi do të përdorim funksionin getallheaders () për të kaluar titujt nga shfletuesi. Ky funksion funksionon vetëm në Apache.
Emrat e funksioneve të reja
Nëse jeni duke përdorur PHP 4.3.0 s Apache Titujt HTTP disponohen me apache_request_headers () dhe apache_response_headers (). Funksioni getallheaders () është bërë një pseudonim për funksionin e ri apache_request_headers ().
Mekanizmi për të punuar me cache të shfletuesit të internetit është përsëri HTTP... Shumë tituj janë të përfshirë në udhëzimin e shfletuesve të internetit dhe proxy-ve për të ruajtur në memorien e faqes në mënyrë të pavarur, të ndërlikuar nga fakti se disa prej tyre janë të disponueshëm vetëm me HTTP 1.1.
Kontrollimi i titujve HTTP në shfletuesin tuaj
Një mjet i thjeshtë por shumë i dobishëm për të kontrolluar titujt e kërkesave dhe përgjigjeve është LiveHttpHeaders- shtesë në shfletues Mozilla... Dini saktësisht se çfarë titujsh po dërgon skripti juaj, veçanërisht kur keni të bëni me titujt e cache-it. HTTP.
Për hir të thjeshtësisë, ne do të shqyrtojmë vetëm kokat e memories HTTP 1.0, përkatësisht Skadon, E modifikuara e fundit dhe Nëse-Modifikuar-Që si dhe kodin e statusit HTTP 304 (i pa modifikuar).
Tituj të tjerë të disponueshëm me HTTP 1.1, për shembull Cache-Control dhe ETag kanë për qëllim të ofrojnë një mekanizëm të avancuar që mund të përdoret në lidhje me gjendjen e sesionit të internetit, me fjalë të tjera, versioni i një faqeje të caktuar që shfaqet tek një vizitor i paautorizuar mund të ndryshojë ndjeshëm nga ai i shfaqur tek një përdorues i autorizuar. Titujt HTTP 1.1 u shtuan fillimisht për të lejuar ruajtjen e faqeve të tilla.
Skadimi i faqes
Titulli më i lehtë për t'u përdorur është titulli Skadon e cila cakton një datë (ndoshta një të ardhme) kur faqja do të skadojë. Deri atëherë, shfletuesi i internetit lejohet të përdorë versionin e ruajtur në memorie të faqes.
Shembulli 7. 6.php
"; echo" Tani ". gmdate (" H: i: s ")." GMT"; jehonë" Shikoni përsëri
"; ?>
Funksioni setSkadon dërgon një kokë HTTP Skadon me një kohë të ardhshme të specifikuar në sekonda. Shembulli i mësipërm tregon kohën aktuale GMT dhe nxjerr një lidhje që ju lejon të shkoni përsëri në faqe. Duke përdorur butonin Rifresko të shfletuesit tuaj, mund t'i tregoni shfletuesit që dëshironi të rifreskoni cache-in. Duke përdorur lidhjen, do të shihni se koha ndryshon vetëm një herë në 10 sekonda.
Datat dhe orët në HTTP
Datat në HTTP llogariten gjithmonë në raport me kohën mesatare të Greenwich (GMT). Funksioni gmdate () i PHP është saktësisht i njëjti funksion si data (), përveç se kompenson automatikisht për GMT bazuar në orën e sistemit dhe cilësimet e rajonit të serverit tuaj.
Kur shfletuesi ndeshet me kokën Skadon, e ruan faqen. Të gjitha kërkesat e mëvonshme të faqeve të bëra përpara kohës së caktuar të skadimit përdorin versionin e cache të faqes, nuk ndodh asnjë kërkesë për serverin në internet.
Drejtimi Skadon kryesisht i lehtë për t'u zbatuar, por në shumicën e rasteve, nëse nuk jeni një person shumë i organizuar, nuk mund ta dini saktësisht se kur është përditësuar një faqe e caktuar e faqes suaj. Meqenëse shfletuesi do të kontaktojë serverin vetëm pasi faqja të ketë skaduar, nuk ka asnjë mënyrë për t'i treguar shfletuesit se faqja në cache-in e tij është e vjetëruar. Ju gjithashtu humbisni një pjesë të trafikut në faqen tuaj të internetit sepse shfletuesi nuk kontakton serverin kur kërkon një faqe nga cache.
Koha e ndryshimit të faqes
Është më praktike të përdoren titujt E modifikuara e fundit dhe Nëse-Modifikuar-Që në dispozicion në HTTP 1.0. Teknikisht, njihet si bërja e një kërkese të kushtëzuar GET, ju ktheni çdo përmbajtje bazuar në gjendjen e kokës së kërkesës së marrë Nëse-Modifikuar-Që.
Kur përdorni këtë metodë, duhet të dërgoni kokën E modifikuara e fundit sa herë që aksesohet skripti juaj PHP. Herën tjetër që shfletuesi të kërkojë faqen, ai do të dërgojë kokën Nëse-Modifikuar-Që që përmban kohën në të cilën skripti juaj mund të përcaktojë nëse faqja është rifreskuar që nga kërkesa e fundit. Nëse jo, skripti juaj dërgon një kod statusi HTTP 304 për të treguar se faqja nuk ka ndryshuar pa shfaqur përmbajtjen e faqes.
Kohën e modifikimit të skedarit cache e vendosim me këtë rresht: $ lastModified = filemtime ($ cache_file);
Pastaj, duke përdorur kohën e modifikimit të skedarit të cache, ne dërgojmë kokën E modifikuara e fundit... Ne duhet ta dërgojmë atë për çdo faqe që ofrojmë për të detyruar shfletuesin të na dërgojë një kokë. Nëse-Modifikuar-Që me çdo kërkesë.
// Merr titullin HTTP Last-Modified ("Last-Modified:". Gmdate ("D, d M Y H: i: s", $ lastModified). "GMT");\ n \ n "; jehonë"
\ n "; jehonë" \ n "; jehonë" \ n ";?>Nëse kombinoni qasjen e fundit të modifikuar të kohës me një kohë tashmë të disponueshme në aplikacionin tuaj (për shembull, kohën e artikullit më të fundit të lajmeve, ose kohën e skadimit nga ana e serverit që pamë në zgjidhjen e fundit), mund të merrni avantazhin e cache-it të shfletuesit të internetit dhe shkarkoni kanalin e transmetimit të të dhënave, duke kursyer trafikun e informacionit nga faqja juaj dhe duke përmirësuar performancën e tij nëse është e mundur.
Kini kujdes kur testoni çdo memorie të bërë në këtë stil, nëse e bëni gabim, mund t'i detyroni vizitorët tuaj të kenë gjithmonë kopje të vjetëruara të faqes tuaj.
Memoria e faqeve tuaja në 5 hapa
Origjinali: Postuar në PHP / JavaScript nga ibzi më 17 shkurt 2007Përkthim: Kuzma Feskov ( [email i mbrojtur], http://kuzma.russofile.ru)
Ruajtja në memorie e faqeve tuaja mund të jetë një mekanizëm i këndshëm dhe i dobishëm, veçanërisht nëse ato krijohen duke përdorur PHP dhe bëjnë shumë pyetje SQL. Sapo të aplikoni caching, serveri juaj do të zvogëlojë menjëherë ngarkesën dhe do të ndalojë së konsumuari shumë memorie për gjenerimin e faqeve - thjesht do t'i ngarkojë ato nga cache. Unë do t'ju tregoj se si PHP mund të ruajë faqet në cache dhe, në të ardhmen, ju mund të shpenzoni rreth 5 minuta në të.
Le të hedhim një vështrim në teknologjinë e memorizimit në hapa:
- Krijoni skedarë në drejtorinë kryesore .htaccess, start_cache.php, fund_cache.php dhe gjithashtu një dosje me emrin skedarët e cache.
- Dosja skedarët e cacheështë e nevojshme të vendosen atributet 777 .
- Brenda .htaccess skedari shkruani rreshtat e mëposhtëm: php_value auto_prepend_file /home/username/public_html/start_cache.php php_value auto_append_file /home/username/public_html/end_cache.php Rreshti / shtëpia / emri i përdoruesit / public_html / duhet të zëvendësohet me shtegun për në direktorinë tuaj kryesore.
- Në skenar start_cache.php vendosni kodin e mëposhtëm:Mos harroni të rregulloni rrugën / shtëpia / emri i përdoruesit / public_html / në shtegun për në direktorinë tuaj të shtëpisë.
- Vendosni kodin e mëposhtëm në skript fund_cache.php:
Të gjitha faqet tuaja do të ruhen për 3600 sekonda = 1 orë. Ju mund ta ndryshoni lehtësisht këtë parametër në skript. start_cache.php... Cache e faqes do të ruhet në dosje skedarët e cache.
Është mjaft e qartë se në këtë rast atributet 777 janë një shkelje e sigurt e sigurisë. Në lidhje me këtë, unë rekomandoj të hiqni dosjen cahce_files përtej kufijve public_html, për shembull, vendoseni një nivel më lart. Kjo do të mbyllë aksesin në skedarët e vendosur në të për përdoruesit e faqes tuaj, por nuk do të ndikojë në asnjë mënyrë në performancën e sistemit.
Gjithashtu, kjo metodë ka një pengesë tjetër serioze: autori i artikullit vendos të gjithë cache në një dosje, e cila, me një numër të mjaftueshëm faqesh në faqen tuaj, do të shkaktojë një problem, për shembull, në sistemet Unix, ka një mjaftueshëm ngadalësimi i performancës kur ka më shumë se 1000 skedarë në dosje ... Në lidhje me këtë, një numër ndryshimesh duhet të bëhen në algoritëm dhe skedarët duhet të vendosen në nënfolderë të veçantë brenda dosjes. skedarët e cache... Për shembull, duke përdorur 3-4 karakteret e para të cache md5 për këtë.
Për burimet dinamike, është mjaft e mundur të zgjidhni një kohë memorie prej disa (5-10) sekondash ose 1-2 minutash, gjë që do të zvogëlojë ndjeshëm ngarkesën në server, por nuk do të dëmtojë ndërveprimin e faqes.
Për faqet për të cilat interaktiviteti është veçanërisht i rëndësishëm, mund të futni përjashtime .htaccess, e cila do t'i lejojë ata të ndryshojnë vazhdimisht, dhe për pjesën tjetër të faqeve, mund të aplikoni caching.
Rigjenerimi i përmbajtjes në fluturim
Faqet e gjeneruara në mënyrë dinamike, por të shërbyera në mënyrë statike d.m.th. faqe që duhet të shërbehen si thjesht statike (të lexohen nga sistemi i skedarëve dhe më pas të dërgohen sipas kërkesës), por duhet të gjenerohen në mënyrë dinamike nga serveri i uebit nëse nuk janë të pranishëm në sistemin e skedarëve. Në këtë mënyrë ju mund të keni faqe të krijuara nga PHP që shërbehen në mënyrë statike, përveç nëse dikush (ose planifikuesi) heq përmbajtjen statike. Në këtë rast, përmbajtja përditësohet.
Kjo bëhet me grupin e mëposhtëm të direktivave:
RewriteCond% (REQUEST_FILENAME)! -S RewriteRule ^ faqe \ .html $ page.php
Këtu, një kërkesë për page.html bën që page.php përkatës të ekzekutohet nga brenda nëse page.html ende mungon ose ka madhësi zero. Truku këtu është se page.php është një skrip i rregullt PHP që, përveç prodhimit të tij, e shkruan daljen e tij në skedarin page.html. Duke e ekzekutuar këtë një herë, serveri transmeton të dhënat e faqes.html. Kur një webmaster dëshiron të përditësojë përmbajtjen, ai thjesht fshin faqen.html (zakonisht me një cronjob).
Problemi i memorizimit të faqeve të Internet Explorer.
IE ka një gabim të keq të cachimit të faqeve kur punon me kokën "Vary". Problemi zgjidhet duke shtuar rreshtat e mëposhtëm në .htaccess:
Problemi kryesor i memorizimit është shpejtësia e përgjigjes ndaj kërkesave ndaj sistemeve kryesore të ruajtjes dhe përpunimi i informacionit të strukturuar në hyrje dhe në dalje.
Imagjinoni që ju duhet të kryeni një transferim të shpejtë të informacionit, por shpejtësia e aksesit të të dhënave është jashtëzakonisht e ulët. Ose një situatë tjetër: shpejtësia është e mirë, por ka pak memorie të disponueshme ose gjerësia e kanalit është e pamjaftueshme, ose faktorët e procesorit dhe diskut ndërhyjnë në detyrë. Në këtë rast, caching është e vetmja rrugëdalje nga situata.
Llojet e caching
Memoria e memories (ose cache)Është një lloj buferi i ndërmjetëm në të cilin ruhen të dhënat. Falë memorizimit, faqja e faqes nuk rikrijohet për çdo përdorues. Caching ju lejon të punoni me një sasi të madhe të dhënash në kohën më të shkurtër të mundshme dhe me burime të kufizuara (server dhe përdorues).Është e nevojshme të kuptohet se puna me të dhëna mund të kryhet si në anën e klientit ashtu edhe në server. Për më tepër, përpunimi i të dhënave nga ana e serverit është i centralizuar dhe ka një sërë avantazhesh të padyshimta (veçanërisht për shërbimin mbështetës).
Ekzistojnë disa lloje të memorizimit, ne propozojmë të shqyrtojmë secilin lloj, veçoritë dhe rekomandimet e tij për përdorim:
1. Memoria e memories së shfletuesit ose memoria e klientit
Është duke përpiluar një komandë për shfletuesin që të përdorë një kopje ekzistuese të memorizuar. Puna e një memorie të tillë bazohet në faktin se në një vizitë të dytë, titulli 304 Not Modified kthehet në shfletues dhe vetë faqja ose fotografia ngarkohet nga cache e përdoruesit lokal. Rezulton se kurseni në trafik midis shfletuesit të vizitorit dhe pritjes së faqes. Prandaj, faqja juaj e internetit fillon të ngarkohet më shpejt.1.1 Ruajtja në memorie e skedarëve dhe imazheve
Ruajtja në memorie e shfletuesit është më e përshtatshme për faqet që përmbajnë një numër të madh imazhesh: fotografia nuk shkarkohet sa herë që hapni sitin, por thjesht ngarkohet përmes cache-it të shfletuesit.
Ky është niveli i parë i memorizimit, i cili konsiston në shërbimin e kokës "Skaduar" dhe titullin "304 i pa modifikuar"... Caching për 2 javë konsiderohet më efektive.
Sidoqoftë, në këtë rast ekziston një nuancë e rëndësishme: nëse imazhi në sit ndryshon, atëherë shfletuesi nuk do ta dijë menjëherë për të, por vetëm nëse prisni të skadojë ose rivendosni cache në vetë shfletuesin. Nuk është shumë efektive nëse skedari ndryshon vazhdimisht dhe ju duhet të shërbeni vazhdimisht versionin e tij aktual.
1.2 Ruajtja në memorie https
Titujt specialë si siguria e rreptë. Lejon shfletuesin t'i referohet gjithmonë domenit të zgjedhur nëpërmjet https. Ai e mban këtë gjendje mjaft të ngurtë dhe, nëse ky lloj cache anulohet, shfletuesi do të përpiqet ende të ngarkojë faqen përmes https për mjaft kohë, duke injoruar titujt aktualë.1.3 Ruajtja në memorie e autoritetit të certifikatës
E ashtuquajtura vula e autoritetit të certifikimit.Ky lloj memorie e fshehtë konsiderohet i detyrueshëm nëse nuk dëshironi që përdoruesit e faqes tuaj të presin që një autoritet certifikues (dhe ky është një server i caktuar që është përgjegjës për vlefshmërinë e certifikatës suaj) për të përpunuar një kërkesë nga shfletuesi i përdoruesit dhe për të konfirmuar që faqja vërtetohet nga ajo.
1.4 Memoria e faqeve
Kur faqja është krijuar tashmë, duhet të monitoroni vazhdimisht rëndësinë e saj. Për ta bërë këtë, duhet të përdorni një cache nga ana e serverit me gjurmimin e kohës së ndryshimit të pjesëve individuale të faqes (nëse faqja është ndërtuar nga shumë blloqe të gjeneruara në mënyrë dinamike). Me këtë qasje, në çdo përgjigje nga serveri, vendosen tituj të veçantë që tregojnë kohën e ndryshimit të faqes, të cilat më pas dërgohen nga shfletuesi i përdoruesit kur faqja e faqes ri-aksesohet. Kur merr tituj të tillë, serveri mund të analizojë gjendjen aktuale të faqes (ndoshta edhe ta bëjë atë), por në vend të përmbajtjes së faqes, jep kokën "304 i pa modifikuar", që për shfletuesin e përdoruesit do të thotë se është e mundur të shfaqet faqja nga cache e tij (shfletuesit të përdoruesit).Sigurisht, është e mundur të dërgohen titujt e duhur pa përdorur cache-në e gjurmimit nga ana e serverit, por në këtë rast, shumica e përdoruesve do ta marrin përditësimin e përmbajtjes së faqes mjaft vonë. Me këtë qasje, shfletuesi ndonjëherë anketon serverin për përditësime, por frekuenca dhe rregullat për secilin shfletues konfigurohen nga zhvilluesi i tij, kështu që nuk ka nevojë të shpresoni se përdoruesit tuaj do të marrin përditësime në kohë.
Në mënyrë tipike, cache kategorizohet sipas llojit të përdoruesit:
Kjo ndarje është për shkak të veçantisë së përmbajtjes për çdo përdorues të autorizuar dhe të përgjithshmes së përmbajtjes për përdoruesit e ftuar. Në shumicën e sajteve, një përdorues i paautorizuar nuk mund të ndryshojë përmbajtjen e faqes, dhe për këtë arsye të ndikojë në përmbajtjen e saj.
Cache e shfletuesit ju lejon të kurseni trafikun dhe kohën e shpenzuar në ngarkimin e faqeve. Por për të arritur efektin e kursimit, përdoruesi duhet të vizitojë faqen tonë të paktën një herë, që do të thotë se ngarkesa në burimet e serverit do të ulet, por jo ndjeshëm.
2. Memoria e memories së serverit
Memoria e memories së serverit i referohet të gjitha llojeve të memorizimit në të cilat të dhënat ruhen në anën e serverit. Këto të dhëna nuk janë të disponueshme për shfletuesit e klientëve. Memoria e memories krijohet dhe ruhet në bazë të një-me-shumë (shumë, në këtë rast, janë pajisje klienti).
2.1 Caching të gjithë faqes
Cache më efikase. Pse është interesante? Avantazhi i saj më i madh është se faqja kthehet pothuajse në momentin e aksesit, si rezultat, është e mundur të përpunohen miliona kërkesa edhe në serverin më të dobët me shpejtësinë e memories dhe me pak përdorim të CPU.Ndoshta dikush ka ëndërruar ndonjëherë për një faqe që funksionon me shpejtësi "ping" ose më shpejt.
Por ky lloj memorie ka edhe të metat e veta: për shembull, pamundësia për të ruajtur memorien e faqeve për një përdorues të autorizuar, ose për një përdorues, përmbajtja e faqes së të cilit varet nga variablat aktualë të përdoruesit.
Përdoreni këtë cache nëse serveri i njeh të gjitha gjendjet statike të të dhënave të jashtme, si p.sh.: uri, get (pa parametra shtesë), përdoruesi nuk është i identifikuar - domethënë, në fakt, kjo është gjendja ideale e faqes për përdoruesit e ftuar. . Mbani në mend se me një caching të tillë, arkitektura e një faqeje ose aplikacioni duhet të përpunojë gjithmonë kërkesat hyrëse në të njëjtën mënyrë dhe të japë të njëjtin lloj përgjigjesh. Një gjendje e tillë ekziston në çdo aplikacion ose sajt, duhet vetëm të gjurmohet dhe të aplikohet në cache.
Cachimi i faqeve të tëra përdoret më shpesh në një lloj urgjence, ndërsa cache e faqeve ruhet për një kohë të paracaktuar (nga 2 minuta), gjatë së cilës përgjigjet nga serveri janë të të njëjtit lloj (mos lejoni që shfletuesi të ruajë memorien kjo).
2.2 Caching e rezultateve të përpilimit të skedarëve php
Bëhet dallimi midis përpilimit të pastër të kodit dhe optimizimit të tij gjatë kompilimit (zëvendësimi i skripteve). Shembujt më të mrekullueshëm:Të dy llojet e caching mund të përdoren në një projekt, por secili ka nuancat e veta që duhet të merren parasysh kur shkruani kodin.
2.3 Caching blloqe individuale të një faqe
Ky është ndoshta lloji më interesant, por edhe më i vështirë i memorizimit. Megjithatë, ai mund të jetë gjithashtu efektiv dhe është mënyra më e lehtë për të shpjeguar parimet e cachimit në përgjithësi.Është e nevojshme të monitorohet: gjendja e tabelave, gjendja e sesionit të përdoruesit, nëse duhet të çaktivizohet caching gjatë kërkesave POST ose GET (kërkesa http), varësia nga adresa aktuale, qëndrueshmëria e cachimit (nëse ndryshojnë kushtet e mëparshme) ose rregullimin dinamik të tij.
Caching-u i blloqeve individuale të faqeve është më i mirë se llojet e tjera të memorizimit nëse keni nevojë, për shembull, të zvogëloni numrin e kërkesave në bazën e të dhënave nga përdoruesit e vërtetë (të autorizuar). Nga rruga, me varësitë e sakta, do të funksionojë edhe më me efikasitet se të gjitha llojet e mëvonshme të memorizimit.
Pse është kaq i rëndësishëm ky lloj memorie? Puna është se zgjerimi i grupit të serverëve të bazës së të dhënave është shumë më i vështirë sesa zgjerimi i grupit të serverëve të pjesës php të faqes. Për më tepër, konfliktet e gjendjes së caching php janë shumë më të lehta për t'u zgjidhur sesa konfliktet me baza të të dhënave të shumta.
2.4 Caching php bazuar në burime të pashpërndara
Ai është më i përshtatshmi për standardizimin e kërkesave, marrjen e të dhënave nga burimet e përbashkëta, duke pasur variabla të brendshme që burimet php i qasen disa herë gjatë gjenerimit të faqeve.2.5 Caching php bazuar në burimet e përbashkëta
Përdoreni këtë memorie për të ruajtur të dhënat e serializuara. Për shembull: skedari i konfigurimit, gjendja e tabelave, listat e sistemeve të skedarëve.2.6 Caching mysql bazuar në cache të pyetjeve
Kjo është një temë mjaft e njohur dhe më e mbuluar. Sidoqoftë, do të doja të merrja në konsideratë specifikat e punës me vulën kohore dhe se si mund të shmangni shpëlarjen e vazhdueshme të cache-it të pyetjeve.Me siguri, ju hasni rregullisht në një situatë kur duhet të jepni materiale të reja, data e publikimit të të cilave tashmë është e lejuar nga vula kohore aktuale? E thënë thjesht,
KU shfaqje_t<=UNIX_TIMESTAMP()
Nëse përdorni një vulë kohore që ndryshon vazhdimisht në pyetje të tilla, atëherë cache sql jo vetëm që do të jetë e padobishme, por edhe e dëmshme, pasi numri i pyetjeve të memorizuara do të grumbullohet, të dhënat e të cilave janë të vjetruara në kohën kur u krijua cache.
Ne ofrojmë mënyrat e mëposhtme për të dalë nga situata:
Si rregull, çdo material publikohet në momente të caktuara kohore. Për shembull, 00:00. E tëra çfarë ju duhet të bëni është të krijoni një pyetje që do të vlerësojë tabelën sipas datës maksimale, ndërsa më pak se ajo aktuale.
Diçka si:
ZGJIDH SQL_NO_CACHE MAX (shfaq_ts)… KU shfaq_t<=UNIX_TIMESTAMP();
Po, kjo pyetje nuk do të ruhet në memorien specifike, por të gjitha pyetjet në këtë tabelë do të ruhen nëse numri i tyre është më shumë se një. Ky operacion i thjeshtë do të përmirësojë shumë jetën e ruajtjes së memorjes sql.
Ka kuptim të ruhen këto pyetje nëse ka pak më shumë lexime nga tabela sesa regjistrime.
2.7 Caching output mysql, grumbullimi i tabelave
Ekziston një rregull: duhet të ketë shumë më pak përditësime të të dhënave sesa lexime për t'i kthyer ato.Kjo do të thotë, nuk ka kuptim të grumbullohet ajo që do të ndryshojë në të njëjtin moment, ndërsa rëndësia e të dhënave të grumbulluara është e rëndësishme.
Çfarë të zgjidhni për grumbullim? Zakonisht ky është një lloj informacioni statistikor në lidhje me numrin e regjistrimeve, datën e përditësimit të fundit, autorin e përditësimit të fundit dhe të ngjashme.
konkluzioni
Duke pasur parasysh ngarkesën e vazhdueshme të rrjetit, nuk mund të krijoni asnjë projekt pa memorie. Caching bën të mundur dërgimin e të dhënave në një rreth të madh klientësh duke përdorur burime minimale. Në këtë artikull, ne shqyrtuam shumë lloje të memorizimit, ndër të cilat jemi të sigurt se do të ketë një zgjidhje të përshtatshme për projektin tuaj.Për të optimizuar punën me rrjetin, përdoret një mekanizëm për të ruajtur dokumentet sapo të merren përmes HTTP në cache me qëllim ripërdorimin e tyre pa kontaktuar serverin burim. Dokumenti i ruajtur në cache do të jetë i disponueshëm herën tjetër që do të aksesohet, pa e shkarkuar atë nga serveri burimor, i cili është krijuar për të rritur shpejtësinë e aksesit të klientit në të dhe për të zvogëluar konsumin e trafikut të rrjetit.
Vetë memoriet janë dy llojesh - lokale dhe të përbashkëta. Local është një cache i ruajtur direkt në disk tek klienti, i krijuar dhe menaxhuar nga shfletuesi i tij. Shared është një cache e serverit proxy të një organizate ose ofruesi dhe mund të përbëhet nga një ose më shumë serverë proxy. Cache lokale është e pranishme, ndoshta në çdo shfletues; një pjesë e konsiderueshme e njerëzve që përdorin internetin përdorin një cache të zakonshme. Dhe nëse një pjesë e vogël e faqeve vlerësohen tani nga konsumi i trafikut, atëherë shpejtësia e shkarkimit është një kriter i rëndësishëm që duhet të merret parasysh kur zhvilloni projektin tuaj në internet.
Duket se memoria e fshehtë është e dëmshme për faqet dinamike të krijuara si rezultat i një programi PHP. Përmbajtja e faqes krijohet me kërkesë të përdoruesit bazuar në një burim të dhënash. Megjithatë, caching mund të jetë i dobishëm. Duke e menaxhuar atë, ju mund ta bëni punën me serverin tuaj më të rehatshëm për përdoruesin duke lejuar ngarkimin e faqeve të caktuara nga cache, duke parandaluar kështu rifreskimin e tyre nga serveri juaj dhe duke kursyer kohën dhe trafikun e përdoruesit.
Duhet të bëj memorie apo jo?
Aftësia për të cache një faqe përcaktohet nga dinamizmi i informacionit në burimin e të dhënave. Kështu, nevoja për të përdorur cache përcaktohet nga ju bazuar në jetëgjatësinë e planifikuar të faqes.
Nëse po flasim për formimin e një përzgjedhjeje sipas bazës së të dhënave (për shembull, kërkimi i një fjale të futur nga përdoruesi), atëherë një faqe e tillë duhet të kërkohet nga serveri me secilën thirrje pa përdorur cache, pasi numri i opsioneve për fjalët e kërkuara janë të mëdha, dhe nëse kemi të bëjmë edhe me ndryshimin e grupit të të dhënave, atëherë cachimi është i pakuptimtë. Ose po flasim për formimin, të themi, një orar të vizitorëve në hyrje (i cili ndryshon me çdo vizitë, d.m.th., pothuajse me çdo telefonatë), atëherë cachimi tashmë është thjesht i dëmshëm.
Megjithatë, nëse po flasim për të njëjtin orar, por për ditën e djeshme, atëherë rekomandohet ruajtja në memorie, pasi të dhënat nuk do të ndryshojnë më dhe ne mund të kursejmë veten dhe burimet e përdoruesit dhe kohën për të ngarkuar faqe të tilla duke i vendosur ato në një memorie lokale ose të përbashkët. . Si vazhdimësi e kësaj situate, formimi i grafikut nuk është në kohë reale, por për orë. Këtu mund të parashikoni paraprakisht datën e skadimit të "datës së skadimit" të të dhënave të gjeneruara.
Parimet e përgjithshme të ruajtjes së faqeve në cache
Një program PHP mund të kontrollojë ruajtjen e rezultateve të punës së tij duke formuar fusha shtesë në kokën e përgjigjes HTTP duke thirrur funksionin Header ().
Disa deklarata të përgjithshme që nuk janë unike për programet PHP:
- Faqet POST nuk ruhen kurrë në memorie.
- Faqet e kërkuara nga GET dhe që përmbajnë parametra ('?' Është i pranishëm në URL) nuk ruhen në memorien specifike, përveç rasteve kur specifikohet ndryshe.
Kështu, në shumicën e situatave, udhëzimet shtesë nuk kanë nevojë të shtohen në program. Pikat kryesore të cilave duhet t'i kushtoni vëmendje mund të reduktohen në dy:
- të mos lejojë ruajtjen në memorie të dokumenteve të ruajtura si parazgjedhje
- memoria e dokumenteve që nuk ruhen si parazgjedhje.
Parandaloni ruajtjen në memorie të dokumenteve të ruajtura si parazgjedhje
Kjo detyrë lind për skriptet PHP të quajtura pa parametra ose që janë indekse të drejtorive, megjithatë, duke gjeneruar të dhëna personalisht për përdoruesin (për shembull, bazuar në cookie ose një agjent përdoruesi) ose duke punuar në bazë të të dhënave që ndryshojnë me shpejtësi. Sipas specifikimeve HTTP / 1.1, ne mund të kontrollojmë fushat e mëposhtme:
Skadon
Përcakton datën e skadimit të dokumentit. Vendosja e tij në të kaluarën përcakton ndalimin e cache-it për këtë faqe.
Cache-control: pa-cache
Menaxhimi i cache. Vlera pa cache specifikon moslejimin e cache-it për këtë faqe. Për versionin e protokollit HTTP / 1.0, "Pragma: pa cache" është në fuqi.
E modifikuara e fundit
Data e modifikimit të fundit të përmbajtjes. Fusha është e rëndësishme vetëm për faqet statike. Apache e zëvendëson këtë fushë me vlerën e fushës Date për faqet e krijuara në mënyrë dinamike, duke përfshirë faqet që përmbajnë SSI.
Faqja www.php.net ofron kodin e mëposhtëm për të çaktivizuar ruajtjen e memories.
header ("Skadon: Hënë, 26 korrik 1997 05:00:00 GMT"); // Data në të kaluarën
header ("Modifikimi i fundit:". gmdate ("D, d M Y H: i: s"). "GMT"); // modifikuar gjithmonë
header ("Cache-Control: pa-cache, duhet të rivlerësohet"); // HTTP / 1.1
header ("Pragma: pa cache"); // HTTP / 1.0
Megjithatë, ky titull është i tepërt. Në shumicën e rasteve, mjafton:
Për të shënuar dokumentin si "tashmë i vjetëruar" vendosni Skadon e barabartë me fushën Date.
header ("Skadon:". gmdate ("D, d M Y H: i: s"). "GMT");
Gjithashtu, mbani në mend se formularët e kërkuar nga POST nuk i nënshtrohen gjithashtu caching.
Ruajtja e dokumenteve në memorie të fshehtë që nuk ruhen si parazgjedhje
Problemi i kundërt mund të duket absurd në shikim të parë. Megjithatë, ka nevojë edhe për këtë. Përveç thjesht minimizimit të trafikut, kur zhvilloni një program në internet, duhet të keni parasysh komoditetin e përdoruesit që punon me të. Për shembull, disa faqe në serverin tuaj krijohen bazuar në të dhëna të mëdha statike. Mundësia për t'i përfshirë ato në cache do të përmirësojë ndjeshëm shpejtësinë e serverit për përdoruesin dhe do të çlirojë pjesërisht tuajin nga gjeneratat e shumta të përsëritura të një faqeje të tillë. Kreu që lejon ruajtjen në serverët proxy:
Artikull i lidhur: Promovimi i motorit të kërkimit të një dyqani në internet në Yandex dhe Google: lista kontrolluese e auditimit të faktorëve të renditjes
Nëse faqja merr parasysh informacionin e ruajtur në shfletuesin e përdoruesit (lloji dhe versioni i shfletuesit, çelësat, autorizimi, etj.), Një faqe e tillë nuk mund të ruhet në proxy, por mund të ruhet në cache-in lokal të shfletuesit:
header ("Cache-control: private");
Ruajtja në memorie deri në skadimin e vlefshmërisë
Zgjidhjet e përshkruara më sipër janë mjaft të thjeshta, megjithëse janë të përshtatshme për shumicën e detyrave. Por protokolli HTTP / 1.1 ka lehtësira për kontroll më të imët të cache të faqeve, dhe ka detyra që kërkojnë përdorimin e këtyre mekanizmave. Si shembull - aplikacionet në internet që punojnë me të dhëna të mëdha dhe dinamizëm të parashikueshëm. Korrektësia e të dhënave mund të përcaktohet si nga data e përditësimit të parashikuar ashtu edhe nga ndryshimi në përmbajtje. Për këto raste përdoren tituj të ndryshëm të kontrollit të cache.
Caching parashikues i përditësimeve
Konsideroni një shembull - një listë çmimesh të përditësuar të hënën. Ju e dini paraprakisht se përmbajtja e faqes mund të ruhet në cache deri në javën e ardhshme, e cila duhet të specifikohet në kokën e përgjigjes për të siguruar sjelljen e dëshiruar të faqes në cache.
Detyra kryesore është të merrni datën e së hënës së ardhshme në formatin RFC-1123
$ dt_tmp = data e marrjes (data ("U"));
header ("Skadon:". gmdate ("D, d M Y H: i: s", data ("U") - (86400 * ($ dt_tmp ["dita"] - 8))). "GMT");
header ("Cache-kontrolli: publik");
Kjo metodë mund të kontrollojë në mënyrë efektive sjelljen e faqes në cache dhe është e dobishme për një numër të madh faqesh - në një mënyrë ose në një tjetër, ju mund të ndani intervale kohore gjatë të cilave përmbajtja e faqes mbetet konstante. Realiteti është se faqet e shumicës së faqeve dinamike kanë një jetëgjatësi të caktuar, në bazë të së cilës zhvilluesi mund ta bëjë serverin më të këndshëm për të punuar.
Një qasje tjetër e përdorur për përditësime më të shpejta të informacionit dhe trafik të lartë të serverit në të njëjtën kohë (përndryshe cachimi nuk do të jetë efektiv) është përdorimi i kontrollit të cache: max-age = seconds header, i cili përcakton kohën pas së cilës dokumenti konsiderohet i vjetëruar dhe ka një prioritet më të lartë kur llogaritet "freskia" e dokumentit.
