Dzisiaj przeprowadzam test na mojej bazie danych, aby zbadać różnicę prędkości między dostępem do klucza z opcji, niestandardowej tabeli i stanów przejściowych. Przeprowadziłem test 1000 razy, a poniżej podano czas potrzebny na wykonanie 1000 operacji pobierania:

Weź pod uwagę, że w większości systemów tabela opcji jest używana zarówno dla opcji, jak i stanów przejściowych, a ta tabela została zoptymalizowana, z dodanymi indeksami. Więc to nie jest uczciwe porównanie

get_transient() 0,0245 sekundy get_option() 0,0068 sekundy prosta operacja wyboru z niestandardowej tabeli 0,65 sekundy

To też nietrafne porównanie, opcje z autoload zestaw opcji zostanie wcześnie załadowany w trybie zaawansowanym w pojedynczym zapytaniu. Więc get_option ciągnie od WP_Cacheopcja została już pobrana.

TLDR: W rzeczywistości nie pobiera opcji, została już pobrana, po prostu wyciąga ją z pamięci z powodu autoload opcja

Sprawdziłem również, czy transjent nie wygasł podczas tego testu.

Nie powinno to mieć wpływu na normalny system na przejściowe pobieranie, w końcu nie wie, czy wygasł, dopóki nie zostanie pobrany.

Więc pytanie brzmi, czy get_option() jest szybsze niż get_transient() lub czy coś zepsułem w moim teście?

To zależy:

• W większości systemów transjenty są przechowywane za pomocą opcji, z których oba obejmują a get_option dzwonić
• Opcje z autoload ustawione na true są ładowane w jednym wywołaniu na początku, więc są przechowywane w pamięci, po tym nie pojawiają się żadne zapytania
• Buforowanie obiektów buforuje zarówno opcje ładowane automatycznie, jak i transjenty

Czy niestandardowe opóźnienie tabeli jest spowodowane domyślnym buforowaniem opcji przez WordPress?

Bardzo możliwe, ale szybkość tego wyboru zależy w dużej mierze od zapytania i projektu tabeli

Czy opcje są również buforowane przez różne wtyczki buforujące, takie jak transjenty?

Tak, WP_Cache jest używany, który będzie przechowywać go w pamięci przez resztę żądania. Wtyczki pamięci podręcznej mogą przechowywać te wartości ze względu na wydajność.

Powtarzalność

Wszystkie są buforowane przez WP_Cache więc za drugim razem, gdy o to poprosisz, nie jest zaangażowana żadna baza danych.

Zmienność i to zależy

To wszystko zakłada wspólną podstawę, ale co z pamięciami podręcznymi obiektów?

Wprowadźmy instancję MemcacheD lub instancję Redis (MOCNIE polecam to zrobić, jeśli masz taką opcję, OGROMNE korzyści w zakresie wydajności dla dobrze zbudowanych witryn, zwłaszcza jeśli używasz ich do buforowania stron, chyba że masz coś takiego jak konfiguracja Varnish)

Teraz mamy nową sytuację:

• Teraz dane są przechowywane w pamięci RAM, a po pobraniu z bazy danych są przygotowywane, a czas dostępu jest znacznie skrócony. Nadal wolniej niż zmienna, ale znacznie szybciej niż zapytanie do bazy danych
• Przechowuje się wiele nowych danych WP_Cache to normalnie nie jest. Np WP_Post obiekty, meta postów itp
• WP_Cache teraz utrzymuje się między żądaniami
• MemcacheD itp. Może wyeliminować przedawnione transjenty itp

Więc teraz stany przejściowe i opcje mają ten sam koszt dostępu. Były już bliskie, ale teraz są nieistotne i mają więcej wspólnego z obciążeniem procesora w momencie wysłania żądania.

Więc dla wydajności powinienem używać transjentów czy opcji?

Chociaż warto się zastanowić nad tym pytaniem, odpowiedź brzmi, że różnica jest znikoma i mieści się w granicach błędu

Więc przestań mikrooptymalizować, to ten sam nośnik pamięci, a to nie jest warte twojego czasu

• Użyj opcji, jeśli chcesz przechowywać coś, co obejmuje całą witrynę
• Używaj transjentów do tymczasowego przechowywania rzeczy, które są drogie do obliczenia, abyś nie musiał następnym razem

Nie warto tracić czasu na wybieranie jednego z nich na podstawie wydajności, nie ma znaczącej różnicy.

Są o wiele lepsze rzeczy do zrobienia w celu optymalizacji, które dają znacznie większe oszczędności, np. używanie taksonomii zamiast meta w zapytaniach postów, nie używanie __not parametry stylu, robienie mniejszej liczby rzeczy na stronie, instalowanie pamięci podręcznej obiektów, zmniejszanie postów na stronę, unikanie zdalnych żądań itp

A co z niestandardowym stołem, który…

Nie, tabela opcji jest już dobrze zoptymalizowana, użycie niestandardowej tabeli po prostu przeniesie operacje poza system WP Caching, zmuszając Cię do napisania własnego