Share
När det gäller att bygga webbapplikationer är en av de viktigaste sakerna som vi alltid måste vara uppmärksamma på.
Som de säger är prestanda en funktion.
Och oavsett om du är designer, utvecklare eller användare vet du det här intuitivt för att vara sant: När det gäller applikationer hatar vi att vänta. Vi blir frustrerade när sakerna inte fungerar tillräckligt snabbt, eller vi måste vänta längre än vi tror att vi borde.
För det ändamålet gör de flesta moderna webbutvecklingsramar det möjligt att implementera någon typ av caching genom användningen av vissa API och WordPress-men en grund-är inte annorlunda.
Så när vi fortsätter vår diskussion om varför WordPress är ett lönsamt alternativ för att fungera som grund för webbapplikationsutveckling, tar vi en titt på API: erna som tillhandahålls av kärnanvändningen, hur de fungerar, hur vi kan utnyttja dem till vår fördel, och hur prestanda kan förbättras ännu mer genom ytterligare cachepluggar.
Kortfattat är caching viktigt eftersom det tillåter oss att lagra data som ofta hämtas på plats i minnet så att det snabbt kan hämtas.
När du tittar på detta i större skala blir det allt tydligare när flera användare tittar på en webbplats. Därmed menar jag att om en enda person eller ett mycket litet antal personer träffar en webbplats och webbplatsen har sina data lagrade i en databas, då varje gång en sida laddas, måste den information hämtas från databas, infogad på sidan, och återförd till användaren.
Om en nivå av caching är inställd så behöver inte samtal till databasen göras så ofta. I stället kan informationen dras från ett område i minnet som resulterar i snabbare hämtning och därigenom snabbare sidlastningstider.
Vi kommer in i de tekniska detaljerna här lite längre senare i artikeln.
Om du har använt WordPress under en betydande tid, är du troligen bekant med ett antal cachepluggar som är tillgängliga.
Det är utan tvekan bra lösningar för att påskynda din webbplats och / eller webbapplikation, men det ställer frågan: Om plugins är tillgängliga för att göra det, varför ska vi oroa oss för det?
Det är en giltig fråga, för att vara säker, men plugins kan bara göra så mycket arbete på egen hand.
Utvecklare kan strukturera sina applikationer på ett sådant sätt att de inte bara fungerar bra utan cachemekanismer, men kommer också att förbättras avsevärt av nämnda cachepluggar.
Därför menar jag att dessa caching-plugins letar efter att data lagras på en viss plats av teman och applikationer, och om vi kan programmässigt göra det inom ramen för vårt eget arbete, kommer pluginsna att resultera i ännu större prestanda.
När vi tittar på API: erna som vi har tillgängliga, kommer vi att titta på det här ämnet för att se på vilket sätt De förbättrar prestanda för cachepluggar senare i artikeln.
För att kunna introducera vår första nivå av caching i programmet måste vi dra nytta av WordPress 'Transients API. Först notera att den officiella definitionen av en transient är "något som existerar endast under en kort tid".
Precis som definierad i Codex:
[Transient API] 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, varefter den kommer att löpa ut och raderas.
Men vad betyder detta exakt? Trots allt lagras dataen fortfarande i databasen, varför är det här bättre än att hålla data lagrade i någon annan databas tabell (t.ex. wp_options tabell?)?
När vi återbesöker diskussionen om caching och plugins, kommer vi att prata mer om detta i mer detalj.
Det är faktiskt väldigt enkelt att ställa in ett övergående värde, och det är ungefär som att lagra data i alternativtabellen.
Specifikt behöver du ett nyckelvärde som unikt identifierar data, och då behöver du ett värde som ska associeras med den nyckeln. Du behöver också en utgångstid (i sekunder) för att hålla data i tabellen innan du uppdaterar den.
Så låt oss säga att vi vill lagra den aktuella användarens namn som den senaste eller senaste användaren som är aktiv på webbplatsen. Vi kan göra detta genom att dra nytta av wp_get_current_user () fungera.
Först ställer vi in värdet så här:
set_transient ('most_recent_user', wp_get_current_user () -> user_login, 12 * HOUR_IN_SECONDS)
Här märker du ett par saker:
Accentsconagua
HOUR_IN_SECONDS konstanter är något som introducerades i WordPress 3.5. En fullständig lista över konstanterna finns här.Även om det här är så går vi miljö en övergående, berättar det fortfarande inte hur vi kan hantera transienter om de inte existerar eller om de redan existerar.
Vi kommer att täcka det mer lite senare i artikeln.
När det gäller att hämta transienter ser det mycket ut som att man hämtar saker som metadata eller alternativ. Därmed menar jag att vi helt enkelt behöver känna till nyckeln för att hämta informationen.
Så i överensstämmelse med exemplet ovan kan vi hämta den senaste användaren av programmet med följande samtal:
get_transient ('most_recent_user');
Detta kommer givetvis att återkomma till vilken typ av information du lagrade, eller om övergången har löpt ut, det vill säga, över 12 timmar har passerat-då kommer funktionen att returnera det booleska värdet av FALSK.
Detta är nyckeln till att komma ihåg speciellt när du försöker läsa cache-värden och behöver sedan fånga dem från en annan datakälla om de inte är tillgängliga i den transienta butiken.
Vi tar en titt på ett komplett exempel på att göra detta före artikelns slut.
Slutligen, om du behöver ta bort en övergångsgivare, antingen för att helt ta bort den eller att ta bort den före den angivna utgången för att ersätta den med ett annat värde, så använder du helt enkelt följande funktion:
delete_transient ('most_recent_user');
Dessutom kommer denna funktion att återvända FALSK om raderingen av det transienta värdet inte lyckas annars kommer det att återvända FALSK.
När det gäller inställningstider för cachervärden för att löpa ut, finns det ett antal sätt som gör det enklare att ställa in värden istället för musikbaserad heltalsmanipulation.
Till exempel, MINUTE_IN_SECONDS är mycket lättare att använda än 60, särskilt när man multiplicerar det med exempelvis minuter, timmar eller dagar.
Och från WordPress 3.5 har flera konstanter lagts till i kärnanvändningen som gör dessa beräkningar mycket enklare att läsa.
Nämligen:
MINUTE_IN_SECONDSHOUR_IN_SECONDSDAY_IN_SECONDSWEEK_IN_SECONDSYEAR_IN_SECONDSMycket lättare att använda, att läsa och skriva är inte det?
Vid denna tidpunkt anser jag att det är viktigt att titta på hur vi kan gå om att konfigurera transienter börjar med att lagra ett värde i alternativtabellen.
Här är den ordning som vi ska göra om att göra detta:
wp_options tabell.Sedan gör vi följande i den andra halvan av koden:
Med det sagt, låt oss ta en titt:
$ användarnamn = wp_get_current_user () -> user_name; add_option ('most_recent_user', $ användarnamn); // Kontrollera om värdet finns i cacheminnet om (FALSE! == get_transient ('most_recent_user')) // Om det gör kommer vi radera det ... om (delete_transient ('most_recent_user')) // ... och lagra den senaste användaren i högst en minut set_transient ('most_recent_user', MINUTE_IN_SECONDS); else // Raderingen misslyckades, så logga in felet // Försök nu läsa värdet från cacheminnet. om (FALSE! == ($ användarnamn = get_transient ('most_recent_user')) // Eftersom det inte finns, läser vi det från alternativets tabell $ användarnamn = get_option ('most_recent_user'); // Och då uppdaterar vi cachen set_transient ('most_recent_user', $ användarnamn, MINUTE_IN_SECONDS); Observera att det här exemplet inte är fullständigt. Det kan vara refactored att vara lite renare och koden ska abstraheras till funktioner som är mer relevanta för applikationen, men syftet med denna kod är att visa hur man hanterar villkorad logik, alternativ , och transienter.
Nu, med allt det sagt, kan vi återkomma frågan om hur du använder transienter kan förbättra prestanda i plugins.
Som vi tidigare nämnde:
När vi tittar på API: erna som vi har tillgängliga, kommer vi att titta på det här ämnet för att se på vilket sätt De förbättrar prestanda för cachepluggar senare i artikeln.
Med det sagt har caching och WordPress-databasen att göra med plats av data i databasen.
Eftersom transienter lagras på ett separat ställe än resten av data, kommer plugins, till exempel en memcached-baserad plugin, att leta efter data där transienter lagras och ladda sedan data till minnet från den platsen.
Således, när data begärs, kommer den att hämtas från minnet. Om data inte existerar kommer den att hämtas från databasen.
Utöver det, om programmeringen är klar korrekt, när data inte läses från cacheminnet och hämtas från databasen, kommer det att sättas in i cacheminnet, så att nästa gång det hämtas kommer det att finnas tillgängligt i minnet.
Slutligen är det viktigaste att notera om övergående information att den har en utgångsperiod. Det betyder att data endast lagras i detta område i databasen under en viss tid.
För det ändamålet måste vi ta reda på det. Det betyder att när vi vill hämta transienter måste vi se till att de finns. Om de inte gör det kommer vi att dra dem från var de är är ligger och lagra dem på rätt plats.
Vid denna tidpunkt har vi täckt mycket av de funktioner som WordPress erbjuder när det gäller en grund för webbapplikationsutveckling.
Men vi har en sista viktig komponent för att täcka och det är så att hantera egna frågor.
Visst, det finns några bra API-skivor som det gäller att köra frågor som är utformade för WordPress-specifika ändamål WP_Query och WP_User_Query, men vi tar också en titt på några av de inbyggda faciliteter som tillåter oss att skriva anpassade frågor mot databasen med hjälp av definierade WordPress-objekt samt metoder som möjliggör korrekt datasanering.
Men vi kommer att täcka allt detta och mer av det materialet i nästa artikel.
