Italiano
Español
РусскийCum funcționează stocarea în cache a obiectelor?
Caut un răspuns definitiv aici. Când este activată stocarea în cache a obiectelor, unde ajung să fie stocate opțiunile și tranzientele?
În mod implicit, ambele sunt stocate în baza de date. Dar am auzit unele referințe că Memcache le va stoca în altă parte și APC va face ceva complet diferit. Unde vor fi persistate aceste date, exact, în ambele cazuri?
observație minoră 1: Nu toate opțiunile sunt încărcate la pornirea paginii, ci doar cele care sunt marcate cu "autoload=da" la creare. Valoarea implicită pentru acest parametru în add_option este 'da' și majoritatea dezvoltatorilor de plugin-uri nu se obosesc să înțeleagă diferența de a folosi 'nu' acolo, ceea ce face afirmația ta practic adevărată.
Mark Kaplun
Chiar și opțiunile care nu se încarcă automat sunt memorate în cache după ce sunt preluate o dată. Este posibil să nu fie încărcate inițial, dar intră în cache-ul obiect după aceea. Chiar și opțiunile care nu există sunt memorate în cache! https://github.com/WordPress/WordPress/blob/master/wp-includes/option.php#L58-L71 Am adăugat totuși o notă despre opțiunea de autoload.
chrisguitarguy
asta a fost observația minoră 2 ;)
Mark Kaplun
Mulțumesc pentru articolul excelent și pentru timpul acordat pentru a rezuma toate acestea.
prosti
Ce răspuns minunat și util, mulțumesc!
And Finally
Știu că răspunsul este destul de vechi, dar aș adăuga și excelentul Redis.
Cranio
@Cranio, ai dreptate dar... redis este practic o variantă de memcache cu stocare și, prin urmare, este o bază de date (NoSQL). Aceasta IMHO este de fapt un lucru rău, deoarece dacă nodul eșuează sau nu poate fi actualizat, s-ar putea să obții informații învechite de la el. Are o opțiune pentru a dezactiva comportamentul de bază de date, dar nu sunt sigur dacă este activată sau dezactivată implicit.
Mark Kaplun
Este un înlocuitor perfect pentru Memcached (chiar mai bun), ce altceva ai nevoie? De departe, cel mai frecvent utilizare pe care am văzut-o este doar ca o stocare cheie-valoare în RAM (da, în afară de asta, datele pot fi făcute persistente, clustering-ul este în curs de implementare și are capabilități de gestionare a cozilor, dar toată lumea adaugă Redis ca o excelentă opțiune de caching pentru WP)
Cranio
toți pot să sară și de pe pod ;) dar complexitatea adăugată nu este deloc necesară pentru caching
Mark Kaplun
Este complet inutil; vrei caching în RAM, Redis face caching în RAM, punct; și o face minunat. Nu există absolut nicio complexitate adăugată dacă nu vrei să mergi pe această cale. Așadar, domnule, chiar nu înțeleg punctul tău de vedere.
Cranio
Bună întrebare.
Cred că partea cu modul în care WordPress folosește clasa WP_Object_Cache încă lipsește, așa că voi adăuga asta.
Din documentație:
DEF: Cache-ul de Obiecte WordPress este folosit pentru a reduce numărul de accesări la baza de date. Cache-ul de Obiecte stochează toate datele de cache în memorie și pune conținutul cache-ului la dispoziție folosind o cheie, care este utilizată pentru a denumi și apoi pentru a recupera conținutul cache-ului.
Iată structura WP_Object_Cache.
Notă: + este public, - privat, # protejat.
Folosești metoda stats() pentru a afișa statistici generale despre obiectul global de cache și despre ce conține. Iată rezultatul:
Cache Hits: 110
Cache Misses: 98
Group: options - ( 81.03k )
Group: default - ( 0.03k )
Group: users - ( 0.41k )
Group: userlogins - ( 0.03k )
Group: useremail - ( 0.04k )
Group: userslugs - ( 0.03k )
Group: user_meta - ( 3.92k )
Group: posts - ( 1.99k )
Group: terms - ( 1.76k )
Group: post_tag_relationships - ( 0.04k )
Group: category_relationships - ( 0.03k )
Group: post_format_relationships - ( 0.02k )
Group: post_meta - ( 0.36k )
Acesta este rezultatul pe care l-am obținut chiar la începutul unui șablon precum single.php.
Variabila care ne interesează este:
global $wp_object_cache.
Membrul privat $cache stochează datele efective de cache.
În programare, structurile de cache sunt peste tot. În forma cea mai simplă, ele pot fi recunoscute ca perechi cheie-valoare. Găleți, structuri NoDB, indexuri de bază de date. Scopul final al Cache-ului de Obiecte WordPress nu a fost să aibă cea mai simplă structură posibilă, dar totuși perechile cheie-valoare pot fi recunoscute.
Deoarece mă aflam în single.php când am afișat cache-ul:
print_r($wp_object_cache->cache['posts']);
Am obținut un singur post stocat în cache.
[last_changed] => 0.34169600 1481802075
[get_page_by_path:2516f01e446b6c125493ec7824b63868:0.34169600 1481802075] => 0
[2831] => WP_Post Object
(
[ID] => 2831
[post_author] => 1
... aici continuă obiectul postului stocat în cache
)
Obiectul ar fi valoarea, iar cheia de cache ar fi
get_page_by_path:2516f01e446b6c125493ec7824b63868:0.34169600 1481802075
Aici puteți verifica structura $cache_key:
Fișier: /wp-includes/post.php
4210: /**
4211: * Returnează o pagină dată fiind calea acesteia.
4212: *
4213: * @since 2.1.0
4214: *
4215: * @global wpdb $wpdb Obiectul de abstractizare a bazei de date WordPress.
4216: *
4217: * @param string $page_path Calea paginii.
4218: * @param string $output Opțional. Tipul de return cerut. Unul dintre OBJECT, ARRAY_A sau ARRAY_N, care corespund
4219: * unui obiect WP_Post, unui array asociativ sau unui array numeric, respectiv. Implicit OBJECT.
4220: * @param string|array $post_type Opțional. Tipul de post sau array de tipuri de posturi. Implicit 'page'.
4221: * @return WP_Post|array|null WP_Post (sau array) în caz de succes, sau null în caz de eșec.
4222: */
4223: function get_page_by_path( $page_path, $output = OBJECT, $post_type = 'page' ) {
4224: global $wpdb;
4225:
4226: $last_changed = wp_cache_get_last_changed( 'posts' );
4227:
4228: $hash = md5( $page_path . serialize( $post_type ) );
4229: $cache_key = "get_page_by_path:$hash:$last_changed";
4230: $cached = wp_cache_get( $cache_key, 'posts' );
4231: if ( false !== $cached ) {
4232: // Caz special: '0' este o `$page_path` invalidă.
4233: if ( '0' === $cached || 0 === $cached ) {
4234: return;
4235: } else {
4236: return get_post( $cached, $output );
4237: }
4238: }