Vahemälu mõistmine WordPressis, 3. osa
Eelmises kahes postituses olen rääkinud vahemällu salvestamise põhitõdedest ja sellest, kuidas vahemälu WordPressis töötab, vähemalt teatud määral.
Kuid pidage meeles, et selle sarja ajendiks oli meilisõnum, mille saatis keegi, kes arvas, et saaksin paremini selgitada, kuidas siirded ja vahemälu WordPressis töötavad ning miks on oluline mõista, kuidas kõik üksteisega paralleelselt toimib.
Selle postituse eesmärk on see kõik kokku viia ja rääkida sellest, kuidas Transients API töötab koos MySQL -iga, miks on oluline suhet mõista ja kuidas sellega edasi liikuda.
Kuidas siirded WordPressis töötavad?
Kuidas üleminekud töötavad
Esiteks, Codexi kohaselt töötavad siirded järgmiselt:
See leht sisaldab WordPress Transients API tehnilist dokumentatsiooni, mis pakub lihtsat ja standardiseeritud viisi vahemällu salvestatud andmete ajutiselt andmebaasi salvestamiseks, andes sellele kohandatud nime ja ajavahemiku, mille möödudes need aeguvad ja kustutatakse.
Idee selle taga tundub piisavalt lihtne, eks?
- Salvestate valiku andmebaasi,
- Määrake aeg, kui kaua see peaks eksisteerima,
- Seejärel hoitakse seda selle aja jooksul
- Ja kui seda taotletakse pärast aegumist, tuuakse see välja ja viiakse tagasi ajutisse olekusse.
Kus siis segadus peitub?
Nagu esimeses postituses mainitud, polnud mul selge, kui kaua mööduv teave saadaval on. Selle asemel, et olla minimaalne aeg, mille jooksul andmed on saadaval, on see maksimaalne.
See tähendab, et kui seate midagi päevaks saadaolevaks, on see ka päevaks saadaval. Mitte vähem; mitte rohkem. Ja pärast selle aja möödumist tuleb see taasluua mööduvasse olekusse.
Vähemalt on see tavapärane tarkus selle taga. See pole vale, kuid selles on midagi enamat. See on aga koht, kus see muutub natuke tehnilisemaks.
Millist rolli mängib MySQL?
WordPressi, hostimise ja muude tehnoloogiate arenedes on muutunud ka rakenduse aluseks olevad andmebaasid. See ei ole hea ega halb (kuigi võib-olla võime mõnes tulevases postituses väita, et see on hea).
Kuid see võib aidata selgitada, miks siirded töötavad nii, nagu nad töötavad, arvestades pinu, millega oleme harjunud töötama, ja kuidas need ei pruugi andmebaasisüsteemideta ootuspäraselt töötada.
Kui otsustate kasutada oma WordPressi installimiseks andmebaasina MySQL-i, mida ma julgen väita, et enamik inimesi ikka teeb, siis tabelis Options (siia on ka siirdeid salvestatud) olev teave töötab Transients API eespool kirjeldatud.
Mis saab aga siis, kui võtate kasutusele muud vahemällu salvestamise vormid, näiteks objektide vahemällu salvestamine tarkvara, nagu Memcached või Redis jne kaudu?
Sel juhul ei pruugi andmed ootuspäraselt saadaval olla. Lühidalt, vahemällu salvestav tarkvara võib loobuda teabest, mida ei nõuta nii sageli kui muud teavet. See tähendab, et see annab teatud prioriteedi teabele, mida sagedamini küsitakse.
Edasi liikuma
Kui võtate kõike ülaltoodut arvesse, vaatate mitut asja.
- Transients API,
- andmebaasi,
- kolmanda osapoole vahemälusüsteem.
Kui teil on Transients API ja standardandmebaas, on teil kõik korras, et asjad toimivad ootuspäraselt.
Kuid kui võtate kasutusele kolmanda osapoole vahemällu salvestamise süsteemi, võib tulemus olla erinev. Täpsemalt, asjad ei pruugi – ja tõenäoliselt ei tööta – nii, nagu ootad.
See tähendab, et kolmanda osapoole vahemällu salvestamise süsteem võib jätta tähelepanuta mis tahes teabe, mida ta soovib eemaldada, kui ta arvab, et see tuleb eemaldada. See tähendab, et kõike, mida arvate, et teil vahemälus saadaval võib olla, seal pole.
Lõppkokkuvõttes on parim nõuanne, mida ma saan anda:
- Kui kasutate MySQL-i ja Transients API-t, toimivad asjad Codexis kirjeldatud viisil.
- Teisest küljest, kui kasutate mõnda muud vahemällu salvestamise süsteemi, on oluline mõista, kuidas see töötab ja kuidas saate selle vastu koodi kirjutada, et see töötaks nii, nagu soovite.
Ja sellega pole sellele praimerile enam midagi lisada, et mõista WordPressi vahemällu salvestamist.