Vandaag gaan we dieper in op de wp_options tabel van je WordPress database. Dit is een terrein dat vaak vergeten wordt als het gaat om de prestaties van je WordPress site en je database. Een slecht onderhouden database kan zorgen voor langzame aanvragen (Engels: queries) door de grote hoeveelheid autoloaded data van plug-ins en thema’s. Daardoor speelt dit probleem vaak bij oudere en grotere websites. Lees daarom nu deze tips om problemen met je wp_options tabel te checken, diagnosticeren en op te lossen.

Wat is de wp_options tabel?

De wp_options tabel bevat verschillende soorten data van je WordPress website, zoals:

  • Website URL, homepage URL, e-mail van de admin, standaardcategorieën, hoeveelheid artikelen per pagina, tijdsindeling, etc.
  • Instellingen voor plug-ins, thema’s, widgets
  • Tijdelijk gecachete data
wp_options tabel

wp_options tabel

De tabel bevat de volgende velden, waarbij sommigen belangrijker zijn dan anderen als het gaat om de prestaties van je WordPress website:

  • option_id
  • option_name
  • option_value
  • autoload
wp_options tabel autoload

wp_options tabel autoload

Een van de belangrijkste dingen om in de gaten te houden in de wp_options tabel is het autoload veld. Deze bevat een ‘yes’ of ‘no’ waarde. Dit veld is belangrijk, want een ‘yes’ zorgt ervoor dat de bijbehorende functie automatisch geladen wordt door de wp_load_alloptions() functie. Automatisch geladen data is data dat geladen wordt op elke pagina van je WordPress website. We hebben je laten zien hoe je kan voorkomen dat bepaalde scripts op elke pagina van je website geladen worden. We kunnen we hetzelfde toepassen op de wp_options tabel. Standaard staat elke plug-in op autoload, maar dit is lang niet voor elke plug-in nodig. Problemen kunnen ontstaan wanneer de wp_options tabel teveel automatisch geladen data bevat. Dit heeft vaak de volgende oorzaken:

  • Data van een bepaalde plug-in staat op autoload, terwijl dit eigenlijk op ‘no’ moet staan. Een goed voorbeeld is de Contact Form plug-in. Is het echt nodig om deze data op elke pagina te laden of volstaat alleen de ‘contact’ pagina?
  • Plug-ins of thema’s zijn verwijderd van de WordPress website, maar de options zijn achtergebleven in de wp_options tabel. Dit kan betekenen dat elke keer nutteloze data wordt aangevraagd, wanneer iemand je website een verzoek doet.
  • Plug-in- en themaontwikkelaars gebruiken de wp_options tabel om hun data te laden in plaats van hun eigen tabel. Dit heeft voor- en nadelen en sommige ontwikkelaars kiezen er simpelweg voor om geen extra tabellen aan te maken en alles binnen wp_options te houden. Het is echter wel zo dat de wp_options tabel niet is gemaakt om duizenden rijen te faciliteren.

Wat is teveel autoloaded data? Dit hangt er natuurlijk van af, maar idealiter wil je tussen de 300KB en 1MB zitten. Zodra je rond de 3-5MB zit, zijn er waarschijnlijk een aantal dingen uit de wp_options tabel die je kan optimaliseren of verwijderen. Wanneer je boven de 10MB uitkomt, doe je er verstandig aan er meteen naar te kijken.

Problemen oplossen met autoloaded data in de wp_options tabel

Als je WordPress trager is dan je gewend bent, dan kunnen autoloaded data en verzoeken van een oude, inmiddels verwijderde, WordPress plug-in de oorzaak zijn. Hieronder laten we je zien hoe je de deze autoloaded data kan vinden en tonen we een voorbeeld van hoe we de database van een bestaande website hebben opgeschoond.

Check de grootte van de autoloaded data

Het eerste dat we uitleggen is hoe je de huidige hoeveelheid autoloaded data van je WordPress website opzoekt. Dit kan je doen door in te loggen bij phpMyAdmin. Klik op je database aan de linkerkant en daarna op het SQL tabblad. Vul onderstaand commando in en klik vervolgens op ‘Go’.

SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';

Er is een kleine kans dat je een wijziging moet aanbrengen in de code als je WordPress een ander voorvoegsel gebruikt dan ‘wp_’.

autoload grootte verzoek in phpMyAdmin

