Kešēšanas hierarhijas: opkods, lapa, pārlūks un malas - visu līmeņu efektīva izmantošana optimālai veiktspējai.

Kešēšanas hierarhijas nodrošina visātrāko ielādes laiku, ja izmantoju katru slāni atsevišķi: opkods, lapa, pārlūks un edge. Skaidros soļos parādīšu, kā apvienoju šos slāņus, izvairos no konfliktiem un iestatu konfigurācijas tā, lai pieprasījumi būtu īsāki un TTFB būtu redzami mazāks.

Centrālie punkti

Lai nodrošinātu, ka pārskats ir skaidrs, vispirms apkopoju galvenos tematus un tiešā veidā saskaņoju tos ar darbības mērķiem. Paskaidroju visus līmeņus ar konkrētiem iestatījumiem, lai īstenošana noritētu veiksmīgi, bez apvedceļiem. Skaidri norobežoju dinamiskās daļas, lai saglabātu personalizāciju. Optimizēju galvenes un kešatmiņas atslēgas, lai kešatmiņā nebūtu nevajadzīgu atkritumu. Visbeidzot, es visu apvienoju stingrā ķēdē, lai katra atgūšana notiktu visātrākajā ceļā.

• Opkods paātrina PHP
• Lapas kešatmiņa saīsināts TTFB
• Pārlūka Ietaupa joslas platumu
• Edge Samazina latentumu
• Orķestrēšana Novērš konfliktus

Ko patiesībā nozīmē „kešēšanas hierarhijas“?

Es saprotu, ka Hierarhija pakāpeniska kešatmiņas izveide no servera kodola uz galīgo ierīci. Katrs slānis atbild uz atšķirīgu jautājumu: vai serverim ir jāpārkompilē kods, vai PHP ir jāpārpublicē lapa, vai pārlūkprogrammai ir jāpārlādē resursi, vai arī galējais mezgls piegādā gatavu saturu lietotāja tuvumā. Es izvairos no darba dublēšanās, saskaņojot līmeņus un nosakot skaidrus pienākumus. Šādā veidā es samazinu procesora slodzi, aizmugurējos pieprasījumus un tīkla aizkavēšanos, nezaudējot funkcionalitāti. Īsu ievadu par līmeņiem varu atrast šajā kompaktajā rokasgrāmatā: Vienkārši kešatmiņas līmeņi.

Opcode caching: tūlītēja PHP paātrināšana

vietnē Opkods-caching, es saglabāju sastādītu PHP bajtkods RAM un ietaupīt sevi atkārtotu parsēšanu. Tas paātrina visus pieprasījumus, kas saistīti ar PHP, jo īpaši tādas CMS slodzes kā WordPress. Es ieslēdzu OPcache un pietiekami dāsni dimensionēju atmiņu, lai bieži lietojamie skripti nekad netiktu izspiesti. Es iestatu mērenu atkārtotu apstiprināšanu, lai izmaiņas būtu redzamas nekavējoties, nepārbaudot pārāk bieži. Šādā veidā es ievērojami samazinu gan procesora slodzi, gan atbildes laiku.

Es apzināti iestatīju tipiskus OPcache parametrus php.ini konservatīvi, uzraugu trāpījumu skaitu un pēc vajadzības koriģēju. Paātrināto failu skaits ir pietiekami liels, lai projekts pilnībā ietilptu. Centrālajām klasēm izmantoju iepriekšēju ielādi, lai pat aukstā palaišana darbotos ātrāk. Izvietoju izmaiņas ar kešatmiņas atiestatīšanu, lai izvairītos no nekonsekventu stāvokļu riska. Es izmantoju konfigurācijas bloku kā sākumpunktu, nevis kā stingru dogmu.

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

Es regulāri pārbaudu OPcache-statistika, jo tikai mērījumi parāda, vai kešatmiņa ir gultnis vai thrash't. Uzņemšanas paneļi vai PHP statusa lapas palīdz man samazināt iztrūkumu skaitu. Es izvairos no pārāk mazām atmiņas vērtībām, kas izraisa evikcijas. Es arī izvairos no retām validācijām, lai produktīvas izmaiņas neaizķertos. Izmantojot šo līdzsvaru, es strādāju efektīvi un droši.

