I dag vil vi tage et kig på wp_options tabellen i din WordPress database. Dette er et område, som ofte bliver overset, når det kommer til den overordnede WordPress- og databaseydelse. Især på ældre og store websteder kan dette være synderen for langsomme forespørgselstider på dit websted på grund af autoloaded data, der efterlades fra tredjeparts plugins og temaer. Tjek disse tips nedenfor om, hvordan du kontrollerer, fejlfinder og rydder op i din wp_options tabel.
Hvad er wp_options-tabellen?
Tabellen wp_options indeholder alle mulige data for dit WordPress-websted, f.eks:
- URL til webstedet, URL til hjemmet, admin e-mail, standardkategori, indlæg pr. side, tidsformat osv
- Indstillinger for plugins, temaer, widgets
- Midlertidigt cachede data
Tabellen indeholder følgende felter, hvoraf vi bekymrer os mere om et af dem, når det drejer sig om ydeevne:
- option_id
- option_name
- option_value
- autoload
En af de vigtige ting at forstå om wp_options tabellen er autoload-feltet. Dette indeholder en yes- eller en mo-værdi (flag). Dette styrer i det væsentlige, om det indlæses af funktionen wp_load_alloptions() eller ej. Autoloaded data er data, der indlæses på hver side på dit WordPress-websted. Ligesom vi viste dig, hvordan du kan deaktivere visse scripts fra at blive indlæst på hele sitet, gælder den samme idé her. Autoload-attributten er som standard indstillet til “yes” for udviklere, men ikke alle plugin bør teoretisk set indlæse deres data på hver side.
Problemet WordPress-websteder kan løbe ind i er, når der er en stor mængde autoloadede data i wp_options-tabellen. Dette er typisk et resultat af følgende:
- Data bliver autoloaded af et plugin, når det i virkeligheden burde være sat til “no” Et godt eksempel på dette ville være et plugin til en kontaktformular. Skal det indlæse data på alle sider eller kun på kontaktsiden?
- Plugins eller temaer er blevet fjernet fra WordPress-webstedet, men deres indstillinger er stadig efterladt i tabellen wp_options. Dette kan betyde, at unødvendige autoloadede data bliver spurgt ved hver forespørgsel.
- Plugin- og temaudviklere indlæser data i wp_options-tabellen i stedet for at bruge deres egne tabeller. Der er argumenter for begge sider af dette, da nogle udviklere foretrækker plugins, der ikke opretter yderligere tabeller. Men wp_options-tabellen blev heller ikke designet til at rumme tusindvis af rækker.
Hvor meget er for meget autoloaded data? Dette kan naturligvis variere, men ideelt set skal det være mellem 300 KB og 1 MB. Når du begynder at nærme dig 3-5 MB eller mere, er der højst sandsynligt ting, der kan optimeres eller fjernes fra autoloaded. Og alt over 10 MB bør behandles med det samme. Det betyder ikke altid, at det vil forårsage et problem, men det er et godt sted at starte.
Fejlfinding af autoloaderede data i wp_options-tabellen
Hvis du oplever langsommelighed på dit WordPress-websted, kan det skyldes en forespørgsel eller autoloaded data, der er efterladt fra et gammelt WordPress-plugin. Nedenfor viser vi dig, hvordan du tjekker den autoloaded størrelse i din database, samt dykker ned i et live-websteds data og deler, hvad vi gjorde for at rense det op.
Kontroller autoloaded datastørrelse
Den første ting at gøre er at kontrollere den aktuelle autoloaded-størrelse på dit WordPress-websted. For at gøre dette skal du logge ind på phpMyAdmin. Klik på din database i venstre side og derefter på fanen SQL-fanen. Indtast derefter følgende kommando, og tryk på “Go”
SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';Du skal muligvis justere forespørgslen ovenfor, hvis dit WordPress-websted bruger et andet præfiks end wp_.
Autoload_size returneres i bytes. Der er 1024 bytes i en KB og 1024 KB i et MB. Så i vores tilfælde er 249.025 bytes lig med 0,25 MB. Så for dette websted er dette en god størrelse! Hvis du returnerer noget under 1 MB, skal du ikke være bekymret. Men hvis resultatet var meget større, skal du fortsætte med denne vejledning.
Nedenfor er et websted, som vi testede, hvor der blev returneret 137.724.715 bytes eller rettere 137 MB. Dette er et godt eksempel på et websted, hvor der helt sikkert er noget galt, eller rettere sagt, der er ting, der skal optimeres.
Du kan også bruge en længere forespørgsel som f.eks. følgende. Dette vil vise dig størrelsen af de autoloaded data, hvor mange poster der er i tabellen, og de første 10 poster efter størrelse.
SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM wp_options WHERE autoload='yes'
UNION
SELECT 'autoloaded data count', count(*) FROM wp_options WHERE autoload='yes'
UNION
(SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 10)
Hvis du har adgang til New Relic (licens påkrævet), kan du også bruge det til at hjælpe med at fejlfinde forespørgsler, der er forbundet med wp_options-tabellen. Fanen databaser vil pege på den tabel og den type forespørgsel, der bruger mest tid. Hvis du vælger en af posterne på listen, kan du se flere detaljer, herunder nogle prøveforespørgsler. I eksemplet nedenfor kan du se, at dataene peger på autoloaded data i tabellen wp_options. En hurtig analyse af det pågældende websted bekræftede ganske rigtigt næsten 250 MB autoloaded data.
Sortere top autoloaded data
Det næste skridt ville være hurtigt at sortere de øverste elementer med autoloaded data. Her er en hurtig SQL-kommando, som du kan bruge til at liste de 10 bedste:
SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 10;Igen, du skal muligvis justere forespørgslen ovenfor, hvis dit WordPress-websted bruger et andet præfiks end wp_.
Grave ind i individuelle autoloaded data i wp_options
Det næste skridt var at grave i nogle af de øverste autoloaded data.
301_redirects
Som vi kan se ovenfor, er den øverste autoloaded indstilling 301_redirects. Dette er sandsynligvis direkte relateret til et omdirigeringsplugin på webstedet eller WordPress SEO-plugin, som også har en omdirigeringfunktion. I dette tilfælde er den bedste anbefaling faktisk at implementere omdirigeringerne på serverniveau.
Hvorfor? Fordi brugen af gratis WordPress-plugins til at implementere omdirigeringer nogle gange kan forårsage problemer med ydeevnen, da de fleste af dem bruger wp_redirect-funktionen, som kræver yderligere kodeudførelse og ressourcer. Og selvfølgelig autoloader den også data til tabellen wp_options.
Hvis du er en Kinsta-klient, kan du nemt tilføje omdirigeringer på serverniveau ved hjælp af værktøjet omdirigeringsregler på dit MyKinsta-dashboard. Dette er ikke kun bedre for ydeevnen, men du har også et plugin mindre at bekymre dig om!
wpurp_custom_template_
Den næste top autoloaded dataindstilling var wpurp_custom_template_#. Vi kan se, at der er en hel del forskellige rækker for dette. Typisk bør du være i stand til at finde dette optionsnavn og forbinde prikkerne ved at kigge i din temaer eller plugins-mappe. I dette tilfælde lavede vi en grep-kommando fra serveren for at se, om vi kunne finde det. Du kan også stikprøvevis tjekke det via SFTP.
grep -Ri "wpurp_custom_template_"Ovenstående kommando gav dog ikke noget tilbage, og derfor gik vi over til Google og foretog en søgning. Vi fandt hurtigt ud af, at det var relateret til et WordPress-plugin, der ikke længere var installeret på webstedet, kendt som WP Ultimate Recipe. Dette er et klassisk eksempel på unødvendige autoloaded data, der er efterladt. Vi har en lang vejledning om, hvordan man afinstallerer WordPress-plugins (på den rigtige måde). Og med korrekt mener vi, at vi rent faktisk rydder op i det, der er efterladt.
um_cache_userdata_
Den næste top autoloaded dataoption var um_cache_userdata_#. Vi kan se, at der er en hel del forskellige rækker for dette. Da dette var mod bunden, ændrede vi hurtigt vores MySQL-kommando til at vise de 40 øverste autoloaded data:
SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 40;Eller summe alle værdier med dette præfiks:
SELECT 'sum size in KiB', ROUND(SUM(length(option_value))/1024,0) FROM wp_options WHERE autoload='yes' AND option_name like "um_cache_userdata_%"Vi kunne se, at der var mange flere poster for um_cache_userdata_# i tabellen wp_options. Vi kørte igen en grep-kommando for at tjekke vores plugins og tema-mapper.
grep -Ri "um_cache_userdata_"Vi var derefter i stand til hurtigt at identificere dette som værende relateret til Ultimate Member-plugin. En anden hurtig Google-søgning gav et par gode løsninger på dette problem (se supportartiklen). Undervurder aldrig kraften af en Google-søgning! Det viste sig, at der var et par forskellige muligheder i pluginet for at løse dette problem.
- Ultimativt medlem > Dashboard > Brugercache > Ryd cachen.
- Ultimate Member -> Indstillinger -> Avanceret -> Stop caching af brugerens profildata (skift til ON), og gem derefter ændringer.
En anden mulighed for at se, hvad en autoloaded indstilling er, er ved at trykke på redigeringsknappen, og dette kan angive mappen for plugin/tema eller angive udviklerens websted.
Cron Jobs
En anden hyppig mulighed, som vi ser med en stor mængde autoloaded data, er cron. For dette kan det være alt cron-relateret. Så det du kan gøre er at trykke på knappen “rediger” for at se, hvad der forårsager det. Her er et eksempel nedenfor, hvor det var tydeligt, at “do_pings” var årsag til problemet. Igen, en hurtig Google-søgning afslørede en hurtig løsning til at rydde op i do_pings.
Oprydning wp_options tabel
Hvis du ser en masse af det, vi nævnte ovenfor, så er det sandsynligvis tid til en oprydning af alle de autoloaderede data i din wp_options tabel. Det anbefales også, at du forsøger at holde antallet af rækker i din wp_options tabel på et minimum. Tag altid backups, før du sletter data i din database. Hvis du ikke er tryg ved at gøre dette selv, anbefaler vi altid at hyre en WordPress-udvikler. Dette er også et godt scenarie, hvor et scene-miljø kan være praktisk.
Ligesom vi gjorde tidligere, skal du logge ind på phpMyAdmin. Klik på din database i venstre side og derefter på fanen SQL-fanen. Indtast derefter følgende kommando, og tryk på “Go”
SELECT * FROM `wp_options` WHERE `autoload` = 'yes'Du skal muligvis justere forespørgslen ovenfor, hvis dit WordPress-websted bruger et andet præfiks end wp_. Dette vil vise dig alle data i tabellen wp_options, der er indstillet til autoload.
Når vi ruller ned gennem rækkerne, ser vi alle mulige plugins, der ikke længere er installeret eller anvendes af webstedet. Dette er blot et eksempel, som vi vil bruge, men i dette tilfælde bemærkede vi en masse Jetpack-rækker. Jetpack blev ikke længere brugt på det pågældende websted.
Det er altid godt at tjekke plugin-udviklerens dokumentation, da de nogle gange har en mulighed for at rydde op i deres efterladte tabeller. I så fald er det nogle gange sikrere og nemmere blot at installere pluginet igen, kontrollere deres automatiske oprydningsmulighed og derefter fjerne pluginet korrekt. Vi vil dog vise dig, hvordan du rydder op i tabellerne manuelt.
Så i dette tilfælde kører vi følgende forespørgsel for at finde de autoloaderede data i tabellen wp_options fra Jetpack-plugin’et. Hvis du vil ændre forespørgslen med din egen, skal du blot erstatte %jetpack%.
SELECT *
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%jetpack%'Du kan derefter vælge alle rækkerne og klikke på “Delete”
Eller du kan køre følgende kommando:
DELETE
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%jetpack%'
Du kan derefter skylle og gentage for yderligere autoloaded data, der er efterladt af plugins og temaer i din wp_options tabel.
Ryd op i Transients
Medmindre du bruger en objektcache, gemmer WordPress midlertidige poster i wp_options-tabellen. Typisk får disse en udløbstid og bør forsvinde med tiden. Det er dog ikke altid tilfældet. Vi har set nogle databaser, hvor der er tusindvis af gamle transient records. Det er også vigtigt at bemærke, at transients ikke er til autoloaded som standard. Du kan bruge en forespørgsel som nedenstående for at se, om der er autoloaderede transient data.
SELECT *
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%transient%'En bedre og sikrere løsning ville dog være at bruge et gratis plugin som Transient Cleaner, som kun kan rydde op i de udløbne transients fra din wp_options tabel.
Ryd op i WordPress-sessioner
Et andet almindeligt problem, som vi har set, er nogle gange cronjobs bliver ude af synkronisering eller ikke fyres korrekt, og derfor bliver sessioner ikke ryddet op. Du kan ende med at få tonsvis af _wp_session_ rækker i din database. I dette eksempel nedenfor endte det pågældende websted med over 3 millioner rækker i deres wp_options tabel. Og tabellen var vokset til over 600 MB i størrelse.
Du kan bruge en forespørgsel som den nedenfor for at se, om du løber ind i dette problem:
SELECT *
FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'
I de fleste tilfælde kan du derefter sikkert slette disse (som et cron job burde have) med følgende kommando:
DELETE FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'Efter oprydning af alle de resterende _wp_session_ rows havde tabellen mindre end 1.000 rækker og blev reduceret til 11 MB i størrelse.
Det løste også spikes, som webstedet fik i MySQL.
Tilføj et indeks til autoload
Og hvis det ikke var nok at rydde op i din wp_options-tabel, kan du prøve at tilføje et “indeks” til autoload-feltet. Dette kan i det væsentlige hjælpe det til at blive søgt mere effektivt. Det fantastiske team hos 10up udførte nogle testscenarier på en wp_options tabel med et typisk antal autoloaded poster for at vise, hvordan tilføjelse af et autoload indeks til wp_options forespørgsler kan øge ydeevnen.
Vi anbefaler også at tjekke disse to yderligere ressourcer fra WP Bullet:
- Sådan tilføjes MySQL Index til wp_options tabel
- Oprydning af wp_options tabellen ved hjælp af WP-CLI
For endnu flere optimeringstips skal du sørge for at tage et kig på vores dybdegående guide: Sådan fremskynder du dit WordPress-websted (ultimativ guide)