autoload grootte verzoek in phpMyAdmin

De grootte van de autoload data krijg je terug in bytes. Er zitten 1.024 bytes in een KB en 1.024KB in een MB. In ons geval gaat het om 249.025 bytes wat ongeveer 0.25MB is. Onze database heeft dus een prima grootte! Als de output onder de 1MB uitkomt, hoef je je geen zorgen te maken. Kom je boven de 1MB uit, ga dan verder met deze tutorial.

Autoloaded data: dit is prima

Autoloaded data: dit is prima

Hieronder vind je een geteste website met 137.724.715 aan bytes oftewel 137MB. Dit is een goed voorbeeld van een website waar iets mis mee is en waar we dingen kunnen optimaliseren.

Niet goed: veel autoloaded data in de wp_options tabel

Niet goed: veel autoloaded data in de wp_options tabel

Je kan ook een langer verzoek indienen, zoals het verzoek hieronder. Door middel van deze code kom je erachter hoeveel autoloaded data je hebt, hoeveel ingevoerde code de tabel bevat en de eerste 10 codes met hun grootte.

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)
Gedetailleerde autoloaded data MySQL code

Gedetailleerde autoloaded data MySQL code

Als je toegang hebt tot New Relic, dan kan je deze ook gebruiken om problemen op te lossen met de wp_options tabel. Het databases tabblad wijst je op de tabellen en het soort verzoeken die je WordPress website het meest vertragen. Wanneer je een entry in de lijst aanklikt, krijg je meer informatie te zien, waaronder een voorbeeldaanvraag. In het voorbeeld hieronder, kan je zien dat er wordt verwezen naar autoloaded data uit je wp_options tabel. Na korte analyse komen we erachter dat deze specifieke website bijna 250MB aan autoloaded data heeft!

New Relic langzame aanvragen in wp_options tabel

New Relic langzame aanvragen in wp_options tabel

Sorteren van Autoloaded Data

De volgende stap is om de lijst met autoloaded data te sorteren op grootte. Hier is een korte SQL code die je kan gebruiken om de top 10 grootste autoloaded data te krijgen:

SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 10;

Nogmaals, als je WordPress site met een andere prefix dan ‘wp_’ werkt, dan moet je dit gedeelte wijzigen.

Top autoloaded data in de wp_options tabel

Top autoloaded data in de wp_options tabel

Nadere bestudering van individuele Autoloaded Data in wp_options

In de volgende stap gaan we de individuele autoloaded data nader bestuderen.

301_redirects

Zoals je ziet is de nummer 1 van de lijst met autoloaded data ‘301_redirects’. Omdat we gesorteerd hebben op grootte is dit ook meteen de grootste. Dit bestaand is waarschijnlijk direct gerelateerd aan een zogenaamde verwijzingsplug-in die de website gebruikt, of de WordPress SEO plug-in, welke in feite ook een verwijzingsplug-in is. In dit geval zouden we voorstellen om de verwijzingen op serverniveau te doen, in plaats van vanuit de wp_options tabel.

De reden dat we dit willen doen is omdat deze gratis WordPress verwijzingsplug-ins soms voor prestatieproblemen zorgen doordat ze gebruik maken van de wp_redirect functie. Dit zorgt er op zijn beurt weer voor dat aanvullende codes en hulpmiddelen worden opgevraagd. Daarnaast is het ook zo dat deze ‘301_redirects’ een grote hoeveel aan autoloaded data in je wp_options tabel plaatst.

Als je klant bent van Kinsta, dan kan je deze verwijzingen eenvoudig naar serverniveau tillen met onze redirect rules tool. Niet alleen zal je website beter presteren, maar je hebt ook potentieel een plug-in minder die voor problemen kan zorgen!

Verwijzingsregels toevoegen in MyKinsta

Verwijzingsregels toevoegen in MyKinsta

wpurp_custom_template_

De nummer twee van onze lijst met autoloaded data is ‘wpurp_custom_template_#’. Deze neemt een groot aantal rijen in beslag. Normaal gesproken zou je in staat moeten zijn om de naam van een option te koppelen aan een plug-in of thema als je kijkt in de lijst met thema’s en plug-ins. In dit geval verzonden we een grep opdracht naar de server om de naam van de bijbehorende plug-in of het thema vinden. Als alternatief kan je via SFTP verbinding maken en het handmatig bekijken.

