WordPress Object Caching: Redis, Memcached și API-uri native

Site-urile WordPress de nivel enterprise, care se pot scala după bunul plac, au nevoie de un mecanism persistent de stocare în cache dincolo de pagini și imagini, un mecanism care poate stoca în cache obiecte PHP reale. Deși WordPress oferă un mecanism de stocare în cache a obiectelor prin intermediul WordPress Object Cache, există și alte soluții care oferă o pârghie și putere mare. Dar înainte de a intra în toate acestea, mai întâi, trebuie să vedem ce este stocarea în cache a obiectelor și cum funcționează în PHP.

Ce este memoria cache a obiectelor?

PHP este un limbaj orientat pe obiecte. Utilizează paradigma Object pentru a structura codul. Ca rezultat, site-ul dvs. WordPress este format din multe obiecte PHP diferite care sunt create, instanțiate și distruse în mod constant (de către managerul de memorie). Crearea și distrugerea obiectelor are un cost general, mai ales dacă sunt multe. Cu toate acestea, cele mai multe dintre acestea tind să fie reutilizate mult, deoarece reprezintă funcționalități de bază. Aceasta înseamnă că de fiecare dată când aplicația are nevoie de ele din nou, va trebui să le instanțieze de la început.

Ce se întâmplă dacă ai putea stoca în cache un obiect instanțiat folosit frecvent, astfel încât să nu fii nevoie să-l distrugi și să-l creezi tot timpul?

Puteți folosi funcția PHP serialise() pentru a converti un obiect sau o primitivă într-o reprezentare numerică (byte blob) care poate fi stocată în memorie sau pe disc pentru acces ulterioară. Apoi calculați numărul hash al blob-ului de octeți folosind funcția hash() și le stocați pe ambele. Hash ca cheie și byte blob ca valoare. Pentru a-l recupera, utilizați numărul hash calculat al blob-ului de octeți, care a fost stocat inițial ca cheie. Puteți transforma orice (șir, întreg, obiect, boolean, matrice etc.) într-o reprezentare stocabilă a unei valori în acest fel.

Exemplu:

$serialized = serialize( array ( 'test' ));

Efectuați operația inversă, cu unserialize():

$original = unserialize ( $serialized );

În general, există trei moduri prin care puteți stoca în cache obiecte: folosind cache-ul obiect WordPress nativ, API-ul Tranzitori sau un magazin extern cheie-valoare, cum ar fi Redis sau Memcached.

Memorarea în cache a obiectelor WordPress

WordPress oferă două API-uri de stocare în cache a obiectelor: WordPress Object Cache nativ și API-ul Tranzitori. Sunt identice și, deși acest lucru poate provoca confuzie, există o logică în spatele ei.

Cache-ul de obiecte WordPress nativ poate stoca obiecte și primitive în cache, dar nu într-o manieră persistentă în mod implicit. Aceasta înseamnă că stocarea în cache are loc în memorie, iar obiectele stocate în cache nu trăiesc dincolo de ciclul de viață al cererii. Prin urmare, nu puteți partaja obiectele stocate în cache în diferite încărcări de pagină. Trebuie să furnizați propria implementare a magazinului cu utilizarea Drop-In-urilor, care sunt pluginuri „avansate” care pot extinde funcționalitatea WordPress. Le puteți vedea pe tabloul de bord WordPress, în lista de pluginuri:

API-ul Tranzitori, pe de altă parte, funcționează din nou. Puteți salva variabile, matrice, obiecte legate cu o dată de expirare direct într-o bază de date și puteți avea cache persistentă a obiectelor. Cu toate acestea, problema este că atunci când obiectele din cache expiră, acestea rămân în baza de date ocupând spațiu. Aceasta înseamnă că există o suprasarcină suplimentară cheltuită pentru întreținerea bazei de date, tăind din când în când obiectele expirate.

WordPress detectează dacă ați implementat propriul cache de obiecte persistente și, atunci când constată că este cazul, apelurile către API-ul Tranzitori sunt ocolite și direcționate către cache-ul obiectelor WordPress (și astfel motivul pentru care acestea sunt identice).

Dezvoltatorii își pot implementa propriul cache de obiecte, pot folosi un plugin WordPress (mai multe despre acestea mai târziu) sau propria noastră implementare, dacă este un client Pressidium. Nu avem cache-ul obiectelor activat în mod implicit, deoarece acest lucru poate cauza penalizări de performanță dacă este utilizat într-o situație greșită. Nu există o soluție „unică pentru toate” când vine vorba de stocarea în cache a obiectelor în site-urile WordPress.

Redis și Memcached

Magazinele cheie-valoare nu folosesc tabele și tipuri de date predefinite pentru a stoca informații în înregistrări, cum ar fi în RDBMS. Ele sunt concepute pentru a stoca și a prelua perechi cheie/valoare, ca în structurile de date din dicționar pe care le găsiți în limbajele de programare.

