add_filter( 'query', function( $query ) {
// Oprește rularea query-urilor masive generate de căutările interne dacă depășesc limita
if ( ! is_admin() && strpos( $query, 'SQL_CALC_FOUND_ROWS' ) !== false && strpos( $query, 'post_type = \'product\'' ) !== false ) {
// Eliminăm SQL_CALC_FOUND_ROWS din paginarea WooCommerce pentru a reduce sarcina pe DB
$query = str_replace( 'SQL_CALC_FOUND_ROWS', '', $query );
}
return $query;
}, 10, 1 );Toată lumea vrea magazine rapide pe WooCommerce, dar majoritatea se opresc la instalat un plugin de caching generic și speră la o minune. Dacă ai un magazin cu 200 de produse merge, însă la un client cu 14.000 de SKU-uri și 80 de comenzi pe oră în orele de vârf, pagina de checkout și căutările îți pun serverul în genunchi în 10 minute.
Am preluat acum câteva luni o platformă unde fiecare click pe filtru dura 3-4 secunde. TTFB-ul pe paginile dinamice bătea lejer spre 2.1s pe un VPS generos cu 8 vCPU și 16GB RAM. Problema n-a fost fierul, ci cum comunicau WordPress și MariaDB.
1. Redis Object Cache: Salvarea serverului, dar atenție la RAM
Fără persistent object cache, WordPress interoghează baza de date pentru orice fleac de opțiune sau sesiune. Adăugarea Redis-ului prin extensia pecl-redis și un drop-in calitativ (folosesc pluginul Redis Object Cache de la Till Krüss) a tăiat din start 60% din SQL queries per request.
Dar am pățit-o la început: dacă nu cureți transient-urile sau lași WooCommerce să bage sesiuni expirate în Redis, te trezești că serverul dă OOM (Out Of Memory) fără avertisment. Redis ține totul în memorie volatilă. Trade-off-ul e direct: obții interogări la 0.2ms pe datele repetitive, dar dacă ai un catalog mare cu atribute custom nestructurate, trebuie să mărești maxmemory și să setezi allkeys-lru ca politică de eliminare, altfel Redis refuză scrierile noi exact când ai vânzări mari.
2. Cloudflare APO: Caching complet de pagină la nivel de rețea
Mulți încearcă pluginuri locale de page cache (WP Rocket, LiteSpeed), dar pentru WooCommerce, Cloudflare Automatic Platform Optimization (APO) e cel mai eficient compromis cost/performanță. Costă 5 dolari pe lună și servește paginile de categorie și produsele direct din nodul Cloudflare din București sau Frankfurt.
Cum funcționează de fapt? APO știe din oficiu cookie-urile native WooCommerce: woocommerce_items_in_cart și wp_woocommerce_session_*. Cât timp userul doar navighează pe site, primește HTML-ul static în ~40ms. Când a adăugat un produs în coș, Cloudflare detectează cookie-ul și dă bypass automat la cache, trimițând cererile către origin.
Singurul dezavantaj e la stocuri dinamice foarte agresive: dacă schimbi prețul frecvent sau stocul se termină într-un minut, edge-ul Cloudflare poate servi pagina veche până când se propagă webhook-ul de purjare. La Black Friday a trebuit să setez TTL-ul la doar 30 de minute.
3. Curățarea interogărilor criminale din wp_postmeta
Niciun Redis din lume nu te salvează dacă tema sau pluginurile de filtre fac interogări cu JOIN pe wp_postmeta după chei multiple fără index. La magazinul de care ziceam, tabela wp_postmeta avea peste 4.2 milioane de rânduri.
Am descoperit că pluginul lor de filtrare rula o interogare SELECT cu 9 JOIN-uri succesive la fiecare paginare. Soluția temporară a fost crearea unui index combinat pe meta_key și post_id, iar soluția definitivă a fost activarea tabelelor custom High-Performance Order Storage (HPOS) din WooCommerce și rescrierea căutărilor grele prin hook-uri dedicate.
De asemenea, sesiunile vechi din tabela wp_woocommerce_sessions erau neșterse de luni de zile. Am curățat aproape 800.000 de rânduri orfane folosind un cron job nocturn.
Voi cum gestionați transient-urile WooCommerce când Redis începe să se umple: script separat de cron sau lăsați fallback pe baza de date?