Wskaźnik trafień w pamięci podręcznej obiektów WordPressa: znaczenie i sensowne wartości docelowe

Co przechowuje pamięć podręczna obiektów WordPressa

Der Pamięć podręczna obiektów WordPressa przechowuje dane pod kluczem i w ramach grupy. Gdy WordPress ponownie żąda tej samej wartości, może ją pobrać z pamięci podręcznej zamiast ponownie wykonywać związane z nią operacje. Obejmuje to na przykład dane, które w przeciwnym razie musiałyby zostać odczytane z bazy danych lub ponownie obliczone.

Wbudowana implementacja Core jest domyślnie związane z żądaniem: Przechowuje swoje wpisy tylko na czas pojedynczego żądania. Oznacza to, że kolejne wywołanie strony nie uzyskuje automatycznie dostępu do wcześniej zapisanych wartości. Niemniej jednak pamięć podręczna może zapobiegać powtarzającym się dostępom już w ramach jednego żądania.

Funkcja typu „drop-in” może zastąpić implementację rdzenia poprzez trwała pamięć podręczna obiektów zastąpić. Wówczas odpowiednie wpisy mogą zostać zachowane poza ramami poszczególnych żądań. Redis jest jedną z możliwych opcji zaplecza, ale nie jest warunkiem koniecznym dla działania WordPressa; możliwe są również inne rozwiązania zaplecza. Nawet przy zastosowaniu trwałego rozwiązania typu „drop-in” niektóre grupy mogą nadal obowiązywać wyłącznie dla bieżącego żądania.

Dane przejściowe stanowią kolejną możliwość przechowywania danych potrzebnych tylko przez ograniczony czas. Dzięki trwałej pamięci podręcznej obiektów można je tam zapisać, zazwyczaj bez konieczności przechowywania ich w bazie danych. Ich czas ważności nie oznacza gwarantowanej minimalnej dostępności: dana wartość może zniknąć wcześniej. Kod aplikacji musi zatem liczyć się z brakiem danych przejściowych i w razie potrzeby być w stanie odtworzyć daną wartość.

To rozróżnienie ma kluczowe znaczenie dla późniejszej oceny wskaźnika trafień: dostęp do lokalnej pamięci podręcznej podczas żądania i dostęp do zewnętrznego backendu niekoniecznie są tym samym wskaźnikiem. Dlatego najpierw sprawdź, która implementacja jest faktycznie używana i jakie dane są w niej przechowywane w sposób trwały.

Różnica między pamięcią podręczną obiektów a pamięcią podręczną stron

Podczas wyświetlania strony może wystąpić Pamięć podręczna stron dostarczyć już wygenerowaną odpowiedź strony. Jeśli zapytanie zostanie tam obsłużone, nie musi przechodzić przez tę samą ścieżkę aplikacji WordPress, co zapytanie niebędące w pamięci podręcznej. Z kolei pamięć podręczna obiektów działa w ramach aplikacji, wykorzystując pojedyncze dane z pamięci podręcznej, a nie pełną odpowiedź strony.

Wyobraź sobie stronę artykułu dostępną publicznie: jeśli jej treść znajduje się w pamięci podręcznej strony (Page Cache), może zostać wyświetlona bezpośrednio. Jeśli natomiast WordPress musi wygenerować tę stronę, pamięć podręczna obiektów (Object Cache) może pomóc w przypadku wielokrotnego dostępu do danych. To, jakie czynności faktycznie zostają dzięki temu pominięte, zależy od zapytania, zapisanych wpisów oraz konkretnej implementacji.

Ma to wpływ na interpretację: dobry wskaźnik pamięci podręcznej obiektów opisuje jedynie zarejestrowane dostępy do pamięci podręcznej. Nie wskazuje on bezpośrednio, ilu użytkowników otrzymało już gotową odpowiedź z pamięci podręcznej strony ani jak szybko reaguje cała witryna. W przypadku intensywnego buforowania stron korzyści płynące z pamięci podręcznej obiektów mogą być widoczne przede wszystkim w pozostałych żądaniach WordPressa.

