Förstå cachelagring i WordPress, del 3
I de två tidigare inläggen har jag pratat om grunderna i cachning och hur cachning fungerar i WordPress, åtminstone till en viss grad.
Men kom ihåg att den här serien motiverades av ett mejl från någon som tyckte att jag kunde göra ett bättre jobb med att förklara hur transienter och cachning fungerar i WordPress och varför det är viktigt att förstå hur allt fungerar tillsammans med varandra.
Så i det här inlägget siktar jag på att få ihop allt och prata om hur Transients API fungerar tillsammans med MySQL, varför det är viktigt att förstå relationen och hur man hanterar detta framåt.
Hur fungerar transienter i WordPress?
Hur transienter fungerar
För det första, enligt Codex, fungerar transienter så här:
Den här sidan innehåller den tekniska dokumentationen för WordPress Transients API, som erbjuder ett enkelt och standardiserat sätt att lagra cachad data i databasen tillfälligt genom att ge den ett anpassat namn och en tidsram efter vilken den kommer att löpa ut och raderas.
Tanken bakom detta verkar enkel nog, eller hur?
- Du sparar ett alternativ i databasen,
- Ställ in en tid för hur länge den ska finnas,
- Sedan lagras det så länge
- Och, om efterfrågad efter utgången, hämtas och flyttas tillbaka till sitt övergående tillstånd.
Så var ligger förvirringen?
Som nämndes i det första inlägget var jag inte klar över hur länge den övergående informationen skulle vara tillgänglig. Istället för att vara ett minimum av tid som data kommer att vara tillgänglig, är det ett maximum.
Det betyder att om du ställer in något att vara tillgängligt för en dag, kommer det att vara tillgängligt för en dag. Inget mindre; inte mer. Och efter att den tiden har gått ut måste den återskapas till det transienta tillståndet igen.
Åtminstone är detta den konventionella visdomen bakom. Det är inte fel men det ligger mer i det. Det är här det blir lite mer tekniskt.
Vilken roll spelar MySQL?
I takt med att WordPress, hosting och andra teknologier har mognat har de underliggande databaserna som driver applikationen också förändrats. Det här är inte bra eller dåligt (även om vi kanske skulle kunna hävda att det är bra i ett framtida inlägg).
Men det kan hjälpa till att förklara varför transienter fungerar som de gör med tanke på den stack som vi är vana vid att arbeta med och hur de kanske inte fungerar som förväntat utan databassystem.
Om du väljer att använda MySQL som databas för din WordPress-installation, vilket jag vågar säga att de flesta fortfarande gör, då kommer informationen som finns i Options-tabellen (som också är där transienter lagras) så kommer Transients API att fungera som som beskrivs ovan.
Men vad händer när du introducerar andra former av cachning som objektcache genom programvara som Memcached eller Redis och så vidare?
I så fall kanske uppgifterna inte är tillgängliga som du förväntar dig. Kort sagt kan cachningsmjukvaran välja att släppa information som inte efterfrågas lika ofta som annan information. Det vill säga, det ger en prioritetsnivå åt information som efterfrågas oftare.
Går vidare
När du tar hänsyn till allt ovanstående tittar du på flera saker:
- Transients API,
- en databas,
- ett cachingsystem från tredje part.
När du har Transients API och en standarddatabas, kommer du att klara dig i och med att saker och ting kommer att fungera som du förväntar dig.
Men om du introducerar ett cachingsystem från tredje part kan resultatet bli annorlunda. Specifikt kanske saker och ting inte – och kommer troligen inte – att fungera på det sätt du förväntar dig.
Det vill säga, tredje parts cachningssystem kan bortse från all information som det vill släppa när det tror att det behöver ta bort det. Det betyder att allt du tror att du kan ha tillgängligt i cachen inte kommer att finnas där.
I slutändan är det bästa rådet jag kan ge detta:
- Om du använder MySQL och Transients API kommer saker och ting att fungera som beskrivs i Codex.
- Om du å andra sidan använder ett annat cachningssystem är det viktigt att förstå hur det fungerar och hur du kan skriva kod mot det så att det fungerar som du vill.
Och med det finns det inget mer att lägga till i denna primer för att förstå caching i WordPress.