Lapas kešēšana: HTML bez gaidīšanas laika

vietnē Lapas kešatmiņa Es saglabāju gatavo HTML, lai PHP un datubāze vairs netiktu darbināta. Tas krasi samazina TTFB un rada lielākos lēcienus zem slodzes. Es konsekventi izslēdzu personalizētos ceļus, piemēram, iepirkumu grozu, kases un lietotāju kontus. Tajā pašā laikā es iekapsulēju nelielas dinamiskās daļas, izmantojot AJAX vai edge-side includes, lai pārējo varētu grūti iegūt no kešatmiņas. Tādējādi vietne ir ātra, nezaudējot svarīgu individualitāti.

Es izlemju, vai izmantot servera līmeņa kešatmiņu vai strādāt ar spraudni. Uz servera es panāku vislabāko Kavēšanās laiks, Spraudņi man nodrošina elastīgu CMS kontroli. Iepriekšējas ielādes mehānismi iepriekš piepilda kešatmiņu, lai sākotnējie izsaukumi nebūtu jāgaida. Atjauninot saturu, es iztīros pamestos ierakstus, izmantojot attīrīšanas noteikumus. Īpaši dārgām jomām apvienoju arī objektu kešatmiņu, lai piekļuve datubāzei būtu retāka.

Pārlūkprogrammas kešatmiņa: saglabāt vietējos aktīvus

vietnē Pārlūka-Tādus statiskus failus kā attēlus, CSS un JS atstāju lokālajā kešatmiņā. Atgriezušies apmeklētāji tad gandrīz neko neuzlādē, un serveris paliek brīvs. Nemaināmiem aktīviem es nosaku garas maksimālās darbības laika vērtības, ko nodrošinu ar failu nosaukumu versiju noteikšanu. Dinamiskajiem galapunktiem pievienoju īsus laikus vai must-revalidate, lai nodrošinātu lietotnes atjaunināšanu. Šādā veidā samazinu joslas platumu un optimizēju uztveramo ātrumu.

Es pievēršu uzmanību kešatmiņas kontroles, ETag un pēdējās modificētās kombinācijai. Nemaināmiem failiem iestatu nemainīgu, lai pārlūkprogramma lieki nepārbaudītu. Resursiem ar biežiem atjauninājumiem izmantoju nosacītus pieprasījumus, izmantojot ETag. Izvairos no neviennozīmīgām galvenēm, jo pretrunīgi signāli rada pārpratumus. Atkarībā no vides es kontrolēju tieši tīmekļa serverī vai izmantojot CMS spraudni.

Krasta kešatmiņa: lietotāja tuvums

Par Edge-tīklus, es piegādāju saturu globālajos PoP, kas samazina latentumu un izlīdzina maksimumu. HTML, attēlus un API atkarībā no noteikumu kopuma var piegādāt lietotājam tuvāk. Es strādāju ar kešatmiņas atslēgām, kas satur tikai nepieciešamos mainīgos, lai samazinātu fragmentāciju. Tādi noteikumi kā "stale-while-revalidate" un "stale-if-error" nodrošina, ka lietotāji nekavējoties redz derīgu kopiju pat tad, ja Origin tikai uzsilda. Īpašs ieguvums ir starptautiskajām mērķgrupām, jo maršrutēšanas laiks ir ievērojami samazināts.

Es atdalīju variantus, ja mobilais un darbvirsmas dators ir ļoti atšķirīgi. Es apzināti atstāju malā izrakstīšanās un konta zonu, lai izvairītos no sadursmēm ar sesijām un sīkfailiem. Regulāri pārbaudu trāpījumu skaitu un koriģēju TTL, līdz tiek sasniegtas optimālas izredzes. Praktisks padziļināts ieskats Krasta kešatmiņas ceļvedis īpašu uzmanību pievēršot latencei un tīkla ceļiem. Man ir pa rokai tīras attīrīšanas stratēģijas, lai atjauninājumi nekavējoties stātos spēkā visā pasaulē.

Pareizi iestatiet HTTP galveni