Również pamięć podręczna przeglądarki i pamięć podręczna kodu operacyjnego pełnią inne funkcje. Pamięć podręczna przeglądarki przechowuje zasoby u użytkownika; pamięć podręczna kodu operacyjnego PHP przechowuje skompilowany kod PHP. Żadna z nich nie zastępuje ani przechowywania poszczególnych danych aplikacji w pamięci podręcznej obiektów, ani dostarczania pełnej odpowiedzi z pamięci podręcznej strony.

Stała WP_CACHE Samo to nie aktywuje pamięci podręcznej obiektów Redis. Aby uzyskać trwałą pamięć podręczną obiektów, potrzebujesz odpowiedniej implementacji i jej obsługiwanej konfiguracji. Dodatkowy przykład współdziałania kilku warstw znajdziesz w artykule poświęconym Silnik pamięci podręcznej AccelerateWP.

Co mówią sukcesy i porażki

A Hit ma miejsce, gdy poszukiwany wpis zostanie znaleziony na rozpatrywanym poziomie pamięci podręcznej. Jednym z Panna oznacza to, że nie można go tam znaleźć. Wskaźnik trafień oblicza się jako stosunek liczby trafień do łącznej liczby zliczonych trafień i pudłów: trafienia / (trafienia + pudły) × 100. Jeśli nie ma ani trafień, ani pudłów, wskaźnik ten nie jest zdefiniowany dla tego okresu.

Błąd niekoniecznie oznacza błąd techniczny. Przy pierwszym dostępie wpis może jeszcze nie istnieć; nawet po upływie jego ważności może zaistnieć konieczność ponownego jego pozyskania lub wygenerowania. Decydujące znaczenie ma to, jakie konsekwencje mają takie nieudane próby w konkretnym procesie oraz czy ponowne próby uzyskania dostępu mają w ogóle sens.

Metoda Core w WordPressie, w swojej własnej implementacji, zlicza trafienia w pamięci podręcznej i nieudane próby. Jednak wtyczka typu „drop-in” może zastąpić tę implementację. Dlatego na podstawie sposobu zliczania stosowanego w rdzeniu nie można z całą pewnością wywnioskować, co rejestruje wyświetlenie wtyczki: sprawdź dla używanej wersji, jakie odsłony i jaki okres obejmuje jej wskaźnik.

Redis zgłasza, że keyspace_hits oraz keyspace_misses pomyślne lub nieudane wyszukiwania kluczy w przestrzeni kluczy Redis. Również nieudane EXISTS-Ruch ten może zostać uznany za faul. To Wskaźnik trafień w Redis nie oznacza zatem automatycznie limitu dotyczącego WordPressa lub wtyczek.

Jeśli z instancji Redis korzysta kilka stron internetowych lub aplikacji, ich liczniki mogą wspólnie odzwierciedlać liczbę odwiedzin. W takim przypadku nie da się wiarygodnie przypisać globalnego limitu do pojedynczej strony WordPress bez odpowiedniej, oddzielnej telemetrii. Dlatego przy każdym porównaniu należy odnotować, jaki poziom i jaką instancję opisują te dane.

Należy dokładnie sprawdzić zakres pomiarowy i dostęp

Przed rozpoczęciem pomiaru sprawdź, jaką implementację pamięci podręcznej obiektów wykorzystuje WordPress. Jeśli masz dostęp do WP-CLI i do katalogu WordPressa, możesz rozpocząć od sporządzenia wykazu zawartości w trybie odczytu za pomocą następującego polecenia:

wp cache type

Wynik ten pomaga w ocenie wdrożenia, ale nie dowodzi, że każdy istotny dostęp jest zapisywany trwale. WordPress pozwala wtyczce typu „drop-in” na zastąpienie pamięci podręcznej rdzenia; jednocześnie poszczególne grupy mogą nie być zapisywane trwale. Dlatego należy również odnotować zastosowaną wtyczkę typu „drop-in” lub inną wtyczkę oraz jej wersję.