Un exemplu bun de astfel de magazin este Redis. Pe lângă structurile de date din dicționar, acceptă o mulțime de altele, inclusiv cele avansate, cum ar fi seturi sortate cu interogări de interval și indici geospațiali cu interogări de rază. Oferă cache persistentă a obiectelor .

Redis nu este doar un magazin sau un cache cheie-valoare. Suportă replicarea datelor, scripting, disponibilitate ridicată într-o configurație de cluster. De asemenea, puteți regla fin nivelul de persistență pe disc dorit. Lucrul bun despre Redis este că, dacă reporniți, cea mai mare parte a memoriei cache va fi în continuare pe disc, iar datele pierdute vor fi doar o mică parte. Chestia este că la repornire, serverul ar trebui să reconstruiască memoria cache și asta de cele mai multe ori crește încărcarea. Cu Redis acest lucru nu se întâmplă. În plus, obiectele expirate sunt șterse imediat din baza de date. Nici acolo nu există timp de management.

Redis Labs are o pagină excelentă care prezintă cazurile de utilizare Redis în Enterprise: Acestea variază de la seturi de date foarte mari, la căutare full-text, serii în timp real, integrare Spark și multe altele.

Deși toate aceste funcții costă în complexitate și poate în viteză în unele cazuri, optimizarea codului Redis Drop-In poate obține destul de multe câștiguri. Nu uitați de faptul că Redis face obiecte persistente în cache , ceva ce Memcached nu face, deși este mult mai simplu de utilizat.

Memcached este un sistem de stocare în cache a obiectelor de înaltă performanță în memorie, care este conform site-ului web oficial, conceput special pentru a accelera aplicațiile web dinamice și pentru a reduce încărcarea bazei de date. De asemenea, este mult mai simplu și simplu de utilizat decât Redis.

Datorită faptului că este conceput special pentru a face cache de obiecte pentru pagini web și faptul că folosește o bază de date în memorie, o face cea mai rapidă soluție de stocare în cache a obiectelor. Cu toate acestea, așa cum am menționat mai devreme, dacă serverul repornește, memoria cache este epuizată. Și până când va fi reconstruit, probabil că veți avea o sarcină crescută. Dar, așa cum spun creatorii: „gândește-te la asta ca la o memorie pe termen scurt pentru site-ul tău”, așa că depinde mai degrabă de ceea ce vrei să faci în primul rând.

Deoarece Memcached folosește o bază de date în memorie pentru păstrarea memoriei cache, este foarte eficient în stocarea în cache a interogărilor SQL, a ieșirilor apelurilor de funcție și altele.

Pluginuri WordPress

• WP Redis, pluginul oficial Redis WordPress. Suportă WP-CLI, clustering și replicare.
• Redis Object Cache Un alt plugin Redis back-end pentru WordPress.
• Memcached Object Cache, backend-ul pentru Memcached.
• Delete Expired Transients, acest plugin șterge obiectele tranzitorii expirate din baza de date. De asemenea, acceptă mai multe site-uri!

Cum să rulați benchmark-uri

Scopul articolului nostru este să te entuziasmeze cu privire la stocarea în cache a obiectelor și să începi să faci singur operațiunile. Puteți încerca diverse implementări persistente de cache și puteți vedea cât de bine se comportă aplicația dvs. Puteți utiliza funcția PHP microsecond() pentru a compara apelurile. De exemplu: Apelați microsecond() înainte și după apelarea wp_cache_get() , scădeți valorile și stocați rezultatul. Faceți acest lucru pentru diferite implementări de cache și vedeți în ce cazuri observați un câștig de performanță.

La Pressidium, nu avem activată implicit caching-ul obiectelor și, deși este ceva ce poate fi solicitat, de obicei nu o sfătuim în favoarea de la început. Efectuăm teste și ne asigurăm că site-ul tău va obține beneficii de pe urma acestuia.

Concluzie

Să presupunem că pentru a reda o pagină aplicația trebuie să citească 2.000 de obiecte tranzitorii. Asta înseamnă 2.000 de citiri în baza de date. Prin utilizarea unui sistem de stocare în cache a obiectelor persistente, aceste 2.000 de citiri sunt descărcate în depozitul cheie-valoare. Dacă utilizați memcached, atunci riscați să vă pierdeți tot memoria cache într-o repornire bruscă. În general, Redis ar putea să nu fie la fel de rapid ca Memcached, dar caracteristicile sale Enterprise și persistența vă avantajează pe termen lung.

Cu toate acestea, o singură mărime nu se potrivește tuturor! De exemplu, am văzut cazuri Redis care au încetinit de fapt site-urile web și, în alte cazuri, le-au accelerat incredibil. Acest lucru are de-a face cu o serie de obiecte pe care le folosește aplicația dvs.: în general, dacă aplicația dvs. folosește câteva (să zicem o duzină) nu veți beneficia prea mult de stocarea în cache a obiectelor și, în cel mai rău caz, veți au supraîncărcare de rețea. Dacă, totuși, aplicația dvs. este în sute, atunci ar putea plăti să aruncați o privire.