Portāls Virsraksts kontrolēt, cik tālu drīkst pārvietoties saturs un kad tas tiek atkārtoti apstiprināts. Es izmantoju kešatmiņas kontroli, lai noteiktu redzamību, darbības ilgumu un atkārtotas apstiprināšanas pienākumus. ETag unikāli identificē resursu un ļauj veikt pieprasījumus, ja nav atbilstības. Last-Modified nodrošina rezerves risinājumu klientiem, kas ignorē ETag. Kombinācija ir skaidra, lai klientam, CDN un izcelsmes vietnei būtu vienādas gaidas.

Konfigurēšanas laikā es izmantoju šo pārskatu kā praktisku atsauci. Es pārbaudu katru rindu, salīdzinot ar resursa veidu un izmaiņu uzvedību. Statiskiem failiem es iestatu garas maksimālās ilguma vērtības ar nemainīgu. Bieži atjauninātam saturam samazinu ilgumu un paļaujos uz nosacītiem pieprasījumiem. Tādējādi datu ceļš ir efektīvs un pareizs.

Virsraksts	Funkcija
Kešatmiņas kontrole	Kontrolē ilgumu, redzamību, atkārtotu apstiprināšanu (piemēram, max-age, public, must-revalidate).
ETag	Versijas unikālais identifikators, nosacīto izsaukumu pamats.
Pēdējo reizi rediģēts	Laika zīmogs kā alternatīva ETag, ko izmanto validācijai

Kešatmiņas anulēšanas un svaiguma stratēģijas

Es plānoju Invalidācija tikpat rūpīgi kā pati kešatmiņa. Selektīvā tīrīšana pēc ID, tagiem vai ceļiem novērš pilnīgu izskalošanu, kas rada izmaksas. Izvietošanas laikā es attīru tikai to, kas patiešām ir mainījies. Stale-while-revalidate saglabā lietotājus ātrus, kamēr fonā tiek ielādētas svaigas kopijas. Stale-if-error novērš kļūdas Origin sistēmā, nepazeminot lietotāju pieredzi.

Es apvienoju īsu TTL ar augstu trāpījuma koeficientu, ja saturs bieži rotē. Arhīviem, multivides materiāliem un bibliotēkām es izvēlos garus laikus, versiju failu nosaukumus un noņemu pārbaudes ielādes. Informācijas paneļi CDN vai servera pusē man parāda, kur kešatmiņas spaiņi ir pārāk mazi. Tad es koriģēju slotu skaitu un objektu izmērus. Šī pastāvīgā regulēšana ikdienā ir ļoti noderīga.

Kešatmiņas atslēgas, sīkfaili un Vari

Ar plānu Atslēgas Es saglabāju nelielu variantu skaitu. Atslēgā tiek iekļauti tikai tie parametri, kas patiešām maina rezultātu. Vary galvenes izmantoju apzināti, piemēram, pēc Accept-Encoding vai User-Agent klasēm, ja nepieciešams. Pārāk daudz sīkfailu atslēgā izjauc kešatmiņu un samazina trāpījumu skaitu. Es attīru no atslēgas neizmantotās sīkdatnes un regulēju parametrus, kas tiek izmantoti izsekošanai.

Ja man ir jāmaina valodas, valūtas vai izkārtojumi, es izmantoju īpašas atslēgas, piemēram, lang=de vai currency=EUR. Es ierobežoju šo dažādību līdz gadījumiem, kas man patiešām ir nepieciešami. A/B testiem es nodalu tikai tos segmentus, kuru saturs atšķiras. Visu pārējo pārvaldu klienta pusē vai izmantojot edge loģiku bez atslēgu eksplozijas. Šādā veidā globālā kešatmiņa ir efektīva.

Objektu kešatmiņa un pārejošie procesi

An Objekts-Cache samazina dārgu datu bāzes pieprasījumu skaitu, saglabājot rezultātus atmiņā. WordPress gadījumā es izvēlos Redis vai Memcached, lai nodrošinātu ātru piekļuvi bieži pieprasītajām opcijām, pieprasījumiem un sesijām. Dārgu aprēķinu īslaicīgai glabāšanai izmantoju pārejas režīmus. Izvietošanas laikā, kad mainās atkarības, es iztīros šīs vērtības. Tas nodrošina lapas dinamiskumu un joprojām ir ātra.

