Drie plugins, geen schuldige: van 13 naar 1,6 seconden

Het dashboard bleek 13,6 seconden nodig te hebben. Na één kleine ingreep was dat 1,6 seconden. De oorzaak was geen enkele slechte plugin, maar drie plugins die elk iets redelijks deden en samen in een kringetje terechtkwamen.

Eerst de gewone verdachten, en die vielen allemaal af. De automatisch geladen instellingen in de database waren netjes (317 KB, ruim onder de grens waar WordPress voor waarschuwt). De database zelf deed 0,3 seconde. En er draaide een snelle geheugencache (Redis), die volgens de plugin “verbonden” was, zonder fouten.

De plugin Query Monitor liet zien waar de tijd wél zat. Bij elke keer dat het dashboard laadde, deed WordPress 22 verzoeken naar andere servers: controleren of er updates zijn, of er vertalingen zijn, of een licentie nog geldig is. Samen ruim 7 seconden wachten. Zulke controles doet WordPress normaal hooguit een paar keer per dag, want het onthoudt de uitkomst. Hier onthield de site blijkbaar niets.

Het bewijs was eenvoudig. Ik zette via de opdrachtregel een testwaarde in de cache en vroeg hem meteen daarna terug. Weg. Met alle plugins uitgeschakeld bleef hij wél staan. Er maakte dus iets de cache leeg, bij elke start van WordPress.

Daarna volgde ik het spoor tot het moment waarop het gebeurde, met een klein stukje code dat alleen meekijkt. Dat liet de kringloop zien:

1. Het thema (Botiga Pro) wil één keer de adresregels van de site laten herberekenen. Om te onthouden dat het dat gedaan heeft, legt het een geheugensteuntje neer, in de cache. 2. Tijdens dat herberekenen maakt een plugin voor productadressen (Premmerce Permalink Manager) de hele cache leeg. 3. Daarmee is ook het geheugensteuntje van het thema weg. Bij het volgende verzoek denkt het thema: dat heb ik nog niet gedaan. En zo begint het opnieuw.

Zonder die snelle cache was er niets aan de hand geweest: het geheugensteuntje stond dan in de database, en daar komt de plugin niet aan. De cache die het sneller had moeten maken, maakte de kringloop pas mogelijk.

De oplossing is één regel code, in een eigen klein bestand, zonder iets aan het thema, de plugin of de cache te veranderen. Die regel zegt tegen het thema: je geheugensteuntje staat er. Dat is precies wat het thema zelf bedoelt, want het wil de adresregels maar één keer herberekenen.

Het resultaat: het dashboard ging van 13,6 naar 1,6 seconden, met nul verzoeken naar buiten. Een gewone productpagina die vers wordt opgebouwd, ging van 4,9 naar 1,8 seconden.

Wat ik ervan leer

“Verbonden, geen fouten” zegt niet dat een cache werkt. Het zegt dat hij bereikbaar is. Of hij iets onthoudt, meet je door er iets in te zetten en het terug te vragen.

En: bij een probleem tussen plugins is er niet altijd een schuldige. Het thema en de adressenplugin doen elk iets verdedigbaars. Pas de combinatie met een cache maakt er een kringloop van. Iemand anders meldde hetzelfde probleem al eens bij de makers van de adressenplugin, zonder dat de oorzaak werd gevonden.

Onderweg ging ik ook één keer de mist in. Mijn eerste proef om de schuldige aan te wijzen (steeds één plugin overslaan en kijken of de testwaarde bleef staan) wees eerst de adressenplugin aan, en bij een tweede ronde tien willekeurige andere. Op een live site komen er tussendoor gewoon bezoekers, bots en geplande taken langs, en die maakten de cache ook leeg. Een proef die van toeval afhangt, wijst niemand aan. Het meekijkende stukje code wel.

add_action( 'init', array( $this, 'flush_rewrite_rules' ), 999 );

public function flush_rewrite_rules() {
    if ( ! get_transient( 'botiga_templates_flushed_rules') ) {
        flush_rewrite_rules();
        set_transient( 'botiga_templates_flushed_rules', true, 0 );
    }
}

add_filter( 'rewrite_rules_array', array( $this, 'addRewriteRules' ), 99 );

public function addRewriteRules( $rules ) {
    // ...
    wp_cache_flush();

add_filter( 'pre_transient_botiga_templates_flushed_rules', '__return_true' );