grep -Ri "wpurp_custom_template_"

Bovenstaande opdracht bracht helaas geen oplossing, dus gingen we naar Google voor een zoekopdracht. We kwamen er snel achter dat de data afkomstig was van de Ultimate Recipe plug-in, die we al lang geleden verwijderd hadden. Dit is een schoolvoorbeeld van compleet onnodige achtergebleven autoloaded data. Wil je weten hoe je je plug-ins écht verwijderd, zonder dat deze potentieel vertragende dingen achterlaat? Lees dan onze uitgebreide tutorial waarin we beschrijven hoe je WordPress plug-ins op de juiste manier verwijderd.

wpurp_custom_template_

wpurp_custom_template_

um_cache_userdata_

De volgende option die we tegenkwamen was um_cache_userdata_#. Ook hier zien we dat deze een aantal rijen in beslag neemt. Omdat we al redelijk aan de onderkant zitten van onze top10, willen we de lijst uitbreiden naar de top40. Hiervoor gebruikten we de volgende SQL opdracht:

SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 40;

Hieronder vind je een alternatieve opdracht waarmee je een opsomming krijgt van de waarden met deze prefix:

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_%"

We zien dat meteen dat er nog veel meer options met deze ‘um_cache_userdata_#’ prefix in de wp_options tabel te vinden zijn. Opnieuw stuurden we een grep opdracht naar de server om de bijbehorende plug-in of thema te vinden:

grep -Ri "um_cache_userdata_"

Dit keer hadden we meer geluk en konden we onze data koppelen aan de Ultimate Member plug-in! Een snelle zoekopdracht via Google gaf ons een aantal oplossingen voor dit probleem (lees het supportartikel). Onderschat de kracht van een simpele Google-zoekopdracht nooit! Het blijkt dat er verschillende alternatieven zijn om binnen deze plug-in het probleem op te lossen.

  • Ultimate Member > Dashboard > User Cache > Clear Cache.
  • Ultimate Member -> Settings -> Advanced -> Stop caching user’s profile data (switch to ON), then Save Changes.

Een andere mogelijkheid om erachter te komen of een option autoloaded is, is door op de ‘Edit’ knop te klikken. Dit laat de map zien waar de plug-in zich bevindt of de website van de ontwikkelaar.

Cron Jobs

Een andere veelvoorkomende option met autoloaded data is cron. In ons geval kan het alles zijn dat met cron te maken heeft. Om een beter idee te krijgen waar we kunnen optimaliseren, kan je op de ‘Edit’ knop klikken. In het voorbeeld hieronder is het meteen duidelijk dat ‘do_pings’ de dader was. Ook in dit geval gaf Google uitkomst en we vonden al snel een oplossing om ‘do_pings’ op te schonen.

cron - do_pings

cron – do_pings

wp_options tabel opschonen

Het is een goed idee om je tabel op te schonen als jouw resultaten (enigszins) overeenkomen met de onze. Dit doen we door de autoloaded data van je wp_options tabel op te schonen. Het is daarnaast aan te bevelen om het aantal options in je wp_options tabel tot een minimum te beperken. Zorg er alsjeblieft voor dat je altijd back-ups maakt voordat je data verwijderd uit je database. Als je het liever aan iemand anders overlaat, dan kan je altijd overwegen een WordPress ontwikkelaar in te schakelen. Dit is ook een goed moment om binnen een testomgeving te werken. Klanten van Kinsta kunnen gratis in een testomgeving werken en op elk moment hun echte website vervangen met de testomgeving.

Net al we eerder deden, moeten we inloggen bij phpMyAdmin. Vul dan de volgende opdracht in en klik op ‘Go’:

SELECT * FROM `wp_options` WHERE `autoload` = 'yes'

Ook hier moet je misschien de opdracht aanpassen als jouw WordPress website met een andere prefix begint dan ‘wp_’. Bovenstaande opdracht zorgt ervoor dat je alleen autoloaded data ziet uit je wp_options tabel.

Autoloaded data vinden in wp_options

Autoloaded data vinden in wp_options

Wanneer je door deze lijst scrolt, kom je waarschijnlijk allerlei plug-ins tegen die niet meer gebruikt worden door de website. In ons specifieke voorbeeld is dat de Jetpack plug-in die een aantal rijen in beslag neemt. Op onze website was de Jetpack plug-in niet langer in gebruik.