Šis salīdzinājums man palīdz projektu lielumiem ar intensīvām datu slodzēm: Redis pret Memcached. Tur es atpazīstu abu sistēmu tipiskās stiprās puses atkarībā no darba slodzes. Es izmēroju operatīvo atmiņu un pārbaudīju izlikšanas stratēģijas, lai atbrīvotu vietu reti izmantotiem objektiem. Uzraugot trāpījumu/trūkumu rādītājus, redzu, vai konfigurācija darbojas. Šis līmenis ideāli papildina lapu kešatmiņu.

Kombinācija: optimizētā ķēde

Es apvienoju Līmeņi lai katrs pieprasījums veiktu īsāko ceļu. OPcache paātrina ģenerēšanu, kad HTML tiek faktiski izveidots. Lapas kešatmiņa nodrošina gatavu iezīmēšanu anonīmiem apmeklētājiem. Pārlūkprogrammas kešatmiņa novērš atkārtotu aktīvu pārsūtīšanu, un Edge globāli izplata saturu. Pašā beigās ir tīra attīrīšanas un versiju veidošanas stratēģija, lai atjauninājumi stātos spēkā nekavējoties.

Kad mainu iestatījumus, man kā palīglente ir šāda tabula. Īstenošanas laikā slejā „Konfigurācija“ es lasu kā darāmo darbu sarakstu. Pārliecinos, ka līmeņi viens otru papildina un viens otru neizslēdz. Tādējādi kopējā arhitektūra ir skaidra un efektīva. Šis pārskats novērš kļūdas plānošanas laikā.

Kešatmiņas līmenis	Priekšrocība	Tipisks saturs	Konfigurācija
Opkods	Ātra PHP izpilde	PHP baitkods	php.ini, Servera panelis
Lapa	Zems TTFB	Pabeigts HTML	Servera līmenis vai spraudnis
Pārlūka	Vietējā atkārtota izmantošana	CSS, JS, attēli	HTTP galvene, versiju veidošana
Edge	Globālais tuvums	HTML un aktīvi	CDN noteikumi, Atslēgas, Tīrīšana

Mērījumi: TTFB, LCP un trāpījumu rādītāji

Es mēru TTFB, lai redzētu, cik ātri pienāk pirmais baits. LCP parāda, vai redzamais saturs parādās laikus. Es izmantoju kešatmiņas analītiku, lai pārbaudītu trāpījumu rādītājus un atpazītu maršrutus, kuros uzkrājas iztrūkumi. Es saistu rādītājus ar izvietojumiem, pārlūkošanas slodzi un datplūsmas maksimumiem. Tikai skaitļi parāda, kur man ir jāpastiprina skrūves.

Es reģistrēju atbildes galvenes, piemēram, Age un CF kešatmiņas statusu, lai vizualizētu malu panākumus. Servera žurnāli parāda, vai lapas kešatmiņa darbojas pareizi. Ja ir lielas novirzes, es meklēju sīkfailus, vaicājuma parametrus vai mainīgos, kas sadala kešatmiņu. Testēju variantus ar un bez pierakstīšanās stāvokļa. Šādā veidā es varu ātri atrast korekcijas stabila ātruma nodrošināšanai.

Tipiskas kļūdas un labojumi

Pārāk daudz Varianti kešatmiņā ir biežs bremzēšanas traucēklis. Es samazinu vaicājuma parametrus atslēgā un neitralizēju izsekošanas parametrus. Vēl viens klasisks gadījums ir pretrunīgas galvenes, piemēram, aizliegums glabāt kopā ar garu maksimālo ilgumu. Arī tukšas vai nepareizas tīrīšanas var radīt iespaidu, ka kešatmiņa nedarbojas. Es ātri atrisinu šādas problēmas ar skaidriem noteikumiem un žurnāliem.

Vēl viena problēma ir spraudņi, kas HTML formātā ieraksta grūti kodētu dinamisku saturu. Šādus elementus es pārvietoju uz sadrumstalotiem galapunktiem, kas atrodas kešatmiņā vai tiek ielādēti neatkarīgi. Sīkfaili bieži netīši bloķē malas kešatmiņu; es agrīni dzēšu nevajadzīgos sīkfailus. Slikts versiju sadalījums liek pārlūkprogrammām atkal un atkal pārlādēties; es konsekventi numurēju failus. Tas nodrošina cauruļvada tīrību un elastību.

