Share
Când vine vorba de construirea de aplicații web, unul dintre cele mai importante lucruri pe care trebuie să le ținem în permanență în vedere este performanța.
După cum se spune, performanța este o caracteristică.
Și indiferent dacă sunteți un designer, un dezvoltator sau un utilizator, știi acest lucru intuitiv pentru a fi adevărat: când vine vorba de aplicații, ne place să așteptăm. Ne face frustrați atunci când lucrurile nu funcționează destul de repede sau trebuie să așteptăm mai mult decât credem noi că ar trebui.
În acest scop, cele mai moderne cadre de dezvoltare web fac posibilă implementarea unui anumit tip de cache prin utilizarea anumitor API, iar WordPress - deși o fundație - nu este diferită.
Deoarece vom continua discuția noastră despre motivul pentru care WordPress este o opțiune viabilă pentru a servi drept fundație în dezvoltarea aplicațiilor web, vom analiza API-urile furnizate de aplicația de bază, modul în care funcționează, modul în care le putem folosi avantajul nostru și modul în care performanța poate fi îmbunătățită și mai mult de pluginurile suplimentare de cache.
Pe scurt, memorarea în cache este importantă deoarece ne permite să stocăm date care sunt adesea preluate într-un loc din memorie astfel încât să poată fi recuperat rapid.
Când vă uitați la acest lucru la o scară mai mare, acest lucru devine din ce în ce mai evident atunci când mai mulți utilizatori vizionează un site. Prin aceasta, vreau să spun că dacă o singură persoană - sau un număr foarte mic de persoane - a lovit un site web și site-ul are datele stocate într-o bază de date, atunci de fiecare dată când o pagină este încărcată, atunci acele informații trebuie să fie preluate de la baza de date, introduse în pagină și apoi returnate utilizatorului.
Dacă se instalează un nivel de cache, apelurile către baza de date nu vor trebui să fie făcute la fel de frecvent. În schimb, informațiile pot fi trase dintr-o zonă din memorie, ceea ce duce la o recuperare mai rapidă și, astfel, la o încărcare mai rapidă a paginilor.
O să intrăm în detalii tehnice mai târziu în articol.
Dacă ați folosit WordPress pentru o perioadă semnificativă de timp, probabil că sunteți familiarizat cu un număr de pluginuri de cache care sunt disponibile.
Acestea sunt fără îndoială soluții excelente pentru accelerarea aplicării site-ului web și / sau a aplicației web, dar ridică întrebarea: dacă sunt disponibile pluginuri pentru a face acest lucru, atunci de ce să ne facem griji?
Este o întrebare validă, sigur, dar plugin-urile pot lucra atât de mult pe cont propriu.
Dezvoltatorii pot structura aplicațiile în așa fel încât să nu funcționeze doar bine fără mecanisme de caching, dar vor fi și ele mult îmbunătățite de către pluginurile de cache menționate.
Prin aceasta, vreau să spun că aceste pluginuri de tip caching caută ca datele să fie stocate într-o anumită locație de teme și aplicații și dacă putem face acest lucru în mod programatic în contextul propriei noastre activități, atunci pluginurile vor duce la performanțe și mai mari.
După ce analizăm API-urile pe care le avem la dispoziție, vom revedea acest subiect pentru a le vedea Cum acestea îmbunătățesc performanța pluginurilor de cache mai târziu în articol.
Pentru a introduce un prim nivel de caching în aplicație, trebuie să profităm de WordPress 'Transients API. Mai întâi, rețineți că definiția oficială a unui tranzitoriu este "ceva care există doar pentru o perioadă scurtă de timp".
Așa cum este definit în Codul:
[API tranzitorie] oferă o modalitate simplă și standardizată de stocare temporară a datelor din memoria cache în baza de date, oferindu-i un nume personalizat și un interval de timp după care acesta va expira și va fi șters.
Dar ce înseamnă asta exact? La urma urmei, datele sunt încă stocate în baza de date, deci de ce este mai bine decât păstrarea datelor stocate în orice altă tabelă de baze de date (cum ar fi wp_options masa?)?
Odată ce vom revizui discuția despre cache și plugin-uri, vom vorbi mai multe despre acest lucru în detaliu.
Stabilirea unei valori tranzitorii este de fapt foarte ușoară și este la fel de importantă ca stocarea datelor în tabelul de opțiuni.
Mai exact, aveți nevoie de o valoare cheie care să identifice în mod unic datele și apoi aveți nevoie de o valoare care să fie asociată cu acea cheie. De asemenea, aveți nevoie de un timp de expirare (în secunde) pentru a păstra datele în tabel înainte de a le recondiționa.
Deci, să spunem că dorim să stocăm numele utilizatorului curent ca ultimul sau cel mai recent utilizator activ pe site. Putem face acest lucru prin a profita de wp_get_current_user () funcţie.
În primul rând, vom seta valoarea astfel:
set_transient ('most_recent_user', wp_get_current_user () -> user_login, 12 * HOUR_IN_SECONDS)
Aici, observați câteva lucruri:
Accentsconagua
HOUR_IN_SECONDS constantele sunt ceva introdus în WordPress 3.5. O listă completă a constantelor este disponibilă aici.Deși așa mergem noi cadru un moment tranzitoriu, acest lucru încă nu ține cont de modul în care putem gestiona tranziții dacă nu există sau dacă există deja.
Vom acoperi mai mult un pic mai târziu în articol.
Când vine vorba de recuperarea tranzitorilor, este foarte asemănător cu recuperarea unor lucruri precum meta date sau opțiuni. Prin asta, vreau să spun că pur și simplu trebuie să cunoaștem cheia prin care să recuperăm informațiile.
Prin urmare, pentru a păstra în concordanță cu exemplul de mai sus, putem prelua cel mai recent utilizator al aplicației cu următorul apel:
get_transient ('most_recent_user');
Acest lucru va reveni în mod evident la orice tip de informație pe care ați stocat-o, sau dacă tranzitorul a expirat - adică, peste 12 ore au trecut - atunci funcția va reveni la valoarea booleană a FALS.
Aceasta este cheia care trebuie amintită în special atunci când încercați să citiți valorile cache-ului și apoi trebuie să le luați de la o altă sursă de date dacă acestea nu vor fi disponibile în magazinul tranzitoriu.
Vom arunca o privire la un exemplu complet de a face acest lucru înainte de sfârșitul articolului.
În cele din urmă, dacă trebuie să ștergeți un element tranzitoriu, fie să îl eliminați complet, fie să îl eliminați înainte de expirarea sa definită, pentru ao înlocui cu o altă valoare, atunci pur și simplu utilizați următoarea funcție:
delete_transient ('most_recent_user');
În plus, această funcție va reveni FALS dacă ștergerea valorii tranzitorii nu este de succes; în caz contrar, se va întoarce FALS.
Când vine vorba de setarea timpului pentru expirarea valorii cache-ului, există o serie de modalități care fac mai ușor setarea valorilor, mai degrabă decât manipularea integerului de bază al muzicii.
De exemplu, MINUTE_IN_SECONDS este mult mai ușor de folosit decât 60, mai ales când îi înmulțiți, de exemplu, minute, ore sau zile.
Și din WordPress 3.5, mai multe constante au fost adăugate la aplicația de bază care fac aceste calcule mult mai ușor de citit.
Și anume:
MINUTE_IN_SECONDSHOUR_IN_SECONDSDAY_IN_SECONDSWEEK_IN_SECONDSYEAR_IN_SECONDSEste mult mai ușor de utilizat, de citit și de scris, nu este așa?
În acest moment, cred că este important să ne uităm la modul în care putem stabili pornirea tranzitorilor cu stocarea unei valori în tabelul de opțiuni.
Iată ordinea în care vom face acest lucru:
wp_options masa.Apoi, în a doua jumătate a codului, vom face următoarele:
Cu asta a spus, să aruncăm o privire:
$ username = wp_get_current_user () -> numele utilizatorului; add_option ('most_recent_user', $ username); // Verificați pentru a vedea dacă valoarea există în cache dacă (FALSE! == get_transient ('most_recent_user')) // Dacă da, vom șterge ... dacă (delete_transient ('most_recent_user')) // ... și să stocați cel mai recent utilizator pentru un maxim de minute set_transient ('most_recent_user', MINUTE_IN_SECONDS); altceva // Ștergerea a eșuat, deci înregistrați eroarea // Acum încercați să citiți valoarea din memoria cache. dacă FALSE! == ($ username = get_transient ('most_recent_user')) // Deoarece nu există, atunci îl vom citi din tabelul opțiunii $ username = get_option ('most_recent_user'); apoi vom actualiza cache-ul set_transient ('most_recent_user', $ username, MINUTE_IN_SECONDS); Rețineți că acest exemplu nu este complet - ar putea fi refactat să fie puțin mai curat și codul ar trebui să fie abstractizat în funcții care sunt mai relevante pentru aplicație, dar scopul acestui cod este de a arăta cum să se ocupe de logica condițională, de opțiuni , și tranzitorii.
Acum, cu toate acestea, putem revedea întrebarea cu privire la modul în care utilizarea tranzițiilor poate îmbunătăți performanța în cadrul pluginurilor.
După cum am menționat anterior:
După ce analizăm API-urile pe care le avem la dispoziție, vom revedea acest subiect pentru a le vedea Cum acestea îmbunătățesc performanța pluginurilor de cache mai târziu în articol.
Cu aceasta a spus, caching-ul și baza de date WordPress are de a face cu Locație a datelor din baza de date.
Deoarece tranzitorii sunt stocați într-o locație separată decât restul datelor, plugin-urile, cum ar fi un plugin bazat pe memcached, de exemplu, vor căuta date în care sunt stocate tranzitorii, apoi vor încărca datele în memorie din locația respectivă.
Astfel, atunci când datele sunt solicitate, acestea vor fi preluate din memorie. Dacă datele nu există, atunci acestea vor fi preluate din baza de date.
În plus, în cazul în care programarea este efectuată corect, când datele nu pot fi citite din memoria cache și sunt preluate din baza de date, acestea vor fi inserate înapoi în memoria cache, astfel încât data viitoare să fie recuperată, va fi disponibilă în memorie.
În cele din urmă, cheia importantă de observat despre informațiile tranzitorii este că are o perioadă de expirare. Aceasta înseamnă că datele vor fi stocate numai în această zonă a bazei de date pentru o anumită perioadă de timp.
În acest scop, trebuie să luăm în considerare acest lucru. Aceasta înseamnă că ori de câte ori căutăm să recuperăm tranzitorii, trebuie să ne asigurăm că există. Dacă nu, atunci îi vom trage de unde sunteți localizate, apoi stocați-le în locația corectă.
În acest moment, am acoperit o mulțime de teme ale caracteristicilor pe care WordPress le oferă în legătură cu o bază pentru dezvoltarea aplicațiilor web.
Dar avem o ultimă componentă majoră pe care o acoperim și care este modalitatea de a face față interogărilor personalizate.
Sigur, există câteva API-uri grozave care se referă la rularea interogărilor concepute pentru scopuri specifice WordPress WP_Query și WP_User_Query, dar vom arunca o privire la unele dintre facilitățile native care ne permit să scriem interogări personalizate împotriva bazei de date folosind obiecte WordPress definite, precum și metode care permit o dezinfectare adecvată a datelor.
Dar vom acoperi toate acestea și mai mult din acest material în următorul articol.
