Share
Als het gaat om het bouwen van webapplicaties, is een van de belangrijkste dingen waar we ons voortdurend bewust van moeten zijn, prestaties.
Zoals ze zeggen, is performance een functie.
En ongeacht of u een ontwerper, ontwikkelaar of gebruiker bent, u weet dat dit intuïtief waar is: als het op toepassingen aankomt, hebben we een hekel aan wachten. We raken gefrustreerd wanneer dingen niet snel genoeg werken, of we moeten langer wachten dan we denken dat we zouden moeten doen.
Daartoe maken de meeste moderne webontwikkelingskaders het mogelijk om bepaalde soorten caching te implementeren door het gebruik van bepaalde API's, en WordPress - hoewel een basis - is niet anders.
Dus als we onze discussie voortzetten over waarom WordPress een haalbare optie is om als een fundament te dienen voor de ontwikkeling van webtoepassingen, zullen we de API's bekijken die door de kernapplicatie worden geboden, hoe ze werken, hoe we ze kunnen gebruiken om te gebruiken ons voordeel en hoe de prestaties nog verder kunnen worden verbeterd door extra caching-plug-ins.
Kortom, caching is belangrijk omdat het ons in staat stelt om gegevens die vaak worden opgehaald op een plaats in het geheugen op te slaan, zodat deze snel kan worden opgehaald.
Als je dit op grotere schaal bekijkt, wordt dit steeds duidelijker wanneer meerdere gebruikers een site bekijken. Daarmee bedoel ik dat als een enkele persoon - of een heel klein aantal mensen - een website raakt en de site zijn gegevens in een database heeft opgeslagen, dan moet elke keer dat een pagina wordt geladen die informatie worden opgehaald uit de database. database, ingevoegd in de pagina en vervolgens teruggestuurd naar de gebruiker.
Als er een niveau van caching wordt ingesteld, hoeven oproepen naar de database niet zo vaak te worden gemaakt. In plaats daarvan kan de informatie worden opgehaald uit een gebied in het geheugen dat resulteert in sneller ophalen en dus snellere paginalaadtijden.
We zullen verderop in het artikel nader ingaan op de technische details hiervan.
Als u WordPress gedurende een aanzienlijke tijd hebt gebruikt, bent u waarschijnlijk bekend met een aantal caching-plug-ins die beschikbaar zijn.
Dit zijn ongetwijfeld geweldige oplossingen voor het versnellen van uw website en / of webapplicatie, maar het roept wel de vraag op: als er plug-ins beschikbaar zijn om dit te doen, waarom zouden we ons daar dan zorgen over maken??
Het is een geldige vraag, maar de plug-ins kunnen alleen zo veel werk op zichzelf doen.
Ontwikkelaars kunnen hun applicaties zodanig structureren dat ze niet alleen goed presteren zonder caching-mechanismen, maar ook enorm worden verbeterd door de caching-plug-ins.
Daarmee bedoel ik dat deze caching-plug-ins zoeken naar gegevens om op een bepaalde locatie te worden opgeslagen door thema's en toepassingen, en als we dat programmatisch kunnen doen binnen de context van ons eigen werk, zullen de plug-ins resulteren in nog betere prestaties.
Nadat we de API's hebben bekeken die we beschikbaar hebben, zullen we dit onderwerp opnieuw bekijken om te zien hoe ze verbeteren de prestaties van caching-plug-ins later in het artikel.
Om ons eerste niveau van caching in de applicatie te introduceren, moeten we gebruik maken van de transiënten-API van WordPress. Merk allereerst op dat de officiële definitie van de transient 'iets is dat maar voor een korte tijd bestaat'.
Net zoals gedefinieerd in de Codex:
[The Transient API] biedt een eenvoudige en gestandaardiseerde manier om gegevens in de cache tijdelijk in de database op te slaan door het een aangepaste naam en een tijdvak te geven waarna het zal verlopen en worden verwijderd.
Maar wat betekent dit precies? De gegevens worden immers nog steeds opgeslagen in de database, dus waarom is dit beter dan gegevens bewaren in een andere databasetabel (zoals de wp_options tafel?)?
Zodra we de discussie over caching en plug-ins opnieuw bekijken, zullen we hier meer in detail over spreken.
Het instellen van een tijdelijke waarde is eigenlijk heel eenvoudig en het lijkt veel op het opslaan van gegevens in de optietabel.
In het bijzonder heeft u een sleutelwaarde nodig die de gegevens op unieke wijze identificeert en vervolgens heeft u een waarde nodig die aan die sleutel moet worden gekoppeld. U hebt ook een vervaltijd (in seconden) nodig om de gegevens in de tabel te bewaren voordat u deze vernieuwt.
Laten we zeggen dat we de naam van de huidige gebruiker willen opslaan als de laatste of meest recente gebruiker die actief is op de site. We kunnen dit doen door gebruik te maken van de wp_get_current_user () functie.
Eerst stellen we de waarde als volgt in:
set_transient ('most_recent_user', wp_get_current_user () -> user_login, 12 * HOUR_IN_SECONDS)
Hier, merk een paar dingen op:
Accentsconagua
HOUR_IN_SECONDS constanten is iets dat werd geïntroduceerd in WordPress 3.5. Een volledige lijst van de constanten is hier beschikbaar.Hoewel dit is hoe we het doen omgeving een transient, dit is nog steeds geen verklaring voor hoe we transiënten kunnen beheren als ze niet bestaan, of als ze al bestaan.
We zullen dat later in het artikel bespreken.
Als het gaat om het ophalen van transiënten, lijkt het erg op het ophalen van dingen zoals metagegevens of opties. Daarmee bedoel ik dat we gewoon de sleutel moeten kennen om de informatie op te halen.
Dus in overeenstemming met het bovenstaande voorbeeld kunnen we de meest recente gebruiker van de toepassing ophalen met de volgende aanroep:
get_transient ('most_recent_user');
Dit zal uiteraard alle soorten informatie die u hebt opgeslagen teruggeven, of als de transiënt is verlopen, dat wil zeggen meer dan 12 uur is verstreken, retourneert de functie de Booleaanse waarde van VALSE.
Dit is de sleutel om te onthouden, vooral wanneer u cachewaarden probeert te lezen en ze vervolgens uit een andere gegevensbron moet halen als ze niet beschikbaar zijn in de tijdelijke opslagruimte.
We zullen een volledig voorbeeld bekijken van dit doen vóór het einde van het artikel.
Als u ten slotte een tijdelijke noodzaak wilt verwijderen om deze volledig te verwijderen of om deze te verwijderen vóór de vastgestelde vervaldatum om deze met een andere waarde te vervangen, gebruikt u eenvoudigweg de volgende functie:
delete_transient ('most_recent_user');
Bovendien keert deze functie terug VALSE als het verwijderen van de tijdelijke waarde niet succesvol is; anders zal het terugkeren VALSE.
Als het gaat om het instellen van tijden voor het verlopen van cachewaarden, zijn er een aantal manieren die het eenvoudiger maken om waarden in te stellen in plaats van muziek..
Bijvoorbeeld, MINUTE_IN_SECONDS is veel gemakkelijker te gebruiken dan 60, vooral wanneer het wordt vermenigvuldigd met bijvoorbeeld minuten, uren of dagen.
En vanaf WordPress 3.5 zijn er verschillende constanten toegevoegd aan de kernapplicatie die deze berekeningen veel gemakkelijker te lezen maken.
Namelijk:
MINUTE_IN_SECONDSHOUR_IN_SECONDSDAY_IN_SECONDSWEEK_IN_SECONDSYEAR_IN_SECONDSVeel gemakkelijker te gebruiken, te lezen en te schrijven, nietwaar?
Op dit moment denk ik dat het belangrijk is om te kijken naar hoe we om kunnen gaan met het instellen van transiënten, begin met het opslaan van een waarde in de optietabel.
Dit is de volgorde waarin we dit gaan doen:
wp_options tafel.Vervolgens doen we in de tweede helft van de code het volgende:
Met dat gezegd, laten we een kijkje nemen:
$ username = wp_get_current_user () -> gebruikersnaam; add_option ('most_recent_user', $ gebruikersnaam); // Controleer of de waarde in de cache bestaat als (FALSE! == get_transient ('most_recent_user')) // Als dit het geval is, verwijderen we deze ... if (delete_transient ('most_recent_user')) // ... en sla de meest recente gebruiker op voor maximaal een minuut set_transient ('most_recent_user', MINUTE_IN_SECONDS); else // De verwijdering is mislukt, dus registreer de fout // Probeer nu de waarde uit de cache te lezen. if (FALSE! == ($ username = get_transient ('most_recent_user')) // Omdat het niet bestaat, lezen we het uit de tabel van de optie $ username = get_option ('most_recent_user'); // And dan zullen we de cache bijwerken set_transient ('most_recent_user', $ gebruikersnaam, MINUTE_IN_SECONDS); Merk op dat dit voorbeeld niet volledig is - het zou kunnen worden geformuleerd om een beetje schoner te zijn, en de code zou moeten worden geabstraheerd naar functies die relevanter zijn voor de toepassing, maar het doel van deze code is om te laten zien hoe om te gaan met voorwaardelijke logica, opties en transiënten.
Nu, met dit alles gezegd, kunnen we opnieuw de vraag bekijken hoe het gebruik van transiënten de prestaties binnen plug-ins kan verbeteren.
Zoals we eerder vermeldden:
Nadat we de API's hebben bekeken die we beschikbaar hebben, zullen we dit onderwerp opnieuw bekijken om te zien hoe ze verbeteren de prestaties van caching-plug-ins later in het artikel.
Dat gezegd hebbende, hebben caching en de WordPress-database te maken met de plaats van de gegevens in de database.
Omdat transiënten op een andere locatie worden opgeslagen dan de rest van de gegevens, zoeken plug-ins, zoals een op memcached gebaseerde plug-in, naar gegevens waar overgangen worden opgeslagen, en laden de gegevens vanaf die locatie in het geheugen..
Wanneer de gegevens worden opgevraagd, wordt deze dus uit het geheugen opgehaald. Als de gegevens niet bestaan, wordt deze uit de database opgehaald.
Als de programmering correct wordt uitgevoerd, als de gegevens niet uit de cache kunnen worden gelezen en uit de database worden opgehaald, wordt deze bovendien weer in de cache geplaatst zodat de volgende keer dat deze wordt opgehaald, deze in het geheugen beschikbaar zal zijn.
Ten slotte is het belangrijkste om op te merken over voorbijgaande informatie dat deze een vervalperiode heeft. Dit betekent dat gegevens slechts gedurende een bepaalde tijd in dit gedeelte van de database worden opgeslagen.
Daartoe moeten we rekenschap afleggen. Dit betekent dat wanneer we op zoek zijn naar transiënten, we ervoor moeten zorgen dat ze bestaan. Als ze dat niet doen, trekken we ze van waar ze komen zijn gevonden en sla ze vervolgens op de juiste locatie op.
Op dit punt hebben we veel aspecten behandeld van WordPress omdat het betrekking heeft op een basis voor de ontwikkeling van webtoepassingen.
Maar we hebben nog een laatste belangrijke component te behandelen en zo kunnen we omgaan met aangepaste zoekopdrachten.
Natuurlijk zijn er enkele geweldige API's die betrekking hebben op query's die zijn ontworpen voor WordPress-specifieke doeleinden WP_Query en WP_User_Query, maar we zullen ook een kijkje nemen naar enkele van de ingebouwde faciliteiten waarmee we aangepaste query's tegen de database kunnen maken met behulp van gedefinieerde WordPress-objecten, evenals methoden die een goede data-sanering mogelijk maken.
Maar we zullen dat alles en meer van dat materiaal in het volgende artikel behandelen.