Lēmumu koks: Kas atbild uz pieprasījumu?

Es definēju skaidru lēmumu pieņemšanas ceļu, lai noteiktu, kurā līmenī ir atļauts veikt piegādi. Tas ļauj izvairīties no nevajadzīgiem avotu triecieniem un reproducējami samazina TTFB.

• 1) Vai resurss ir nemainīgs (datne ar versiju)? Pārlūka kešatmiņa ar ilgu maksimālo ilgumu un nemainīgs.
• 2) Vai pieprasījums ir anonīms, GET un bez sensitīviem sīkfailiem? Edge/lapas kešatmiņa ar public, s-maxage un stale-while-revalidate.
• 3) Vai pieprasījumā ir Auth-Cookies, Authorisation-Header vai POST? Origin, pēc izvēles ar Object-Cache.
• 4) Vai URL satur tikai kosmētikas parametrus (utm, fbclid)? Es tos noņemu no kešatmiņas atslēgas.
• 5) Vai jums ir nepieciešamas nelielas dzīvās daļas (piemēram, iepirkumu grozu skaits)? Sadalīts, izmantojot AJAX vai ESI.

// pseido loģika
if (immutable_asset) return browser_cache;
if (is_get && is_anonymous && cacheable) return edge_or_page_cache;
if (needs_fragment) return cached_html + dynamic_fragment;
return origin_with_object_cache;

Fragmentācijas pārvaldība: ESI, AJAX un daļēja atveidošana

Es izolēju dinamiskās salas, lai pārējie varētu cache grūti. ESI ir piemērots servera puses injekcijām (piemēram, personalizētiem blokiem), AJAX - klienta puses pārlādes punktiem. Ir svarīgi, lai fragmenti saņemtu savus, īsus TTL, lai tie paliktu aktuāli, neizjaucot visa dokumenta derīgumu.

• Statiskā pamatstruktūra: long TTL, public, s-maxage, stale-while-revalidate.
• Dinamiskais fragments: īss TTL, must-revalidate vai no-store, ja ir personalizēts.
• Kļūdu gadījums: stale-if-error HTML ietvarā novērš baltās lapas.

// HTML aploksnes galvenes piemērs
Cache-Control: public, max-age=0, s-maxage=600, stale-while-revalidate=60, stale-if-error=86400

// Personīgā fragmenta galvenes piemērs
Cache-Control: private, no-store

Izvairieties no kešatmiņas uzpludināšanas un kontrolējiet iesildīšanos

Es novēršu ganāmpulka efektu, kad daudzi vienlaicīgi garāmgājēji pārpludina Izcelsmi. Mani instrumenti ir mīkstais TTL/cietais TTL, pieprasījumu apvienošana un bloķēšana. Es izmantoju priekšlādētājus, kas cikliski uzsilda vietņu kartes vai svarīgus ceļus un izkārto TTL, lai viss neizbeigtos vienlaicīgi.

• Soft TTL: darbinieks var atjaunot objektus, kuru derīguma termiņš ir beidzies, kamēr citi patērētāji joprojām saņem novecojušus objektus.
• Vienlaicīgu vienas un tās pašas atslēgas pieprasījumu apvienošana.
• Pakāpeniski TTL: Lai izlīdzinātu attīrīšanas viļņus, kritiskajām lapām tiek piešķirts dalīts izpildes laiks.

