Če je skrbniški vmesnik WordPress iz meseca v mesec počasnejši, čeprav nisi namestil novega vtičnika, je vredno pogledati tabelo wp_options. WordPress na samem začetku vsake zahteve, še pred predlogo in vtičniki, z eno poizvedbo naloži vse samodejno nalagane (autoload) nastavitve in jih drži v pomnilniku. To se zgodi ob vsakem nalaganju strani, vsaki skrbniški strani, vsaki zahtevi AJAX in vsakem zagonu crona.

To je bilo prvotno zamišljeno za majhne vrednosti: naslov spletnega mesta, aktivna predloga, časovni pas. Veliko vtičnikov pa sem postavi tudi svoj predpomnilnik, dnevnik ali veliko polje nastavitev, tu ostanejo tudi nastavitve odstranjenih vtičnikov. Že megabajt ali dva podatkov autoload opazno upočasni vsako zahtevo. O splošnem vzdrževanju podatkovne baze (revizije, prehodni podatki, vtičniki za čiščenje) govori naš blogovski zapis.

Koliko jih je na tvojem spletnem mestu?

Od WordPressa 6.6 Zdravje spletnega mesta (meni Orodja) opozori, če so samodejno nalagane nastavitve prevelike: „Samodejno naložene možnosti lahko vplivajo na zmogljivost”. Točno število lahko poizveš z WP-CLI:

cd ~/public_html
wp option list --autoload=on --format=total_bytes

Na našem testnem spletnem mestu je to 40775 bajtov, torej približno 40 KB, kar je značilno za sveže spletno mesto. Nekaj sto KB je še v redu, nad 1 MB se je vredno poglobiti, pri več MB pa boš zagotovo nekaj našel. Šteje tudi število vrstic: tudi več tisoč majhnih nastavitev upočasnjuje.

Kaj zaseda prostor?

Največje postavke z WP-CLI:

wp option list --autoload=on --fields=option_name,size_bytes --format=csv | sort -t, -k2 -n -r | head -20

Ali v phpMyAdminu (skupina Podatkovne baze v cPanelu), na zavihku SQL podatkovne baze. Predpono tabel (v primeru 1vL7334_) zamenjaj s svojo; izpiše jo ukaz wp db prefix, vidiš pa jo tudi na seznamu na levi strani phpMyAdmina:

SELECT option_name, autoload, ROUND(LENGTH(option_value) / 1024, 1) AS kb
FROM 1vL7334_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY LENGTH(option_value) DESC
LIMIT 20;

Od WordPressa 6.6 v stolpcu autoload nista le yes in no: on in auto-on sta obvezna, auto pomeni samodejno nalaganje, prepuščeno odločitvi WordPressa, off in auto-off pa nesamodejno. Zato pogoj WHERE autoload = 'yes' starih vodnikov danes izpusti večino postavk.

Imena veliko povedo o svojem lastniku: wf_ je Wordfence, rocket_ WP Rocket, elementor_ Elementor, _transient_ in _site_transient_ sta prehodna podatka (predpomnilnik), cron pa je lasten razpored WP-Cron (pri prometni spletni trgovini je lahko že ta nad 1 MB). V začetek velike vrednosti lahko pogledaš tako, da v terminal ne izpišeš več megabajtov:

wp option get rocket_cache_files --format=json | head -c 500

Seštevek po vtičnikih (po predponi) v SQL:

SELECT SUBSTRING_INDEX(option_name, '_', 2) AS elotag,
       COUNT(*) AS db,
       ROUND(SUM(LENGTH(option_value)) / 1024) AS kb
FROM 1vL7334_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
GROUP BY elotag
ORDER BY kb DESC
LIMIT 20;

Popravek

Pred tem shrani podatkovno bazo. Na strežnikih cPanel aWh wp db export ne deluje, zato uporabi ukaz mysqldump (članek o WP-CLI) ali zavihek Izvoz v phpMyAdminu.

1. Izklopi samodejno nalaganje, kjer ni potrebno

Nastavitev se mora samodejno naložiti le, če je potrebna skoraj ob vsakem nalaganju strani. Kar je potrebno le na strani z nastavitvami ali pri redki nalogi, vtičnik dobi tudi, če se ne naloži vnaprej, le z ločeno poizvedbo:

wp option set-autoload rocket_cache_files off
wp cache flush

Če jo vtičnik ob naslednjem shranjevanju znova zapiše s samodejnim nalaganjem, je to napaka vtičnika; sporoči jo razvijalcu.

2. Izbriši potekle prehodne podatke

WordPress poteklega prehodnega podatka ne izbriše, dokler ga kdo ne poskuša prebrati ali ga ne doseže dnevno čiščenje. Kar ni nikoli več potrebno, lahko ostane notri:

wp transient list --format=count
wp transient delete --expired

Tudi popolno praznjenje (wp transient delete --all) je varno, vtičniki znova zgradijo, kar uporabljajo; prva nalaganja strani so lahko takrat počasnejša.

3. Izbriši nastavitve odstranjenih vtičnikov

Če vtičnika zagotovo ne uporabljaš več in ga ni na seznamu (wp plugin list), lahko njegove nastavitve izbrišeš. Posamično:

wp option list --search="regibovitmeny_*" --fields=option_name,size_bytes
wp option delete regibovitmeny_settings regibovitmeny_cache

V SQL je treba podčrtaj ubežati, ker _ v vzorcu LIKE pomeni poljuben znak:

DELETE FROM 1vL7334_options WHERE option_name LIKE 'regibovitmeny\_%';

Po predponi briši le, če predpona nedvoumno pripada enemu vtičniku; prekratek vzorec lahko odnese tudi nastavitve drugih vtičnikov.

4. Stisni tabelo

Po brisanju se velikost tabele na disku ne zmanjša. V phpMyAdminu označi tabelo wp_options in izberi operacijo Optimiziraj tabelo ali iz ukazne vrstice: mysql "$(wp config get DB_NAME)" -e "OPTIMIZE TABLE $(wp db prefix)options".

Preverjanje in preprečevanje

Znova izmeri (wp option list --autoload=on --format=total_bytes) in poglej stran Zdravje spletnega mesta. Čas nalaganja strani skrbniškega vmesnika je viden tudi na zavihku Omrežje v razvijalskih orodjih brskalnika, sprememba je merljiva že pri zmanjšanju za nekaj sto KB.

Najboljše preprečevanje je brzdanje števila vtičnikov in brisanje (ne le izklop) neuporabljenih vtičnikov. Na pol leta poglej velikost autoload; dodatne nasvete za pospešitev daje članek o pospešitvi WordPressa, druge napihnjene tabele pa obravnavata članka wp_postmeta in Action Scheduler. V naših paketih gostovanje WordPress lahko pri pospešitvi pomaga tudi AccelerateWP.