Vahemälu mõistmine WordPressis, 1. osa
Maikuus kirjutasin artikli WordPress Transients API kasutamise kohta. Võtan artikli kokku järgmiselt:
Küpsiste ja nende aegumise funktsiooni simuleerimiseks võib WordPressi transientide kasutamine olla elujõuline lahendus.
https://wordpress.mediadoma.com/et/kas-kasutate-kuepsiste-asemel-wordpressi-siirdeid/
Kuigi artikli eesmärk oli panna alus sellele, kuidas saaksime kujundada klassi, mis töötaks koos Transients API-ga, et simuleerida küpsiste käitumist, on artikli üks kõrvalmõjudest see, et see ei teinud head tööd. selgitades, kuidas Transients API (ja puhverserveri kaudu ka MySQL) töötab.
David juhtis sellele e-posti teel tähelepanu UpDraft Plusis.
Seega pidasin kasulikuks rääkida vahemällu salvestamise kontseptsioonist praktilisel tasandil, kuidas seda WordPressis rakendatakse, ja siis võib-olla vaadata, kuidas kasutada pistikprogramme või uuemat tehnoloogiat, et oma saite ja rakendusi paremini toita ning paremini mõista.
Vahemällu salvestamise mõistmine: põhitõed
Vahemällu salvestamise kontseptsioon on suhteliselt lihtne. Kuid ma arvan, et seda näitab kõige paremini see, kui räägime kõigepealt andmete serialiseerimisest ja otsimisest ilma vahemällu salvestamata.
Ilma vahemäluta
Andmete kirjutamine
Kui kirjutate teavet aluseks olevasse andmebaasi, salvestate andmebaasi kirje või kirjete seeria.
Näiteks kui avaldate postituse, kirjutate postituste tabelisse kirje ja postituste metaandmete tabelisse, millest igaüks on seotud postituse ID-ga.
See, kuidas need on seotud, pole selle postituse jaoks oluline.
Selle asemel tuleb selles osas aru saada, et andmete andmebaasi kirjutamisel luuakse vähemalt üks kirje, kui mitte mitu.
Andmete lugemine
Kui külastaja jõuab saidile seda konkreetset postitust lugema, päritakse kogu selle postituse teave andmebaasist, edastatakse see WordPressi rakendusele ja renderdatakse seejärel esiotsas.
Mõelge kogu sellele protsessile kui reisile:
- ❓külastaja küsib lehte,
- 🔍 veebiserver tuvastas, millist lehekülge laadida,
- 📂 lehekülge küsitakse andmebaasist mitmest tabelist,
- 🏗 andmed koondatakse ja saadetakse põhirakendusse,
- 🖥 Andmed esitatakse kasutajale.
Seega algab reis siis, kui kasutaja taotleb lehte, ja lõpeb siis, kui teave talle brauseris esitatakse.
See on Reis
Ja ilma vahemällu salvestamiseta juhtub seda iga kasutajaga. See tähendab, et iga teie saiti külastava kasutaja jaoks tuleb teha reis.
See võib olla ressursi ja aja osas väga kulukas (eriti sõltuvalt teie andmebaasi suurusest).
Kuid siin võib mängu tulla vahemälu.
Enne vahemällu salvestamist
Vahemällu salvestamise idee on muuta kogu see protsess kiiremaks. See tähendab, et kui me teame, et reis on peagi toimumas, saame hoida teavet kohas, kus see on juba kokku pandud ja kiiremini kätte saadav.
Enne kui räägin sellest, mida ma järgmises postituses räägin, pange tähele, et see on nagu teekond selle serveri kõvakettale, kus saiti majutatakse iga kord, kui seda saiti külastatakse.
Sest lõppkokkuvõttes asuvad andmebaas, failid ja kõik saidi toiteks vajalikud varad kõvakettal. Ja jah, sellised asjad nagu pooljuhtdraivid võivad selle protsessi kiirendada, kuid see pole ikkagi nii optimaalne kui võimalik.
Ja siin tulebki pilti vahemällu salvestamine. Transients API paremaks mõistmiseks on oluline mõista vahemällu salvestamist, mis eeldab esmalt põhiteadmist, kuidas asjad ilma vahemäluta toimivad.
See on praimer
Nii et pidage seda põhiaabitsaks selle kohta, kuidas andmebaasi toega sait ilma vahemällu salvestamata töötab. Ja siis jätkame sellest järgmises postituses rohkem.