// Pakāpenisku izpildes laiku piemērs
/home, /category/* -> s-maxage=900
/article/* -> s-maxage=1800
/search -> s-maxage=120, stale-while-revalidate=30

TTL konstrukcijas tīra izlīdzināšana ķēdē

Es noregulēju pārlūkprogrammas, edge un izcelsmes TTL, lai atkārtota validācija notiktu tur, kur tas ir visizdevīgāk. Attiecībā uz HTML es paļaujos uz s-maxage malā un uzturu zemu max-age pārlūkprogrammā, lai garantētu ātru attīrīšanu. Attiecībā uz aktīviem es to apgriežu otrādi: pārlūkprogrammas TTL ir ļoti ilgi, jo versiju noteikšana nodrošina atjaunināšanu.

// HTML
Cache-Control: public, max-age=0, s-maxage=600, stale-while-revalidate=60

// Versionētie aktīvi
Cache-Control: public, max-age=31536000, immutable

Es izvairos no pretrunīgām specifikācijām, piemēram, no-cache kopā ar immutable. Skaidri noteikumi rada konsekventus rezultātus visā hierarhijā.

Kompresija, HTTP/2/3 un prioritāšu noteikšana

Es aktivizēju Gzip/Brotli un pareizi iestatīju Vary galveni, lai varianti būtu skaidri nodalīti. Izmantojot HTTP/2/3, es gūstu labumu no multipleksēšanas un prioritāšu noteikšanas; tas samazina bloķēšanu, kad paralēli tiek ielādēti daudzi resursi.

# NGINX piemērs
gzip ieslēgts;
gzip_types text/css application/javascript application/json image/svg+xml;
brotli on;
brotli_types text/css application/javascript application/json image/svg+xml;
add_header Vary "Accept-Encoding" vienmēr;

# Ilgs pārlūkprogrammas TTL aktīviem
location ~* .(css|js|svg|woff2|jpg|png)$ { {
  expires 1y;
  add_header Cache-Control "public, max-age=31536000, immutable";
}

Autentifikācija, sīkfaili un drošība

Es nekad publiski neizmantoju personisko saturu kešatmiņā. Es atzīmēju pieprasījumus ar autorizācijas galvenēm vai sesijas sīkfailiem kā privātus vai īpaši apeju edge kešatmiņu. Tajā pašā laikā es iekļauju tikai svarīgākās sīkdatnes baltajā sarakstā, lai kešatmiņas atslēga paliktu liesa.

• Pieslēgšanās/konta jomas: Kešatmiņas kontrole: privāta vai bez glabāšanas.
• Publiskās HTML lapas: publiskas, s-maxage; izvairīties no sīkfailu iestatīšanas.
• Sīkfailu higiēna: no atslēgas noņemiet nebūtiskus sīkfailus (piemēram, izsekošanas).

// VCL līdzīga loģika
if (req.http.Authorisation) { return(pass); }
if (req.http.Cookie ~ "session=") { return(pass); }
// Atslēgā ir tikai nepieciešamās sīkdatnes
unset req.http.Cookie: ".*";

Efektīvi kešēt API un meklēšanas galapunktus

Es stingri nošķīru metodes: GET var būt kešatmiņā, POST parasti ne. Biežiem meklēšanas pieprasījumiem es iestatu īsas s-maxage vērtības un stale-while-revalidate, lai izlīdzinātu atbildes laiku. Atbildes ar 4xx/5xx kļūdām kešēju tikai īsu brīdi vai vispār neveicu, lai labojumi stātos spēkā nekavējoties.

// Publiskā GET API galvenes piemērs
Cache-Control: public, max-age=0, s-maxage=120, stale-while-revalidate=30

// Kļūdas kešatmiņā reti
Cache-Control: public, s-maxage=10

Novērojamība: galvenes, žurnāli un TTFB pārbaude

Es izmantoju galvenes pārbaudi un žurnālus, lai padarītu ķēdi pārredzamu. Vecums, trāpījumu/trūkumu rādītāji un augšupejošais statuss man parāda, kur tiek zaudēts laiks. Es izmantoju vienkāršus rīkus, lai atkārtoti pārbaudītu TTFB un atrastu novirzes.

Pasākums # TTFB
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}sn" https://example.org

Pārbaudīt # galveni
curl -I https://example.org | sed -n '1,20p'

# NGINX žurnāls ar kešatmiņas statusu
log_format timed '$remote_addr "$request" $status $body_bytes_sent '
                 '$upstream_cache_status $upstream_response_time $request_time';
access_log /var/log/nginx/access.log timed;

Es salīdzinu žurnāla datus ar izvietojumiem un tīrīšanām. Augsti iztrūkumu pīķi tieši pēc izvēršanas norāda uz trūkstošu iesildīšanos vai pārāk īsiem TTL. Ja Age paliek pastāvīgi zems, pārbaudu, vai sīkfaili netīši neapiet edge kešatmiņu.

Izvietošana: versiju veidošana un mainīga tīrīšana

Es iebūvēju versijas failu nosaukumos (piemēram, app.9f3c1.js), lai pārlūkprogrammas kešēšana būtu agresīva. Attiecībā uz HTML es izmantoju slīdošo tīrīšanu, kas vispirms atjaunina kritiskās lapas, pēc tam - dziļās un garās lapas. Zilās/zaļās izvietošanas atvieno izveidi no izlaišanas un dod man laiku, lai īpaši uzsildītu kešatmiņas.

// Aktīvu cauruļvads
style.[hash].css
app.[hash].js
// HTML vienmēr atsaucas uz jauniem hash

Es plānoju tīrīšanas logus ārpus pīķa laikiem un uzreiz pēc tam uzraugu trāpījumu skaitu. Šādā veidā izvairos no slodzes maksimumiem Oriģinālajā datubāzē.

Attēlu varianti, DPR un responsīvā kešatmiņa

Attēlu variantus (izmērs, formāts) ģenerēju deterministiski, lai kešatmiņas atslēga būtu stabila. WebP/AVIF variantus es skaidri nodalu, izmantojot faila ceļu vai parametrus, nevis tikai Accept galvenes, lai izvairītos no Vary eksplozijām. Augstas izšķirtspējas displejiem (DPR) es izmantoju srcset/sizes, kas ļauj pārlūkprogrammai izvēlēties labāko variantu un kešatmiņu, kas stājas spēkā katram konkrētajam aktīvam.

<img src="img/hero-1024.jpg"
     srcset="img/hero-768.jpg 768w, img/hero-1024.jpg 1024w, img/hero-1600.jpg 1600w"
     sizes="(max-width: 768px) 90vw, 1024px" alt="">

Lai kešatmiņa netiktu sadrumstalota, es saglabāju nelielu variantu skaitu vienam motīvam un izdzēšu novecojušos izmērus no konveijera.

Jaudas plānošana: kešatmiņa un objektu izmēri

Kešatmiņas lielumu nosaka pēc reālajiem piekļuves modeļiem: dažiem lieliem objektiem (attēliem, videoklipiem) nepieciešamas atšķirīgas stratēģijas nekā daudziem maziem (HTML, JSON). Es nosaku ierobežojumus maksimālajam objektu lielumam un pārbaudu, vai populāri objekti paliek atmiņā. Augsts atkārtotas izmantošanas rādītājs ir svarīgāks par absolūto lielumu; tāpēc es apgriežu atslēgas, apvienoju variantus un novēršu dublēšanos.

// Piemērs: Limits
max_object_size = 10m
noklusējuma_ttl = 600
nuke_limit = mērens (izlikšana bez apstāšanās)

Īstenošanas praktiskais kontrolsaraksts

Es aktivizēju OPcache ar pietiekamu atmiņu un pārbaudiet trāpījumu skaitu. Pēc tam iestatu lapu kešēšanu, izslēdzu kritiskos ceļus un iepriekš ielādēju svarīgus URL. Pēc tam iestatu pārlūkprogrammas galvenes ar ilgu laiku nemaināmiem failiem un versiju veidošanu. CDN definēju kešatmiņas atslēgas, TTL un attīrīšanas stratēģijas un aktivizēju stale-while-revalidate. Visbeidzot, es izmantoju mērīšanas rīkus, lai pārbaudītu, vai TTFB, LCP un edge hit rate sasniedz mērķus.

Īss kopsavilkums

Es izmantoju Kešatmiņa hierarhiska: OPcache paātrina kodu, lapas kešatmiņa nodrošina HTML, pārlūkprogrammas galvenes saglabā vietējos resursus, bet Edge saturu pietuvina lietotājiem. Izmantojot skaidras atslēgas, piemērotus TTL un gudru anulēšanu, es samazinu servera slodzi, joslas platumu un latentumu. Izmērītās vērtības nodrošina progresu un parāda optimizācijas potenciālu. Tādējādi tiek izveidota uzticama ķēde no izcelsmes līdz gala ierīcei. Ikviens, kas meklē papildu informāciju par globālo piegādi, praksē atradīs pietiekami daudz izejas punktu, lai padarītu savu arhitektūru ievērojami ātrāku.