Sprawdź w dokumentacji konkretnej wersji, jakie operacje obejmują wyświetlane liczby trafień i pominięć oraz w jakim przedziale czasowym są one zliczane. Wskaźnik wtyczki można sensownie porównać z innym wskaźnikiem tylko wtedy, gdy znany jest zakres pomiaru i sposób zliczania. Szczególnie ważne jest to, czy wyświetlanie odnosi się tylko do jednego żądania, czy też do dłuższego przedziału czasowego.

W przypadku Redis, o ile dostępne jest połączenie i uprawnienia, można w sesji CLI Redis pobrać w trybie odczytu statystyki i informacje o pamięci. Poniższe polecenia celowo nie zawierają danych uwierzytelniających:

INFO stats
INFO memory

Udokumentuj Zakres pomiarowy: Które instancje lub węzły zostały sprawdzone i z jakich innych stron internetowych lub aplikacji korzystają? Globalne liczniki Redis nie dają się w prosty sposób przypisać do pojedynczej strony internetowej, gdy są współużytkowane. Przed udostępnieniem danych sprawdź, czy nie zawierają one poufnych informacji operacyjnych; do przeprowadzenia tej inwentaryzacji nie jest konieczne ani opróżnianie pamięci, ani test obciążenia.

Jeśli nie masz dostępu do interfejsu CLI Redis, zapytaj swojego dostawcę usług hostingowych o dostępne wskaźniki i ich zakres. Również pulpit nawigacyjny stanowi użyteczną podstawę tylko wtedy, gdy jest jasne, czy pokazuje tę samą instancję, poszczególne węzły, czy też już zagregowane wartości.

Obliczanie wskaźnika trafień Redis w danym przedziale czasowym

Statystyki Redis to po prostu stany liczników, a nie gotowe wnioski dotyczące konkretnego okresu pomiarowego. Aby przeprowadzić analizę w przedziale czasowym, sprawdź wartości dla keyspace_hits oraz keyspace_misses na początku i na końcu tego samego przedziału czasowego dla tej samej instancji. Zanotuj oba momenty oraz odpowiadającą im instancję, aby odczyty były ze sobą zgodne.

Następnie dla każdego licznika odejmij wartość początkową od wartości końcowej. Współczynnik trafień w przedziale czasowym wynosi: ΔHits / (ΔHits + ΔMisses) × 100. Znak Δ oznacza daną różnicę. Jeśli obie różnice wynoszą zero, w tym oknie nie odnotowano żadnych wyszukiwań; wówczas wskaźnik nie jest zdefiniowany, a nie wynosi zero procent.

Przykład obliczeniowy, a nie pomiar: jeśli liczba trafień wzrośnie o 900, a liczba pomyłek o 100, daje to 90 procent przy łącznej liczbie 1 000 zliczonych wyszukiwań. Nie oznacza to ani tego, że strony są o 90 procent szybsze, ani tego, że zaoszczędzono dokładnie 900 zapytań do bazy danych. Redis zlicza operacje wyszukiwania kluczy; ich znaczenie dla aplikacji zależy od konkretnego dostępu.

Jeśli jeden z liczników spadnie w okresie między odczytami, prosta różnica obliczona na podstawie tego ułamka nie jest prawidłowa. Może to wynikać z ponownego uruchomienia urządzenia lub zresetowania statystyk. Należy rozpocząć okno pomiarowe od nowa lub podzielić je w oparciu o wiarygodne dane eksploatacyjne w momencie wystąpienia przerwy, zamiast wprowadzać wartość ujemną do wzoru.

W przypadku wielu węzłów najpierw obliczasz różnice dla każdego odpowiedniego węzła w tym samym okresie. Następnie zsumuj oddzielnie trafienia i pomyłki, a na tej podstawie oblicz ogólny wskaźnik. Nieważona średnia poszczególnych wartości procentowych traktuje węzeł z niewielką liczbą wyszukiwań tak samo jak węzeł z dużą liczbą wyszukiwań; może to znacznie zniekształcić ogólny obraz sytuacji.

Zwróć przy tym uwagę, które węzły są faktycznie uwzględnione i jaką rolę pełnią w środowisku. Obliczona w ten sposób łączna wartość odnosi się wyłącznie do wybranych liczników i ich użytkowników; nie wynika ona wyłącznie z agregacji w celu uzyskania konkretnego wskaźnika pamięci podręcznej obiektów WordPressa.

