Variații ale codurilor pentru gestionarea cache-ului folosind anteturile Last-Modified, Expires și Cache-Control. Ce este memoria cache
Igor.
Actualizare: 21 noiembrie 2017.
Bună ziua, dragi cititori ai site-ului blogului. Continuez seria de articole care se referă la măsurile de optimizare, iar astăzi este timpul să setăm utilizarea cache-ului browserului în aceste scopuri de către utilizatori, care este următorul pas în accelerarea site-ului.
Fiecare acțiune care vă permite să vă apropiați de acest obiectiv va fi un plus în promovarea unei resurse web și, prin urmare, nu fiți prea leneși să vă uitați măcar la materialele în care am dat descrieri, precum și, care, fără îndoială, vă vor ajuta în implementarea sarcinii generale.
În cele ce urmează, voi încerca să ofer instrucțiuni clare despre cum să configurați memorarea în cache a browserului prin încorporarea unui cod special în minunatul fișier .htaccess. Adevărat, acest lucru nu este pentru toată lumea și nu poate ajuta întotdeauna, dar mai multe despre asta mai jos.
Cred că fiecare dintre voi are o idee despre ce este stocarea în cache, cel puțin în termeni generali. Pentru orice eventualitate, o să explic pe scurt. Să presupunem că un cititor deschide o pagină a resursei dvs. într-o fereastră de browser, ale cărei toate componentele (conținut, stiluri, scripturi etc.) sunt descărcate de pe serverul de găzduire, ceea ce durează ceva timp.
Să presupunem că avem posibilitatea de a lansa un mecanism care ne va permite să salvăm copii ale elementelor paginii direct în browserul web al utilizatorului care le vizitează. Apoi, cu fiecare solicitare ulterioară, toate aceste elemente vor fi preluate direct din memoria cache a browserului vizitatorului (), adică dintr-un folder special aflat pe hard disk-ul computerului său.
Câștigul în viteza de descărcare va fi evident. Acesta este algoritmul pe care îl vom studia în acest articol. Apropo, pe lângă subiect, puteți citi despre cum, împreună cu accelerarea site-ului, puteți realiza, ceea ce este foarte relevant în aceste zile.
Ceea ce este important este că, în cea mai mare parte, codul propus mai jos este destul de suficient pentru a crea condiții în care Pagespeed nu va mai face nicio pretenție și, prin urmare, se va asigura că paginile se încarcă mai repede în măsura necesară.
Deci, pe baza celor de mai sus, trebuie să asigurăm ieșirea unuia dintre anteturile Last-Modified și ETag, precum și a unuia dintre perechile Expires sau Cache-Control: max-age. Pentru claritate și pentru a extinde gama, să luăm în considerare diferite opțiuni.
Variații de cod pentru gestionarea memoriei cache folosind anteturile Last-Modified, Expires și Cache-Control
Dacă găzduirea dvs. este deja configurată pentru a scoate același Last-Modified, atunci jumătate din lucrare este gata (apropo, verificați prezența acestui antet important, inclusiv în lista lor un instrument pentru verificarea răspunsului serverului de la Yandex). Dacă nu, atunci este destul de ușor să faci asta scriind câteva rânduri în același .htaccess de neînlocuit:
RewriteRule .* - RewriteRule .* -
Adevărat, această metodă va funcționa, din nou, cu condiția să aveți un „Apache pur” (dar tocmai acesta este cazul pe care îl luăm în considerare). Vom presupune că antetul Last-Modified, a cărui valoare, apropo, va afișa data ultimei modificări, este configurat.
Acum este rândul Cache-Control cu parametrul max-age, a cărui valoare va specifica perioada de stocare în cache a fiecărui obiect static specific. Modulul vine pe scenă antete de mod, al cărui cod ar trebui introdus în .htaccess:
Trebuie remarcat faptul că prin recipient ifModule Serverul verifică prezența acestui modul. Dacă aceasta este absentă, directiva nu va fi executată, deci utilizarea ei în orice caz nu ar trebui să conducă la erori.
Timpul de păstrare a memoriei cache este determinat folosind parametrul varsta maxima, valoarea sa este setată în secunde. Datorită comentariilor (pe care, apropo, le puteți șterge în siguranță) după simbolul hash „#”, cred că baza acestei construcții este clară.
Cu toate acestea, în loc de anteturile modului, este destul de posibil să utilizați modulul modul expiră, afișând antetul Expires (care, conform Google însuși, este de preferat deoarece are suport mai larg). În acest caz, fragmentul de cod pentru a-l activa va fi astfel:
Punctul de pornire pentru data de expirare a memoriei cache atunci când utilizați antetul Expires este data primei încărcări. Mai mult, spre deosebire de Cache-Control, unde perioada de timp este definită doar în secunde, aici poate fi specificată în orice format de timp, inclusiv anul.
Pentru a vedea acest lucru, priviți secțiunea cu imagini a codului. Acolo am indicat în mod specific timpul în diferite unități: 1 lună, 4 săptămâni, 30 de zile, 43829 minute, 2592000 secunde.
Este clar că o lună și un an pot avea un număr diferit de zile, săptămâni, minute și secunde, dar acest lucru nu este important, deoarece se folosesc valori medii. Apropo, pentru fișierele și imaginile JS, CSS, se recomandă setarea unei perioade de timp de cel puțin o săptămână, dar nu mai mult de un an. În acest caz, de fapt, data sfârșitului așteptat al perioadei de stocare în cache a acestei versiuni a obiectului va fi indicată ca valoare a antetului Expires în răspunsul serverului.
Pe lângă modulele menționate, este util să se folosească și mod setenvif. Cert este că browserele web ale familiei Microsoft Internet Explorer și unele versiuni de Mazila nu percep corect antetul Vary în răspunsul serverului HTTP, ceea ce aduce, de asemenea, o contribuție importantă la gestionarea cachei. Acest modul vă permite să rezolvați această problemă prin excluderea lui Vary din răspunsul serverului:
Ca rezultat obținem două variante finale setările de cache, pe care le puteți verifica inserând una câte una în .htaccess (nu recomand să le folosiți pe ambele în același timp):
Permiteți-mi să vă reamintesc încă o dată că, în ciuda prezenței containerului IfModule, care asigură siguranța editării, nu ar fi greșit să faceți o copie de rezervă a versiunii originale a fișierului de fiecare dată când schimbați .htaccess (puteți copia pur și simplu conținutul acestuia și salvați-l pe computer) pentru a nu fi prins prin surprindere cu forța majoră într-o variantă sau alta.
Cod pentru generarea antetelor Etag și Expires pentru a configura memoria cache
În cazul în care directivele propuse mai sus nu funcționează brusc (chiar dacă pe găzduirea dvs. este instalat Apache „pur), să ne uităm la un alt caz, și anume, când o pereche de anteturi obligatorii Etag și Expires acționează ca instrumente de control al caching-ului. După cum vă amintiți, ambii sunt responsabili pentru livrarea la timp a fișierelor din cache, inițiind o verificare a relevanței versiunii curente.
Dar dacă data ultimei modificări este afișată ca valoare Expires, atunci ETag-ul folosește unul sau altul identificator unic de resursă (mai des acest rol este jucat de versiunea fișierului). Pentru a activa ETag trebuie să introduceți doar o linie în același .htaccess:
FileETag MTime Size
Ei bine, atunci aplica modul modul expiră, deja cunoscut de noi. De asemenea, puteți adăuga mod setenvif, care, așa cum am spus mai sus, interzice formarea antetelor Vary pentru un anumit grup de browsere web pentru a asigura formarea unui cache din partea lor:
FileETag MTime Size
Aici folosim un complex cu un minim de tipuri de obiecte implicate, dar cele mai populare (CSS, JavaScript si imagini), care ar trebui sa fie si suficiente pentru a asigura eficienta maxima in accelerarea site-ului. Dacă doriți, puteți adăuga alte tipuri de fișiere la setul „jpg|jpeg|gif|png|ico|css|js”.
În plus, în exemplul de cod de mai sus, toate fișierele sunt supuse aceleiași perioade de viață cache de un an („acces plus 1 an”), care este recomandat de Google. Dar puteți specifica propria perioadă de timp pentru fiecare grup de obiecte, urmând exemplul conținutului modulelor mod_expires și mod_headers din secțiunea anterioară a articolului.
Verificarea prezenței antetelor necesare în răspunsul serverului
După ce lipiți codul în fișierul .htaccess, puteți verifica dacă anteturile necesare sunt incluse în răspunsul serverului. În acest scop, puteți utiliza un serviciu online, de exemplu, Checkmy.ru, unde selectăm orice browser ca client (User Agent) care trimite o solicitare HTTP către server și, de asemenea, introducem adresa URL a resursei (de exemplu, am luat calea către imagine, folosită într-unul dintre articolele de pe blog):
După ce faceți clic pe butonul „Trimiteți cererea”, după câteva secunde va apărea rezultatul:
După cum puteți vedea, în cazul meu sunt prezente toate cele patru anteturi. Am spus că una dintre perechile „Last-Modified - ETag” și „Expires - Cache-Control” trebuie afișată, restul nu sunt necesare. În acest caz, setul complet, din câte se poate judeca cineva, nu va cauza prejudicii.
Apropo, dacă testați înainte de a începe configurarea memoriei cache, puteți determina imediat cât de productive vor fi acțiunile dvs.
La urma urmei, dacă nginx este prezent în răspunsul serverului, atunci va fi necesar să-l configurez (furnizorul meu a făcut acest lucru), iar fișierul de configurare .htaccess va fi inutil aici. În acest caz, așa cum am menționat deja, va trebui să utilizați ajutorul serviciului de asistență, cu excepția cazului în care, desigur, tariful dvs. de găzduire și cunoștințele insuficiente vă permit să rezolvați singur problema.
În continuare, pentru a consolida materialul, vă sfătuiesc să apelați la videoclip și să urmăriți 6 lecții în succesiune (dintre care una este dedicată instalării caching-ului în browsere), care discută în detaliu toate cele mai importante aspecte ale accelerării unui site web WP. :
");">
Doriți să primiți articole proaspete, relevante și utile în timp util? Apoi te poți abona:
Mai multe articole pe acest subiect:
60 de recenzii
- Denis
O modalitate foarte utilă de a crește confortul de a fi pe site. La urma urmei, prin optimizarea vitezei de încărcare, economisiți astfel timpul vizitatorului și pentru aceasta vă va fi recunoscător vizitând site-ul dvs. din nou și din nou. Ceea ce va afecta direct veniturile site-ului într-un mod pozitiv.
- Igor
Absolut dreptate, Denis. Totul este interconectat în promovarea site-ului.
- Marazzi
Nu înțeleg nimic, browserul își amintește efectiv site-urile pe care a fost în cookie-uri, dacă ștergeți cookie-urile. CONFORM METODEI DVS., atunci schema dumneavoastră va înceta să funcționeze, sau mai bine zis, înțeleg că despre asta este vorba în conversație, este destinată unui vizitator obișnuit care nu curățează istoricul7 ABONAT, AȘTEPTĂ UN RĂSPUNS1;
- Serghei Dmitrievici
Informatii foarte utile. Mi s-a părut util. Multumesc.
- Igor
Marazzi, in primul rand, cookie-urile si cache-ul sunt lucruri diferite. Cookie-urile sunt fișiere speciale cu un set de date care vă permit să identificați un utilizator dacă acesta vizitează o resursă web. Și memoria cache (tradusă din engleză ca depozit, ascunzătoare) a browserului este un fel de loc izolat pentru stocarea copiilor de documente (de exemplu, pagini web de site), care, dacă este necesar, sunt afișate în browser. Pe partea de server este făcută comanda pentru a utiliza memoria cache din partea browserului utilizatorului, iar un folder cu memoria cache este creat pe computerul utilizatorului. La rândul său, utilizatorul poate regla frecvența creării de copii în cache ale paginilor site-ului prin ștergerea folderului cache. Sau dezactivați complet stocarea în cache; setările browserelor moderne permit acest lucru. Cu cât ștergeți mai des memoria cache, cu atât veți obține versiunea mai recentă a paginii.
- Nikolai
Super, si totul este OK aici!!!
- marazzi
Ei bine, despre asta vorbeam.
- Alexandru
- Nikolai
Multumesc pentru articol. Adevărat, nu este complet clar cum să ștergeți acest cache mai târziu dacă, de exemplu, o nouă categorie sau secțiune apare pe site sau, dimpotrivă, dispare. Desigur, exagerez foarte mult, dar sensul este același. Uneori, memoria cache trebuie șters, cum este implementat acest lucru în acest cod?
- Irina
BINE! Multumesc!
Acest cod a ajutat, acum 80 din 100FileETag MTime Size ExpiresActiv on ExpiresDefault „acces plus 1 an”
- Igor
Nikolay, nu prea am înțeles întrebarea ta. Acesta este codul pentru stocarea în cache a paginilor din browserele utilizatorilor; Articolele și categoriile noi sunt afișate chiar și atunci când memoria cache este plină. Doar elementele care rămân neschimbate pentru o perioadă lungă de timp sunt stocate în cache pentru o perioadă lungă de timp.
- Andrei
Multumesc. Dar dacă am nevoie doar de anumite elemente pentru a fi stocate în cache, de exemplu, sigla și steagurile țărilor din subsol, atunci ce ar trebui să fac?
- Igor
Andrey, de ce trebuie să separați imaginile, să memorați în cache unele și nu altele? De obicei, imaginile nu se schimbă cu viteza caleidoscopică.
- Andrei
Ei bine, da, ai dreptate cu pozele. Și nu păstrați în cache o anumită pagină (de exemplu, din panoul de administrare). Este posibil acest lucru?
- Igor
Desigur că este posibil. Dacă utilizați un plugin de stocare în cache, cum ar fi Hyper Cache, atunci setările sale au o mulțime de opțiuni diferite, inclusiv posibilitatea de a exclude paginile care nu pot fi stocate în cache.
- Yaroslav
Articol foarte util, îmi doream de mult să configurez memoria cache, dar anterior am găsit prima metodă prezentată peste tot și nu a făcut absolut nimic.
Dar, datorită celei de-a doua metode, totul funcționează cu brio!! PS 91 - Igor
Rezultat bun, Yaroslav.
- stan
nici un fel nu funcționează
- Igor
Stan, se poate ca asta să depindă în mare măsură de găzduitor.
- Ilya
Nu există cuvinte pentru cât timp am căutat un articol despre cum să activez timpul de stocare în cache a browserului, a trebuit doar să introduc codul de top. Multumesc pentru articol.
- Igor
Te rog, Ilya.
- Gri
Mulțumesc, funcționează!
- Serghei
nici una dintre metode nu funcționează
hosterul este adecvatSe pare că vor trebui să scrie pentru a susține
- Igor Gornov
Da, Serghei, poate. Puteți vedea singuri că mulți reușesc să o implementeze.
- Alexandru Puzatykh
Multumesc. Informații grozave. Acum o voi corecta pe site-ul meu. În caz contrar, pgespeed dă un semn roșu.
- Yuri
Am făcut totul așa cum este descris, dar viteza de încărcare a PageSpeed Insights nu s-a schimbat (74%). Care ar putea fi motivul?
- Yuri
Aici este htaccess-ul meu
# ÎNCEPE WordPressRewriteEngine Pornit
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %(REQUEST_FILENAME) !-f
RewriteCond %(REQUEST_FILENAME) !-d
RewriteRule. /index.php [L]#ENDWordPress
Adaug codul tau si nu se schimba nimic
PageSpeed Insights rămâne la 74%.
Spune-mi care ar putea fi problema??? - Igor Gornov
Configurația specifică a serverului dvs. de găzduire unde se află site-ul. În opinia mea, am notat deja în articol și în comentarii că această metodă nu este potrivită pentru toată lumea.
- Valery
Igor, bun articol. Îmi doream de mult să fac asta, dar nu știam cum. Acum e clar. Am o întrebare: „Unde în fișierul .htaccess ar trebui să lipesc codul?”
- Igor Gornov
Valery, dacă aveți deja câteva fragmente de cod în .htaccess, atunci ar trebui să existe o linie ca aceasta:
#ENDWordPress
În acest caz, nu numai acesta, ci și orice cod ar trebui plasat deasupra acestei linii. Restul nu contează.
- vokacan
Informațiile sunt utile, dar destul de greu de înțeles pentru un începător, după părerea mea.
- Aely
În mod ciudat, nu a funcționat același lucru pentru mine, dar ce ar trebui să fac, sau mai degrabă, ce ar trebui să-l întreb pe gazdă?
- Igor Gornov
Trebuie să întrebați găzduitorul următoarele: este posibil să activați stocarea în cache pe server pentru toate fișierele posibile. Poate că au deja un algoritm gata făcut, diferit de cel pe care l-am propus.
- Aely
Multumesc, am scris-o acum.
- Aely
Iată o glumă, ei (hosterul) au spus că au totul inclus și le-am spus, iar Googlespeedtest arată „utilizați cache-ul browserului” și mi-au spus că acestea sunt întrebări pentru Googlespeedtest. Nu pot să-mi dau seama pe cine să cred?
- Igor Gornov
Aely, această atitudine față de client din partea hosterului este, cel puțin, ciudată. În teorie, ar trebui să explice și să ofere un posibil algoritm pentru adăugarea acestuia în fișierul .htaccess pentru a activa funcția, chiar dacă o au activată. Mă întreb dacă nu este prima dată când contactați serviciul de asistență, cum s-a comportat acesta în alte situații?
17.04.1999 Phil Keppeler
Se așteaptă ca serverele cache IP să fie la mare căutare pe piața întreprinderilor în 1999. Mai jos vom analiza cele mai recente oferte de la producători.
Spre deosebire de lățimea de bandă a rețelelor globale, memoria a devenit mult mai ieftină.
Se așteaptă ca serverele cache IP să fie la mare căutare pe piața întreprinderilor în 1999. Mai jos vom analiza cele mai recente oferte de la producători.
Spre deosebire de lățimea de bandă a rețelelor globale, memoria a devenit mult mai ieftină. Potrivit cercetării IDC, nivelul general al prețurilor pentru rețelele globale va rămâne același sau, în cel mai bun caz, va scădea ușor. Între timp, costul memoriei scade anual cu 31,4-39,8%.
Comunitatea internetului cunoștea beneficiile stocării în cache cu mult înainte ca Internetul să devină fenomenul comercial care este astăzi. De obicei, arhivele de fișiere pentru servicii de internet, cum ar fi ftp, gopher și conferințe, erau reflectate în întreaga lume pentru a păstra fișierele populare cât mai aproape de utilizatori. Odată cu apariția HTTP, oglindirea a devenit ineficientă din cauza volumului mare, a sensibilității la timp și a naturii aleatorii a conținutului solicitat.
Serverele cache IP sunt pentru HTTP ceea ce a fost oglindirea pentru protocoalele de arhivare. Toate serverele cache se bazează în esență pe aceleași principii: interceptează cererile de obiecte de la browser către serverul Web și stochează obiectele primite de la server pe hard disk înainte de a le transmite către browser. Astfel, la solicitările ulterioare pentru același obiect de la alte browsere, serverul cache returnează o copie a obiectului din memoria sa în loc să transmită o cerere către serverul Web pentru a obține obiectul original. În mod ideal, ca un server cache să execute cereri pentru obiecte ar trebui să economisească atât timp, cât și lățime de bandă. (O descriere mai detaliată a tehnologiei de stocare în cache poate fi găsită în articolul „Small cache is expensive” din LAN nr. 3 pentru acest an.)
Sub presiunea atât din partea consumatorilor, cât și a furnizorilor de conținut, furnizorii de internet au devenit utilizatorii principali ai caching-ului IP. Opțiuni de conectivitate mai rapide, cum ar fi Digital Subscriber Line (DSL), IDSN și modemurile prin cablu, oferă speranța că ceea ce a fost odată cea mai slabă verigă din lanțul de date a fost un modem telefonic standard cu o rată maximă de transfer de date de 56 Kbps/s eliminat. Pe măsură ce conexiunile la Internet se accelerează, volumul de obiecte copiate va crește proporțional, ceea ce va duce la o creștere a traficului pe coloana vertebrală a Internetului. În același timp, furnizorii de conținut trec la formate de date mai complexe și cu volum mare, cum ar fi streaming audio/video și applet-uri Java.
Ca urmare a acestui atac în două direcții, furnizorii de internet sunt nevoiți să găsească modalități mai eficiente de a-și folosi infrastructura pentru a satisface cerințele utilizatorilor. Cacheul IP a fost și rămâne o parte importantă a soluției lor.
Deși mulți furnizori de internet recunosc beneficiile stocării în cache IP, întreprinderile încă nu implementează tehnologia la scară largă. Conform unui raport de cercetare colaborativă din februarie 1998, aproximativ 80% dintre furnizorii de internet din Statele Unite au anunțat planuri de a implementa memorarea în cache în următoarele șase luni. Pe de altă parte, doar 56% dintre companii plănuiau să înceapă să folosească memorarea în cache în aceeași perioadă. Cu toate acestea, după cum prevăd experții, în 1999 stocarea în cache va fi la mare căutare pe piața corporativă. Potrivit Collaborative Research, investiția în tehnologia de stocare în cache a întreprinderii este de așteptat să o depășească rapid pe cea a furnizorilor de internet, crescând de la 85 milioane USD în 1998 la peste 1 miliard USD în 2000 (vezi tabelul).
| Piața mondială a produselor de stocare în cache în perioada 1998-2002. | |||||
|---|---|---|---|---|---|
| Segmentul de piata | 1998 | 1999 | 2000 | 2001 | 2002 |
| Utilizatori corporativi | 85 de milioane de dolari | 421 de milioane de dolari | 1.113 milioane de dolari | 2.108 milioane de dolari | 3.157 milioane de dolari |
| furnizorii de internet | 103 milioane de dolari | 214 milioane de dolari | 376 de milioane de dolari | 481 milioane dolari | 576 milioane dolari |
| Alte | 19 milioane de dolari | 63 de milioane de dolari | 149 de milioane de dolari | 259 de milioane de dolari | 373 de milioane de dolari |
| Total | 207 milioane de dolari | 698 de milioane de dolari | 1.638 de milioane de dolari | 2.848 milioane de dolari | 4.106 milioane de dolari |
| Sursa: Collaborative Research, 1998 | |||||
Această tendință nu a trecut neobservată de producători, iar aceștia își reorientează în mod activ produsele către clienții corporativi. Producând inițial produse high-end pentru furnizorii de internet, producătorii au început să includă oferte în liniile lor de produse la un preț relativ scăzut și cu un nivel de performanță suficient pentru companii. În plus, o duzină de noi furnizori au anunțat sau au lansat servere cache bazate pe hardware și software standard din industrie - cum ar fi servere bazate pe Intel cu software gratuit de stocare în cache Squid - cu scopul de a oferi produse cât mai ieftine.
INTERMEDIAR CA CACH?
Primele servere cache au fost implementate de obicei pe baza serverelor proxy. Ca atare, aceștia au acționat ca brokeri de obiecte pentru un grup de utilizatori, acceptând toate cererile și transmitându-le către destinație pe Internet. Ca punct de acces comun pentru toți utilizatorii, serverele proxy s-au dovedit a fi extrem de atractive pentru implementarea unei varietăți de servicii suplimentare: filtrarea conținutului, identificarea utilizatorilor, înregistrarea evenimentelor și stocarea în cache a obiectelor. Împreună cu un firewall, serverul proxy a făcut posibilă crearea unei conexiuni securizate la Internet.
Unul dintre primii intermediari activați pentru cache a fost serverul software Harvest Cache, care a fost rezultatul unui proiect comun finanțat în 1994-1996 de Agenția pentru Proiecte Avansate de Cercetare (ARPA), Fundația Națională pentru Știință, NSF) și NASA. De atunci, cel puțin o duzină de produse au fost comercializate ca „intermediari de caching”. În special, Netscape Communications, Microsoft și Novell au toate serverele proxy activate pentru cache, care sunt strâns integrate cu celelalte instrumente ale companiei. Pe lângă stocarea în cache, produsele lor oferă o mare varietate de funcții intermediare, cum ar fi autentificarea utilizatorilor, filtrarea conținutului, scanarea virușilor, securitatea și înregistrarea evenimentelor. Proxy-ul Microsoft rulează pe Windows NT 4.0; Server proxy de la Netscape - bazat pe majoritatea soiurilor de UNIX, precum și Windows NT; BorderManager FastCache de la Novell - pe IntranetWare, NetWare 4.11 și NetWare 5.
Un alt intermediar comercial utilizat pe scară largă este Squid, o extensie a Harvest Cache dezvoltată de Laboratorul Național pentru Cercetare în Rețea Avansată (NLANR). Poate pentru că a apărut ca produsul unui efort colectiv într-un mediu în care software-ul standardizat și acceptat este binevenit și utilizat pe scară largă, Squid s-a impus pe piața furnizorilor de internet și continuă să aibă o bază instalată relativ puternică.
Configurațiile cu cache proxy au două dezavantaje principale. În primul rând, deoarece browserul fiecărui utilizator trebuie configurat să treacă printr-un intermediar, o defecțiune a serverului face ca toți utilizatorii să își piardă conexiunea la Internet. În al doilea rând, introducerea în configurația browserului fiecărui utilizator cu informații despre intermediar poate fi laborioasă în întreprinderile mari și, în esență, o sarcină imposibilă pentru operatorul de internet.
Pentru a evita aceste probleme în configurațiile man-in-the-middle, puteți implementa memorarea în cache transparentă în rețeaua dvs. instalând un router activat pentru politici sau un comutator Layer 4 pentru a redirecționa traficul către un server cache sau un grup de servere. Aceste dispozitive interceptează tot traficul HTTP de pe portul 80 și îl redirecționează în cache. Cache-ul face cereri HTTP și returnează obiectele înapoi în browser. O soluție de cache cu adevărat transparentă trebuie să susțină scalabilitate prin echilibrarea încărcării pe mai multe servere cache, precum și transferarea la serverele de rezervă dacă unul sau toate serverele cache nu sunt disponibile. Exemple de dispozitive de comutare Layer 4 includ ACEdirector de la Alteon Networks și ServerIron de la Foundry Networks.
Infolibria Cache Server de la DynaCache adoptă o abordare diferită, oferind transparență fără a fi nevoie de un comutator sau un router separat. Acest lucru se realizează folosind DynaLink Redirector (DLR), un comutator dedicat Layer 4 care interfață cu DynaCache. DLR-ul, o parte integrantă a strategiei de stocare în cache a companiei, se află în rețea și transmite numai pierderile de memorie cache către Internet. Potrivit companiei, această strategie poate reduce sarcina de pe router cu două treimi.
SOFTWARE VS HARDWARE
În 1997, într-un raport intitulat „De ce contează cachingul în cache”, Forrester Research a prezis că furnizorii de servicii de internet și companiile vor migra de la serverele software cache la dispozitive dedicate de cache. De asemenea, Dataquest a declarat într-un raport din iulie 1998 că dispozitivele dedicate vor domina piața produselor de stocare în cache.
Prin urmare, nu este surprinzător faptul că peste o jumătate de duzină de producători au lansat dispozitive de stocare în cache în 1998. Ei susțin că produsele lor oferă performanțe mai bune decât omologii lor software, deoarece sistemul de operare și serverul de cache sunt strâns integrate între ele și optimizate pentru stocarea în cache. De asemenea, susțin că produsele lor sunt mai ușor de configurat și configurat și oferă platforme mai sigure, deoarece este mai puțin probabil să creeze găuri de securitate din cauza erorilor administrative sau de configurare. În mod obișnuit, cache-urile software, cum ar fi proxy-ul de cache discutat mai sus, sunt concepute având în vedere un accent proxy, în timp ce cache-urile hardware sunt concepute exclusiv pentru a suporta stocarea în cache grea. În ciuda acestui fapt, multe dispozitive de stocare în cache pot fi utilizate în configurații proxy.
Network Appliance a fost unul dintre primii care a oferit un dispozitiv de stocare în cache dedicat. Pentru a face acest lucru, a adaptat software-ul NetCache pentru produsul hardware. Network Appliance a achiziționat software-ul NetCache (și l-a achiziționat pe Peter Danzig, unul dintre arhitecții șefi ai Harvest Project), împreună cu o mică companie start-up, Internet Middleware.
Alte dispozitive de stocare în cache introduse în 1998 includ Cache Engine de la Cisco Systems, CacheFlow de la CacheFlow și DynaCache de la InfoLibria. Deși nu este un dispozitiv strict dedicat, Netra Proxy de la Sun Microsystems vine preconfigurat pe un computer UltraSPARC II. Conține software-ul de cache al Sun și este optimizat pentru aceste funcții.
Mai recent, pe piață au apărut dispozitive de cache relativ ieftine. Acestea se bazează pe hardware și software standardizat și sunt dispozitive server preconfigurate concepute pentru a face ca stocarea în cache să fie mai simplă și mai accesibilă. Această abordare poate fi atractivă pentru companiile mici sau chiar pentru marile corporații care doresc să profite de avantajele memorării în cache a grupului de lucru, dar care ezită din cauza costului ridicat și complexității soluțiilor disponibile. Prețul acestor produse se situează în jurul a 2.000 USD, în timp ce soluțiile menționate mai sus costă cel puțin 7.000 USD.
Trei exemple de dispozitive de stocare în cache cu costuri reduse sunt CacheQube și CacheRaQ de la Packetstorm Technologies WebSpeed și Cobalt Networks. WebSpeed se vinde cu amănuntul între 2.100 USD și 7.100 USD, în funcție de dimensiunea memoriei cache. WebSpeed folosește procesoare Intel și sistemul de operare Linux gratuit, precum și software-ul de stocare în cache Squid. Compania pariază că clienții vor aprecia un dispozitiv preconfigurat, la preț redus, pe care îl pot instala în rețelele lor cu efort minim. CacheQube de la Cobalt Network și CacheRaQ montat pe rack pot fi extinse fie prin creșterea capacității DRAM și a spațiului pe disc, fie prin crearea unui cluster de dispozitive multiple. CacheQube costă 1.899 USD, iar CacheRaQ costă 2.299 USD sau 2.799 USD, în funcție de configurație.
În încercarea de a contracara predicțiile experților conform cărora dispozitivele dedicate de caching vor domina piața, Inktomi a lansat Traffic Server, pe care compania îl poziționează ca o soluție de înaltă performanță de caching destinată în primul rând furnizorilor de servicii de internet și companiilor mari. În schimb, alte cache-uri software se concentrează pe funcțiile de mediere și protecție la fel de mult ca și pe funcțiile de cache. La 30.000 USD per CPU, Traffic Server are și prețul unui produs de calitate operator.
COMPATIBILITATE ȘI STANDARDE
Datând din cercetările timpurii privind stocarea în cache de la Harvest Project, Internet Caching Protocol (ICP) definește modul în care mai multe servere cache IP pot partaja informații despre recentitatea obiectelor Web și modul în care preiau obiecte din alte cache (spre deosebire de preluarea obiectelor din originalul). server web). Cu ICP, administratorii de server pot configura memoria cache pentru a interoga alte servere cache care acceptă și ICP pentru a vedea dacă au cele mai recente informații despre obiectele Web. De exemplu, un cache local ar putea cere unui cache din amonte să vadă dacă are o copie mai nouă a unui fișier, iar dacă nu are, atunci dacă a verificat vechimea fișierului pe serverul de origine. Chiar dacă serverul din amonte nu are o versiune mai nouă a fișierului, este posibil să fi verificat recent dacă fișierul de pe serverul din amonte sa schimbat. În funcție de algoritmul de actualizare, memoria cache locală poate folosi aceste informații pentru a prelua o versiune mai nouă a obiectului de pe serverul de origine sau poate utiliza o copie locală (vezi figura).
Sondajul cache-ului din amonte introduce o latență suplimentară datorită distanței și timpului de transmisie crescut; cu toate acestea, economiile de timp vor fi destul de semnificative în multe cazuri, deoarece cererea nu trebuie să se deplaseze până la server cu obiectul original. În plus, furnizarea de obiecte de pe serverele de comunicare ICP situate aproape de destinatar va reduce sarcina pe coloana vertebrală a Internetului, eliberând lățime de bandă pentru comunitatea de internet în ansamblu. Aproape toate soluțiile de stocare în cache acceptă astăzi ICP.
Similar cu ICP, protocolul CARP (Caching Array Routing Protocol) este un protocol pentru partajarea încărcăturii de cache într-o flotă de servere locale. Acesta a fost dezvoltat de Microsoft și înaintat la World Wide Web Consortium (W3C) ca propunere standard pentru Internet. Pe lângă Microsoft, aproximativ o duzină de alți furnizori, inclusiv Packetstorm Technologies și Sun, au anunțat suport pentru CARP.
Pentru a permite cache Engine să comunice cu routerele sale, Cisco a dezvoltat Web Cache Communication Protocol (WCCP). Cu WCCP, un router Cisco IOS interceptează solicitările HTTP de la browsere și le transmite către un server cache sau către un dispozitiv dedicat. WCCP acceptă scalabilitate prin distribuirea cererilor pe mai multe servere cache în funcție de disponibilitatea acestora.
În noiembrie 1998, Cisco a început să acorde licențe WCCP altor producători de produse de stocare în cache. Inktomi și Network Appliance au anunțat planuri de a include suport WCCP în lansările viitoare ale produselor lor.
INDICATORI DE PIAȚĂ
În ciuda unor controverse cu privire la cifre, piața produselor de stocare în cache pe Internet este de așteptat să crească semnificativ în următorii patru ani. Collaborative Research proiectează ca piața să crească de la 206 milioane USD în 1998 la peste 4 miliarde USD în 2002.
Având în vedere aceste cifre, nu este surprinzător faptul că marii producători și dezvoltatori de software și hardware încearcă să își folosească poziția pentru a pătrunde pe piața de caching. De exemplu, cu o bază mare instalată de sisteme de operare pentru server, Novell se bazează pe integrarea strânsă a BorderManager cu celelalte produse ale sale pentru a atrage atenția clienților corporativi.
La fel ca Novell, Microsoft și Sun luptă pentru dominația pe piața de software și servere de internet. Ambii au baze mari instalate de servere Web și își poziționează produsele – cu arsenalul lor de capabilități intermediare – ca componente esențiale pentru un mediu de suport integrat pentru aplicații Web. Cu o bază mare instalată de dispozitive de rețea, integrarea strânsă a Cache Engine cu alte componente de rețea Cisco poate ajuta la promovarea adoptării pe scară largă.
PRET CE AI NEVOIE
Dacă decideți să implementați memorarea în cache în rețeaua dvs., veți avea de ales de la produse gratuite la cele care costă 100.000 USD sau mai mult. În general, cu cât produsul este mai scump, cu atât este mai puternic.
La capătul inferior al scalei de preț, unde serverele de cache software au dominat recent, acum puteți găsi aproximativ o duzină de dispozitive de stocare în cache. Când utilizați un produs gratuit, cum ar fi Squid, care este disponibil atât în formă sursă, cât și în formă precompilată, veți avea nevoie de un computer pe care să îl instalați. Pentru a evita cheltuielile inutile, puteți reutiliza echipamentele existente pentru a efectua sarcini de stocare în cache.
Netscape, Microsoft și Novell oferă servere cache software puternice, cu o gamă largă de caracteristici de mediere. Produsele lor costă în jur de 1000 USD per CPU. Ca și în cazul Squid, costul total al soluției poate fi redus prin utilizarea hardware-ului existent. În caz contrar, costul achiziției de echipamente va trebui inclus în partea de cheltuieli.
Phil Keppeler este un dezvoltator web la o firmă de proiectare și programare. El poate fi contactat la: [email protected].
Produse revizuite
Microsoft Netscape Communications Laboratorul Național de Cercetare Avansată în Rețea Alteon Networks director ACE Brian D. Davidson, Ph.D. de la Universitatea Rutgers, menține o pagină de informații despre stocarea în cache pe serverul său http://www.cs.rutgers.edu/~davison/Web-caching/. Conține știri despre stocarea în cache, o listă și un tabel cu intermediarii de cache, o bibliografie etc. Dacă doriți să aflați mai multe despre Harvest Project, linkurile relevante către rezultatele cercetării, transcrierile întâlnirilor și întrebările frecvente sunt disponibile la: http://www.harvest.transarc.com . CacheNow este o campanie în curs de desfășurare de promovare a stocării în cache la scară largă pentru a aborda deficitul de lățime de bandă și a depăși limitările infrastructurii Internet. Informații despre acesta sunt disponibile pe http://vancouver-Webpages.com/CacheNow/ . |
Ce este memoria cache a browserului?
- htaccess caching salvează conținutul unei pagini web pe computerul local atunci când un utilizator o vizitează;
- Utilizarea cache-ului browserului – webmasterul instruiește browserele cum să trateze resursele.
Când browserul redă o pagină web, trebuie să încarce sigla, fișierul CSS și alte resurse:
Cache-ul browserului „îți amintește” resursele pe care browserul le-a descărcat deja. Când un vizitator merge pe o altă pagină de pe site, logo, fișiere CSS etc. nu ar trebui să fie descărcate din nou deoarece browserul le-a „rememorat” deja (le-a salvat). Acesta este motivul pentru care pagina web durează mai mult să se încarce la prima vizită decât la vizitele repetate.
Când utilizați memoria cache, fișierele paginii web vor fi stocate în memoria cache a browserului. Paginile se vor încărca mult mai repede la vizitele repetate. Se va întâmpla și cu alte pagini care folosesc aceleași resurse.
Cum să activați memoria cache a browserului
- Modificați anteturile cererii de resurse pentru a utiliza stocarea în cache;
- Optimizați-vă strategia de stocare în cache.
Modificarea antetelor cererii
Pentru majoritatea oamenilor, singura modalitate de a stoca în cache htaccess-ul unui site este să adăugați cod la fișierul .htaccess de pe serverul web.
Fișierul .htaccess controlează multe setări importante pentru site-ul dvs.
Memorarea în cache a browserului prin fișierul .htaccess
Codul de mai jos îi spune browserului ce să memoreze în cache și cât timp să-l „amintească”. Ar trebui adăugat la începutul fișierului .htaccess:
## EXPIRĂ CACHING-ul ##
Salvați fișierul .htaccess și apoi reîmprospătați pagina web.
Cum să setați timpul de cache pentru diferite tipuri de fișiere
Codul de mai sus specifică intervale de timp. De exemplu, 1 an (1 an) sau 1 lună (1 lună). Sunt legate de tipurile de fișiere. Codul de mai sus prevede că fișierele .jpg (imaginile) ar trebui să fie stocate în cache timp de un an.
Dacă doriți să schimbați acest lucru, astfel încât imaginile JPG să fie și ele stocate în cache pentru o lună, atunci ați înlocui pur și simplu „1 an” cu „1 lună”. Valorile de cache htaccess de mai sus sunt optime pentru majoritatea paginilor web.
Metodă alternativă de stocare în cache pentru .htaccess
Metoda descrisă mai sus se numește „ Expiră„, îi ajută pe majoritatea începătorilor cu memorarea în cache. Odată ce vă simțiți confortabil cu memorarea în cache, puteți încerca o altă metodă de stocare în cache numită Cache-Control, care vă oferă mai multe opțiuni.
Este posibil ca metoda Expires să nu funcționeze pe serverul dvs., caz în care ar putea dori să încercați să utilizați Cache-Control.
Cache-Control
Această metodă vă permite să obțineți mai mult control asupra stocării în cache a paginii în browser, dar multor persoane le este mai ușor să specifice toate setările o dată.
Exemplu de utilizare într-un fișier .htaccess:
#1 lună pentru majoritatea activelor statice
Codul de mai sus setează antetul Cache-Control în funcție de tipul fișierului.
Cum funcționează Cache-Control?
Luați în considerare linia de mai sus a codului de stocare în cache în browserul htaccess:
#1 lună pentru majoritatea activelor statice
Această linie este doar o notă. Fișierul .htaccess ignoră liniile care încep cu caracterul #. Această notă este recomandată deoarece este posibil să aveți mai multe seturi de date diferite ca soluție de stocare în cache a fișierelor:
Linia menționată mai sus spune că „ dacă fișierul este unul dintre aceste tipuri, atunci vom face ceva cu el...»
Cel mai important lucru la această linie este că listează diferitele tipuri de fișiere ( CSS, JS, JPEG, PNG etc. ) și că instrucțiunile de stocare în cache ar trebui aplicate acestor tipuri de fișiere. De exemplu, dacă nu doriți ca fișierele JPG să fie stocate în cache pentru o anumită perioadă de timp, puteți elimina „ JPG". Dacă doriți să adăugați HTML, atunci trebuie să indicați în această linie „ HTML«:
Set antet Cache-Control „max-age=2592000, public”
Linia menționată mai sus stabilește anteturile și valorile reale:
- Partea " Setul antet Cache-Control» — stabilește titlul;
- variabila " varsta maxima=2592000„—indică cât timp va dura procesul de stocare în cache (în secunde). În acest caz, păstrăm în cache timp de o lună (2592000) secunde;
- Partea " public» raportează că este disponibil public.
Această linie de cache htaccess închide instrucțiunea și încheie blocul de cod.
Dacă, după actualizarea configurației, formularele dvs. plutesc, raportul nu mai funcționează și apar ferestre de eroare, atunci cel mai probabil problema poate fi rezolvată prin ștergerea memoriei cache. Vă vom spune cum.
Ce este memoria cache?
Programul 1C:Enterprise este creat în așa fel încât în timpul activității sale se străduiește constant să optimizeze viteza operațiunilor. În acest scop, pe computerul utilizatorului este creată o „cache”, care stochează informații frecvent utilizate, de exemplu: locația și forma ferestrelor, datele de serviciu pentru utilizator, setările de selecție, fonturile etc.
Memorarea în cache vă permite să reduceți numărul de apeluri către server și, prin urmare, . Acest mecanism economisește timp, dar conține și o serie de probleme.
Dacă, după actualizarea configurației, formularele dvs. plutesc, raportul nu mai funcționează și apar ferestre de eroare, atunci cel mai probabil problema poate fi rezolvată prin ștergerea memoriei cache.
Cum să ștergeți memoria cache?
Există două modalități principale de a șterge memoria cache.
1. Lansarea bazei de date 1C utilizând parametrul „/ClearCache”.
Această metodă este foarte simplă. În fereastra de selecție a bazei de informații, selectați-l pe cel al cărui cache doriți să îl ștergeți. Faceți clic pe butonul „Editați”.
În ultima fereastră Editare baze de date, setați parametrul de lansare „/ClearCache”. Faceți clic pe „Finalizare” și lansați baza de informații.
Ca rezultat al pașilor de mai sus, memoria cache a cererilor client-server va fi șters. Prin urmare, dacă problema a fost în memoria cache locală a metadatelor, atunci această metodă de ștergere a memoriei cache nu va funcționa. Când utilizați această metodă, este important să înțelegeți că folderul cu fișiere temporare va fi „deconectat” de la baza de informații, dar Nu va fi șters de pe computer.
2. Ștergerea cache-ului 1C manual
Pentru a șterge manual fișierele cache, trebuie să găsiți folderele în care este stocat memoria cache. Pentru sistemele de operare Win7 și versiuni ulterioare, fișierele temporare sunt stocate la:
- C:\Utilizatori\Nume utilizator\AppData\Roaming\1CŞi C:\Utilizatori\Nume utilizator\AppData\Local\1Cîn foldere care încep cu „1cv8”.
- În Windows XP, în folderul utilizatorului la Setări locale\Date aplicații\1C\.
- Dacă folderul AppData nu este vizibil, atunci trebuie să configurați vizibilitatea folderelor ascunse.
Figura de mai jos arată cum arată fișierele cache - foldere cu nume lungi și neclare. În cazul nostru, există un singur fișier.
Pentru a șterge memoria cache, trebuie să ștergeți aceste foldere.
Important! Puteți șterge foldere numai când procesele de lucru cu 1C:Enterprise sunt finalizate.
3. Ștergerea memoriei cache în 1C pe un server sau pe computerul utilizatorului folosind scripturi gata făcute
Pe Internet puteți găsi scripturi gata făcute pentru curățarea fișierelor temporare 1C. Utilizarea unor astfel de scripturi poate duce la consecințe imprevizibile, de aceea este recomandată numai administratorilor de sistem și personalului de suport tehnic.
Această metodă va ajuta la ștergerea cache-ului 1C atât pe client, cât și pe server. Pentru a face acest lucru, veți avea nevoie de acces la folderele de server corespunzătoare
4.Suplimentar
Dacă după folosirea metodelor de mai sus pentru a șterge memoria cache apare o eroare, de exemplu „ Format de stocare a datelor nevalid„, este încă salvat, se recomandă oprirea și curățarea manuală a folderului reg_1541/SNCCNTX. Este situat pe computerul serverului central 1C:Enterprise din director<рабочий каталог кластера> / <идентификатор информационной базы>.
De exemplu:
Fiți atenți, nu totul din acest folder poate fi curățat. Voi enumera ce poate fi curățat:
- 1CV8Reg.lst – registru de cluster (stochează o listă de baze de informații înregistrate, servere și procese de lucru, corespondența dintre cluster și managerul suplimentar și o listă de administratori.)
- srvribrg.lst – listă de clustere (clustere înregistrate și administratori centrali ai serverului)
- 1cv8ftxt – date de căutare text integral. Acestea se află pe serverul central 1c: directorul de lucru al clusterului - identificatorul bazei de informații
- 1Cv8Log – jurnal de înregistrare a bazei de date *.lgp și *.lgf.
Este important să rețineți că, după ștergerea memoriei cache, lansarea lui 1C va încetini puțin.
Fotografii, am aflat că memoria cache și memoria RAM joacă un rol cheie în scalabilitatea și performanța site-ului.
Site-ul poate stoca date pentru a accelera procesarea cererilor ulterioare la patru niveluri:
- client;
- reţea;
- server;
- nivelul de aplicare.
Diferitele pagini de pe un site web au adesea aceleași resurse. Utilizatorul trebuie să refolosească resursele în timpul navigării. Imaginile, scripturile și stilurile pot fi stocate în cache luni de zile, iar pagina documentului în sine poate fi stocată în cache pentru câteva minute în browserul clientului.
Cache la nivel de client
Antetele HTTP sunt responsabile pentru a determina dacă răspunsul poate fi stocat în cache și pentru a determina cât timp vor fi păstrate datele. Următorul exemplu de antet Cache-control specifică faptul că răspunsul poate fi stocat în cache timp de 7 zile. Browserul va retrimite cererea de stocare a datelor dacă perioada de stocare expiră sau utilizatorul reîmprospătează pagina în mod deliberat.
O solicitare și un răspuns care pot fi stocate în cache timp de 604800 de secunde.
Răspunsul poate include, de asemenea, un antet Last-Modified sau Etag. Aceste anteturi sunt necesare pentru a verifica dacă datele pot fi reutilizate. O stare de răspuns 304 indică faptul că conținutul nu s-a schimbat și nu este necesară o reîncărcare. Rețineți anteturile asociate Last-Modified și If-Modified-Since, precum și datele de mai jos:
Un răspuns cu un antet „Ultima modificare” urmat de o solicitare care îl folosește.
Antetul Etag este utilizat cu If-None-Match într-un mod similar pentru a schimba coduri de răspuns la detectarea modificărilor de conținut, dacă există.
Un site cu anteturi HTTP bine gândite va avea mai mult succes în rândul utilizatorilor. În plus, browserul va economisi timp și lățime de bandă.
Cache la nivel de rețea
Clienți care solicită același conținut de la serverul proxy.
Clienți multipli care solicită același conținut în același timp.
Acest mecanism simplu, dar puternic, evită aglomerația din partea aplicației atunci când există un număr mare de solicitări atunci când conținutul expiră.
Ideea din spatele acestei ultime, dar nu în ultimul rând, este că un server proxy poate îmbunătăți toleranța la erori a aplicației. Există indicatori de directivă proxy_cache_use_stale pentru livrarea conținutului expirat atunci când aplicația returnează o stare de eroare sau când comunicarea dintre serverul proxy și aplicație nu funcționează conform așteptărilor.
O altă considerație importantă atunci când utilizați depozitele cache este condiția de cursă care apare atunci când diferite instanțe ale unei aplicații accesează date necache în același timp. API-ul de stocare în cache a cererilor Rails include o proprietate race_condition_ttl pentru a minimiza acest efect.
Anticiparea condițiilor de cursă pentru cache-urile cu mai multe instanțe de aplicație este o provocare. Soluția optimă în acest caz este să actualizați datele din cache în afara firului de execuție al aplicației și să utilizați datele din cache în aplicația în sine. Într-o arhitectură de microservicii, puteți securiza comunicarea dintre aplicație și serviciu folosind nginx, așa cum este descris mai sus.
Concluzie
Sperăm că acest articol vă va ajuta să înțelegeți și să alegeți cea mai bună strategie pentru aplicația dvs. Antetele HTTP sunt cel mai simplu lucru pe care îl puteți și ar trebui să îl configurați pentru a optimiza stocarea în cache a aplicației dvs. Utilizați și alte strategii atunci când aveți anumite probleme de performanță, dar amintiți-vă că optimizarea prematură este rădăcina tuturor problemelor.