Oude autoloaded data

Oude autoloaded data

Je doet er altijd verstandig aan om de documentatie van je plug-in te raadplegen. Soms bieden ze je namelijk de mogelijkheid om hun plug-in te verwijderen inclusief de data in de wp_options tabel. Mocht dit zo zijn, dan is het veiliger en ook veel makkelijker om de desbetreffende plug-in opnieuw te installeren om deze vervolgens te verwijderen, gebruikmakend van de optie om dit veilig te doen. Omdat niet elke plug-in deze optie biedt, laten we je hieronder zien hoe je dit handmatig kan doen.

In ons geval willen we de autoloaded data van de Jetpack plug-in vinden in de wp_options tabel. Dit doen we door de volgende opdracht in te voeren. Om je eigen plug-in te vinden, kan je %jetpack% vervangen met de naam van je eigen plug-in:

SELECT * 
FROM `wp_options` 
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%jetpack%'

Vervolgens selecteer je alle rijen en klik je op ‘Delete’.

Verwijder autoloaded rijen

Verwijder autoloaded rijen

Een alternatief is om de volgende opdracht uit te voeren:

DELETE
FROM `wp_options` 
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%jetpack%'
Delete autoloaded data in de wp_options tabel

Delete autoloaded data in de wp_options tabel

Dit proces kan je herhalen voor elke verwijderde plug-in en thema die data heeft achtergelaten in je wp_options tabel.

Opschonen van tijdelijke data

Behalve wanneer je gebruikt maakt van object caching, bewaart WordPress tijdelijke data in de wp_options tabel. Doorgaans bevat deze data een houdbaarheidsdatum en zullen ze dus op den duur verwijderd worden. Toch is dit niet altijd het geval. We hebben databases gezien met duizenden rijen verlopen data. Het is belangrijk om te weten dat tijdelijke data normaal gesproken niet automatisch wordt geladen. Met onderstaande opdracht kan je erachter komen of er tijdelijke autoloaded data in je wp_options tabel zit:

SELECT * 
FROM `wp_options` 
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%transient%'

However, a better and safer option would be to utilize a free plugin like Transient Cleaner which can clean up only the expired transients from your wp_options table.

Toch is er een betere optie. Met de gratis Transient Cleaner plug-in kan je verlopen tijdelijke data makkelijk uit je wp_options tabel halen.

Opschonen van WordPress sessies

Een ander veelvoorkomend probleem is dat cron jobs niet synchroon lopen of niet (op tijd) uitgevoerd worden. Hierdoor kan het zo zijn dat bepaalde sessies niet opgeschoond worden. Hierdoor kan je een enorme hoeveelheid aan _wp_session_ rijen in je database krijgen. In het voorbeeld hieronder vind je een website die meer dan 3 miljoen rijen in de wp_options tabel had. Niet vreemd dus dat deze tabel over de 600MB was!

wp_options tabel met miljoenen rijen

wp_options tabel met miljoenen rijen

Door middel van onderstaande opdracht kan je erachter komen of je tabel ook een dergelijk probleem heeft:

SELECT * 
FROM `wp_options` 
WHERE `option_name` LIKE '_wp_session_%'
wp_session rows

_wp_session_ rows

In de meeste gevallen kan je deze data veilig verwijderen (wat een cron job eigenlijk al gedaan zou moeten hebben) met de volgende opdracht:

DELETE FROM `wp_options` 
WHERE `option_name` LIKE '_wp_session_%'

Na het opschonen van de _wp_session_ rows the table had less than 1,000 rows and was reduced to 11 MB in size.

WP sessions opgeruimd

WP sessions opgeruimd

Door het opschonen van de database kregen we ook geen MySQL pieken meer in de website!

MySQL web transactions

MySQL web transactions

Een index toevoegen aan autoload

Als het opschonen van de wp_options tabel niet genoeg was, dan kan je ook nog proberen een ‘index’ toe te voegen aan het autoload veld. Simpel gezegd kan de rij daardoor makkelijker opgezocht worden. Het team van 10up heeft enkele tests uitgevoerd die de resultaten laat zien van het toevoegen van een index aan de wp_options tabel.

wp_options aanvraagsnelheid

wp_options aanvraagsnelheid (Bron: 10up)

We bevelen van harte de volgende twee handleidingen aan van WP Bullet:

12
keer gedeeld