Protokół pomiarowy i wskaźniki Redis

Oprócz trafień i pomyłek w klasyfikacji pomagają również inne wskaźniki Redis. Również w tym przypadku różnice w wybranym okresie są bardziej miarodajne niż pojedyncze wartości całkowite. Poniższa tabela oddziela znaczenie wartości od wniosków, których nie można wyciągać wyłącznie na ich podstawie.

Wzrost o expired_keys może stanowić powód do dokładniejszego przyjrzenia się okresom ważności i wzorcom dostępu. Nie wskazuje jednak, czy dany wpis był ponownie potrzebny wkrótce po upływie jego ważności. Podobnie jest evicted_keys należy rozpatrywać w kontekście skonfigurowanego limitu pamięci i strategii wypierania, zamiast od razu wyciągać z tego wniosek o konieczności zwiększenia pamięci.

Przydatny Protokół pomiarowy Podaj początek i koniec przedziału czasowego, instancję lub węzeł, obie różnice liczników, ich sumę oraz obliczony współczynnik. Dodaj informację, czy instancja jest współużytkowana oraz czy w trakcie tego przedziału odnotowano ponowne uruchomienie lub zresetowanie. Dzięki temu pomiary będą później możliwe do odtworzenia.

Równolegle rejestruj rozpatrywany typ żądania oraz odpowiedni wskaźnik opóźnienia, a także obciążenie bazy danych i wskaźnik błędów. Na przykład oddziel wywołania stron publicznych od żądań użytkowników zalogowanych, jeśli dostępne są odpowiednie dane. Sam wskaźnik Redis nie wskazuje, który z tych typów żądań odniósł korzyść z trafienia.

Aby umożliwić późniejsze porównanie, okres, węzły i skład żądań powinny być jak najbardziej podobne. Należy również odnotować istotne zmiany i zauważalne fazy rozgrzewania. Tam, gdzie brakuje danych lub wspólna instancja nie pozwala na przyporządkowanie, ograniczenie to należy odnotować w protokole, a nie w pozornie precyzyjnym wniosku.

Uruchomienie na zimno, sklep i strona statyczna

Po ponownym uruchomieniu lub wdrożeniu niezbędne wpisy mogą początkowo nie być dostępne. Takich braków należy się spodziewać podczas wypełniania pamięci podręcznej; przy powtarzających się dostępach wskaźnik trafień może następnie wzrosnąć. Wartości z Faza zimna i faza ciepła należy rozpatrywać osobno, aby długi średni okres nie przesłaniał ani kosztów początkowych, ani późniejszych wyników.

W przypadku sklepu internetowego lub obszaru wymagającego logowania szczególnie interesujące są zapytania dynamiczne: pamięć podręczna strony niekoniecznie odpowiada na każde wywołanie koszyka lub konta. Dlatego należy porównywać jak najbardziej podobne typy żądań i zwracać uwagę nie tylko na wskaźnik trafień, ale także na czasy odpowiedzi oraz obciążenie bazy danych. Wysoki wskaźnik trafień w Redis sam w sobie nie świadczy o tym, czy koszyk jest wyświetlany szybko i czy jego zawartość jest poprawna.

W przypadku strony internetowej o charakterze głównie statycznym znaczna część wyświetleń stron może natomiast pochodzić już z pamięci podręcznej stron (Page Cache). Trwała pamięć podręczna obiektów (Object Cache) ma tam wpływ przede wszystkim na żądania, które WordPress faktycznie przetwarza. Należy zatem osobno ocenić, czy pozostałe żądania odniosą korzyści i czy efekt ten będzie miał wpływ na całą stronę internetową.

Jeśli korzystasz z Redis razem z innymi stronami internetowymi lub aplikacjami, liczniki instancji uwzględniają również ich dostępy. Bez odpowiedniej, oddzielnej telemetrii nie da się wiarygodnie przypisać globalnego limitu do żadnej pojedynczej strony internetowej. Należy również udokumentować, które węzły są uwzględniane: w przeciwnym razie zmiana limitu może wynikać również z innego sposobu użytkowania lub ze zmiany zakresu pomiarowego.

