# Configurare critică în redis.conf pentru a preveni căderea serverului când memoria e plină
maxmemory 512mb
maxmemory-policy allkeys-lru
# În wp-config.php, definim prefix unic și dezactivăm metricele inutile
define('WP_REDIS_PREFIX', 'site_prod_');
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);
define('WP_REDIS_DISABLE_METRICS', true);Acum câteva luni am preluat un magazin WooCommerce cu vreo 42.000 de produse și peste 150 de comenzi pe zi. Problema clasică: în admin se mișca oribil, iar pe frontend fiecare click pe o categorie dura între 1.8 și 3 secunde doar până răspundea serverul (TTFB).
Clientul deja plătise două audituri care i-au recomandat un server dedicat de 200€/lună. În realitate, problema era modul în care WooCommerce interoga baza de date și faptul că memoria cache era aproape inexistentă.
Redis Object Cache: Nu lăsa MySQL să numere stocurile la infinit
Implicit, WordPress ține transients și cache-ul intern de obiecte direct în tabela wp_options. Pe un magazin mare, asta înseamnă sute de mii de rânduri cu autoload = 'yes', care se încarcă la absolut fiecare request, chiar și pentru un simplu ping de heartbeat.
Am instalat extensia redis de PHP pe server și drop-in-ul de object-cache.php (recomand pluginul Redis Object Cache al lui Till Krüss). Din start, numărul de queries pe o pagină de produs a scăzut de la 140 la 22.
Trade-off sincer: Redis are nevoie de RAM dedicat și disciplină. Dacă nu setezi în redis.conf directiva maxmemory-policy allkeys-lru, la primul import masiv de feed de la furnizori Redis se va umple, va arunca erori 500 și-ți pică magazinul instant. Am alocat 512MB de RAM doar pentru instanța de Redis și n-am mai avut probleme.
Cloudflare APO: Salvarea paginilor de catalog
Pentru utilizatorii nelogați, nu are niciun sens ca PHP să randeze pagina de categorie sau de produs la fiecare vizită. Am activat Cloudflare APO (Automatic Platform Optimization for WordPress).
Ce face APO bine: știe nativ de cookie-urile WooCommerce (woocommerce_items_in_cart, wp_woocommerce_session_). Dacă utilizatorul are coșul gol și nu e logat, Cloudflare îi livrează pagina direct din edge-ul cel mai apropiat (București pentru România) în sub 40ms. Imediat ce vizitatorul adaugă un produs în coș, cookie-ul se setează, iar APO face bypass automat, lăsând serverul de origine să proceseze request-urile dinamice.
Minusul? Dacă ai badge-uri dinamice pe catalog (de genul „mai sunt 2 bucăți în stoc” calculate live în PHP), utilizatorii nelogați vor vedea stocul din cache până când Cloudflare invalidează pagina. Noi am mutat logica asta pe un micro-call de admin-ajax / REST doar pentru produsele critice.
Marea bubă: wp_postmeta și meta_queries absurde
Dacă ai filtre de produse făcute cu pluginuri generice, uită-te în Query Monitor. O să vezi monștri de interogări cu 5-6 INNER JOIN-uri pe wp_postmeta. Pe o tabelă cu 1.5 milioane de rânduri, asta îngheață procesele MariaDB.
Soluția pe termen lung este activarea High-Performance Order Storage (HPOS) pentru comenzi și trecerea filtrelor pe taxonomii native de produs, nu pe custom fields. Taxonomiile au tabele optimizate de termeni (wp_term_relationships), unde căutările sunt indexate brici.
La voi cum arată setup-ul pe magazine medii spre mari? Mai folosește cineva Varnish în fața lui WooCommerce în 2024 sau ați mers toți pe edge caching?