English
Deutsch
PolskiAutoload w WordPressie: wartości kolumny autoload i zapytanie, które nadal je znajduje
Spis treści
Każda strona tego bloga zaczyna się od tego samego zapytania do bazy, wysłanego zanim WordPress w ogóle wie, o którą stronę chodziło: czyta zestaw ustawień, których spodziewa się potrzebować.
O tym, które ustawienia należą do tego zestawu, rozstrzyga jedna kolumna o nazwie autoload. Kolumna ta dostała w ostatnich wersjach nowe wartości, a zapytanie polecane przez niemal każdy starszy poradnik nie zwraca dziś nic.
Co autoload naprawdę robi
WordPress trzyma swoje ustawienia w jednej tabeli. Każdy wiersz niesie nazwę, wartość i adnotację, czy wartość ma przyjść automatycznie.
Oznaczenie pozwala ograniczyć liczbę zapytań do bazy danych. Zamiast pobierać każde ustawienie osobno, gdy jest potrzebne, WordPress ładuje razem wszystkie wartości oznaczone do automatycznego ładowania i przechowuje je w pamięci do końca żądania.
Ta zamiana ma swoją cenę. To, co nosi oznaczenie, podróżuje przy każdym pojedynczym wywołaniu – na stronach, które nigdy go nie dotykają, przy plikach wydawanych przez PHP, przy każdej wizycie każdego crawlera.
Trzy wartości w kolumnie, cztery liczą się jako ładowane
Dawniej kolumna była prosta. Stało w niej yes albo no i znaczenie obu było jednoznaczne. Od wersji 6.6 możliwości jest więcej.
on i off to odpowiedzi wyraźne: coś zażądało, żeby wartość była ładowana, albo zażądało, żeby nie była.
auto-on i auto-off znaczą: nikt nie pytał, a WordPress rozstrzygnął.
auto znaczy: nikt nie pytał i WordPress też nie rozstrzygnął.
Które wartości liczą się jako ładowane, stoi w kodzie źródłowym jako funkcja wp_autoload_values_to_autoload() i wymienia ona cztery: yes, on, auto-on i auto. Reszta zostaje na dysku, dopóki coś nie zażąda jej po nazwie.
Dlaczego stare zapytanie nic nie znajduje
Linijka, która pojawia się w poradniku za poradnikiem, brzmi SELECT option_name FROM wp_options WHERE autoload = 'yes'.
Zastosowana do tej strony zwraca zero wierszy przy 1290 opcjach – podczas gdy 155 z tych opcji jest faktycznie czytanych przed każdą stroną. Kolumna prowadzi tutaj wyłącznie off, on i auto. Wartość yes nie występuje nigdzie.
Nic o tym nie ostrzega. Nie ma błędu ani komunikatu, a pusty wynik wygląda dokładnie tak samo jak czysta diagnoza. Sprawdzana w ten sposób strona przez lata sprawia wrażenie, jakby w ogóle nie miała ładowanych opcji.
Zapytanie, które nadal działa, wymienia wszystkie cztery wartości: WHERE autoload IN ('yes','on','auto-on','auto').
Nierozstrzygnięte znaczy ładowane
Wartość auto jest tą zaskakującą. Zapisuje, że żadna decyzja nie zapadła – a opcja w tym stanie i tak zostaje załadowana.
Droga przez kod jest krótka. Wyraźne true, on albo yes staje się on. Wyraźne false, off albo no staje się off. Tam, gdzie nie podano nic wyraźnego, głos dostaje filtr: true staje się auto-on, false auto-off, a brak odpowiedzi auto.
Ponieważ auto stoi na liście ładowanych, milczenie ma kierunek. Opcja założona bez słowa o autoload jest od tej chwili czytana przed każdą stroną. Na tej stronie w dokładnie takim stanie znajduje się 55 opcji.
Granica przy 150 000 bajtów
Jeden filtr przychodzi razem z WordPressem i nie robi nic poza pilnowaniem rozmiaru. Jeśli wartość po serializacji przekracza 150 000 bajtów, odpowiedź brzmi auto-off, a opcja zostaje na miejscu.
Dwa szczegóły warto zapamiętać. Granica sama jest filtrem, wp_max_autoloaded_option_size, więc wtyczka może ją przesunąć. I działa tylko tam, gdzie nie powiedziano nic wyraźnego – opcja ustawiona ręcznie na on zostaje załadowana bez względu na rozmiar.
W liczbach tej strony reguła jest dobrze widoczna. Żadna ładowana opcja nie przekracza tutaj 150 000 bajtów, podczas gdy największa opcja całej tabeli – zapisany rozmiar katalogu o wielkości 102 403 bajtów – stoi na off i nigdy nie podróżuje.
Ile naprawdę kosztuje 155 opcji
Zmierzone 2 września 2026: 155 z 1290 opcji jest czytanych przed każdą stroną, razem 122 435 bajtów, niecałe 120 KB.
Ważniejszy od sumy jest rozkład. 145 ze 155 jest mniejszych niż kilobajt. Trzy niosą razem 88 946 bajtów, czyli prawie trzy czwarte całego ciężaru.
Zdecydowanie największa jest cron z 49 606 bajtami: 40 procent wszystkiego, co ładowane, w jednym wierszu. Mieści 338 zaplanowanych zdarzeń, a 321 z nich jest jednego rodzaju – po jednym publish_future_post dla każdego wpisu, który wciąż czeka na swój termin.
To nie jest usterka i żadna wtyczka nie ponosi za to winy. Właśnie po to ta opcja istnieje. Znaczy to jednak, że blog z długim planem redakcyjnym czyta cały swój plan, zanim w ogóle wyda jakąkolwiek stronę – i że ten ciężar rośnie wraz z kalendarzem, a nie z ruchem. Dobrze o tym wiedzieć, zanim poszukiwania winnego zaczną się w zupełnie innym miejscu.
Pytania i odpowiedzi
Czy trwała pamięć podręczna obiektów zmienia koszt ładowanych opcji?
Oszczędza zapytanie do bazy, nie ciężar. Przy pamięci podręcznej obiektów, takiej jak Redis czy Memcached, WordPress odkłada tam cały zestaw ładowanych opcji i przy każdym wywołaniu pobiera go z powrotem w jednym kawałku, zamiast pytać tabelę. W pamięci PHP ląduje potem to samo co bez pamięci podręcznej, na tej stronie nadal 122 435 bajtów na wywołanie, a cały zestaw zostaje wczytany, zanim powstanie pierwsza linijka strony.
Na uwagę zasługuje jeden skutek uboczny: zestaw leży w pamięci podręcznej jako pojedynczy wpis. Gdy rośnie, rośnie razem z nim ten wpis, a Memcached w ustawieniu domyślnym nie przyjmuje elementów większych niż 1 MB. Przy niecałych 120 KB ta strona jest daleko od tej granicy; blog, którego opcja cron rośnie razem z planem redakcyjnym, powinien jednak mieć sumę na oku.
Czy da się zmniejszyć opcję cron, nie narażając zaplanowanych wpisów?
Tylko w niewielkim stopniu. 321 zdarzeń publish_future_post to nie pozostałości, lecz polecenia opublikowania czekających wpisów w ich terminach. Bez takiego zdarzenia wpis pozostaje w statusie future, nawet gdy jego termin dawno minął. Na jedno zdarzenie przypada średnio niecałe 147 bajtów (49 606 bajtów na 338 zdarzeń), więc każdy kolejny zaplanowany wpis powiększa opcję mniej więcej o tyle, a każda publikacja znów to odejmuje.
Porządki mają sens wśród pozostałych 17 zdarzeń. Bywają wśród nich cykliczne zadania wtyczek usuniętych dawno temu, bo wtyczka musi sama wyrejestrować swoje zdarzenia przy usuwaniu, a nie każda to robi. Nawet gdyby wszystkie 17 okazały się zbędne, przy przeciętnym rozmiarze dałoby to zaledwie około 2,5 KB.
Nic się przy tym nie zmienia, gdy WP-Cron jest uruchamiany przez systemowe zadanie cron. Zmienia się tylko to, kto wywołuje zdarzenia, na które przyszła pora; lista nadal jest zapisana w tej samej opcji i ładowana przed każdą stroną.
Czy WordPress przestawia opcje dezaktywowanej wtyczki na off?
Nie. Dezaktywacja nie rusza tabeli, a opcje znikają dopiero wtedy, gdy wtyczka sama posprząta po sobie przy odinstalowaniu, więc opcja założona bez podania wartości autoload jest czytana przed każdą stroną także po usunięciu wtyczki. Wśród 55 opcji w stanie auto o tym, do której wtyczki należy dany wiersz, zwykle mówią przedrostki nazw.
Powiązane artykuły