Analiza nietypowych wartości i błędów

Niski wskaźnik to na razie tylko spostrzeżenie, a nie diagnoza. Jako przyczyny można rozważać dużą liczbę pierwszych dostępów, krótki czas życia lub rozkład dostępów z rzadko ponownie wykorzystywanymi kluczami. Przed dostosowaniem ustawień pamięci lub pamięci podręcznej sprawdź, czy zmienił się skład żądań lub okno pomiarowe.

Liczniki expired_keys oraz evicted_keys dostarczają dodatkowych wskazówek: pierwszy z nich zlicza wygasłe klucze, a drugi – klucze usunięte z powodu ograniczeń pamięci. Różnice między nimi są specyficzne dla danej instancji Redis i muszą być dostosowane do konfiguracji oraz sposobu użytkowania. Duża liczba wygasłych kluczy nie świadczy ani o nieprawidłowo wybranym TTL, ani o tym, że dłuższy czas życia ma sens; może to pogorszyć aktualność przechowywanych danych.

W przypadku własnych rozszerzeń należy wp_cache_get parametr $found ważne: Rozróżnia on znalezioną wartość od zapisanej false z powodu braku wpisu. Przed podjęciem działań dotyczących grup należy wp_cache_supports sprawdzić, czy dany backend obsługuje daną funkcję. Alternatywne rozwiązanie typu „drop-in” może różnić się od implementacji w rdzeniu.

Ostrzeżenie: Nieprzemyślane wyczyszczenie pamięci podręcznej może wpłynąć na większą liczbę wpisów lub aplikacji niż zamierzano i zafałszować wyniki kolejnego pomiaru poprzez „zimny start”. Przed wykonaniem operacji usuwania należy ustalić zakres działania i uzyskać zgodę. Dodatkowe wskazówki dotyczące Diagnozowanie problemów związanych z powolnym działaniem pamięci podręcznej obiektów WordPressa pomóc w uwzględnieniu w analizie ewentualnego obciążenia związanego z pamięcią podręczną.

Samodzielne ustalanie sensownych wartości docelowych

Uniwersalny minimalny wskaźnik wynoszący 90 procent nie stanowi rzetelnego wymogu technicznego. Bardziej sensowne jest zakres docelowy dla danej lokalizacji, który odpowiada przewidywanemu rozkładowi dostępów i korzyściom dla aplikacji. Redis zaleca ocenę zaobserwowanego wskaźnika w kontekście danego wzorca dostępów; sama wartość procentowa nie wyjaśnia jeszcze wydajności WordPressa.

Najpierw przeprowadź reprezentatywny pomiar początkowy, uwzględniając okres, zakres pomiaru, liczbę dostępów i wskaźnik. W tym celu należy odnotować czasy odpowiedzi dla ważnych typów żądań, obciążenie bazy danych oraz wskaźnik błędów. Należy oddzielnie oznaczyć zimne starty i uwzględnić typowe różnice między okresami o małym i dużym natężeniu ruchu, zamiast traktować przypadkowo korzystny przedział czasowy jako stan normalny.

Następnie zaplanuj konkretną zmianę i po jej zatwierdzeniu sprawdź ją w miarę możliwości najpierw w odpowiednim środowisku testowym. Następnie porównaj podobne okresy i zestawy żądań: czy zmieniają się limity i liczba zapytań, a także opóźnienia lub obciążenie bazy danych? W ten sposób łatwiej jest odróżnić rzeczywisty efekt od zwykłego przesunięcia w czasie dostępów.

Nawet wysoki wskaźnik może maskować nieliczne, ale szczególnie kosztowne błędy. Z drugiej strony umiarkowany wskaźnik nie musi stanowić problemu, o ile na istotne zapytania udzielane są szybkie i poprawne odpowiedzi. Dodatkowe koszty eksploatacji związane z Redis lub innym trwałym backendem nie są automatycznie uzasadnione samym lepszym wskaźnikiem; należy wziąć pod uwagę wsparcie techniczne dostawcy hostingu, koszty oraz potencjalne scenariusze awarii.