Test porównawczy WordPressa: powtarzalne testowanie wydajności hostingu

Na jakie pytania odpowiada test porównawczy WordPressa

A Test wydajności WordPressa Zaczyna się od konkretnego pytania: czy dana strona ładuje się szybko w określonych warunkach? W tym celu przeglądarka pobiera kod HTML, obrazy, skrypty i inne zasoby, a następnie wyświetla stronę. Wynik odzwierciedla współdziałanie tych elementów, a nie tylko szybkość serwera hostingowego.

Drugie pytanie dotyczy Reakcja pod obciążeniem: Jak zmieniają się czasy odpowiedzi i liczba błędów, gdy napływają żądania zgodne z określonym profilem? Pojedyncze wywołanie strony nie daje odpowiedzi na to pytanie. Z drugiej strony test obciążenia HTTP nie pokazuje bezpośrednio, jak szybko przeglądarka wyświetla całą stronę.

W przypadku publicznego wpisu na blogu pamięć podręczna strony może dostarczyć gotowy kod HTML; sieć CDN może udostępniać zasoby lub odpowiedzi bliżej lokalizacji pomiarowej. Jednocześnie na wynik wpływają motyw, wtyczki, obrazy i skrypty zewnętrzne. Jakie inne czynniki mogą spowalniać działanie strony, wyjaśnia artykuł na temat ukryte czynniki obniżające wydajność WordPressa.

Aby ocenić wpływ hostingu, pomocne są dwa pytania porównawcze. W przypadku Porównanie stosów Należy w miarę możliwości dostosować stronę internetową i ustawienia oraz udokumentować pozostałe różnice. Podczas porównywania pakietów należy sprawdzić oferowane konfiguracje, w tym odpowiadające im pamięci podręczne i usługi. Jest to przydatne przy podejmowaniu decyzji o zakupie, ale nie pozwala wyodrębnić samej wydajności serwera.

Dlatego należy odnotować, która strona, jaki plan taryfowy i jakie otoczenie składają się na dany wynik. Zaleta testowanego artykułu na blogu może wyglądać inaczej w przypadku wyświetlania z zalogowanego konta. Pomiar odnosi się do udokumentowanych warunków i okresu; nie stanowi on ani ogólnego zwycięzcy testu, ani gwarancji wydajności.

Analiza danych z przeglądarek i interpretacja danych terenowych

Test szybkości WordPressa przeprowadzony za pomocą Lighthouse’a daje Zdjęcie z laboratorium strony w określonych warunkach pomiarowych. W protokole należy zatem uwzględnić profil przeglądarki, urządzenie lub emulację, profil sieciowy, lokalizację pomiaru oraz wersję narzędzia. Tylko w ten sposób można później ocenić, czy dwa przebiegi są rzeczywiście porównywalne.

Wynik wydajności Lighthouse stanowi ważoną sumę kilku wskaźników. Może on ulegać wahaniom w zależności od zmieniających się treści i warunków pomiaru, a także nie pozwala ustalić, który konkretny wskaźnik uległ zmianie. Powtórz pomiar przy użyciu tego samego profilu i udokumentuj poszczególne wartości wszystkich przebiegów, zamiast wybierać tylko najlepszy wynik.

Jednym z ważnych wskaźników jest LCP: opisuje on, kiedy największy istotny element treści zostaje widocznie załadowany. CLS rejestruje nieoczekiwane przesunięcia układu podczas korzystania ze strony. INP opisuje responsywność na interakcje; do jego obliczenia potrzebne są faktycznie zarejestrowane interakcje i nie jest on określany wyłącznie na podstawie samego wywołania strony.

Z kolei raport Chrome UX, w skrócie CrUX, dostarcza dostępne dane, o ile są one dostępne Dane terenowe na podstawie odwiedzin rzeczywistych użytkowników biorących udział w badaniu. Doświadczenia te zależą między innymi od ich urządzeń i sieci. Nie są one dostępne dla każdej strony i odpowiadają na inne pytanie niż test laboratoryjny przeprowadzony w kontrolowanych warunkach.

Dla każdej wartości należy zaznaczyć, czy pochodzi ona z laboratorium, czy z rzeczywistych warunków użytkowania. Na przykład zwykłe zapytanie HTTP może rejestrować status i czas odpowiedzi, ale nie powoduje automatycznie renderowania ani interakcji przeglądarki. W związku z tym na jego podstawie nie można określić wskaźników LCP, CLS i INP jako wskaźników dotyczących doświadczenia użytkownika w przeglądarce.

Jak prawidłowo rozróżniać poziomy pamięci podręcznej

A Pamięć podręczna stron może przechowywać gotowy kod HTML na potrzeby powtarzających się żądań. Z kolei pamięć podręczna obiektów przechowuje dane aplikacji, które są potrzebne WordPressowi podczas przetwarzania. Ponadto przeglądarka może ponownie wykorzystywać lokalnie już załadowane zasoby; sieć CDN może buforować treści na kolejnym poziomie poza pierwotnym serwerem.

W przypadku „rozgrzanej” pamięci podręcznej stron wielokrotnie wywołujesz stronę publiczną po zakończeniu udokumentowanego okresu rozgrzewania. Ma to znaczenie w przypadku często odwiedzanych treści, ale niewiele mówi o tym, jak kosztowne jest ich dynamiczne generowanie. Zanotuj, który adres URL został rozgrzany oraz jakie reguły pamięci podręcznej i ustawienia CDN miały zastosowanie.

W przypadku żądania bez pamięci podręcznej musisz ustawić Obejście pamięci podręcznej Sprawdź to dokładnie, zamiast po prostu przyjmować to za pewnik. Zgłoszona sesja może działać według innych zasad i dostarczać spersonalizowane treści. Sprawdź, jaka jest rzeczywista odpowiedź: szybki dostęp nie ma wielkiej wartości, jeśli dostarcza błędne lub nieaktualne treści.

Pierwsza wizyta w nowym stanie przeglądarki nie oznacza, że pamięć podręczna serwera lub sieci CDN jest pusta. Podobnie błąd CDN nie oznacza automatycznie, że pamięć podręczna aplikacji została wyczyszczona. Nagłówki pamięci podręcznej mogą dostarczać wskazówek, ale w zależności od dostawcy nie potwierdzają stanu każdej z zaangażowanych warstw; dlatego należy również udokumentować dostępne ustawienia i metody sprawdzania.

Pamięć podręczna obiektów WordPressa jest zasadniczo ograniczona do danego żądania, o ile nie ma odpowiedniego rozszerzenia zapewniającego trwałość danych. Stała WP_CACHE Samo to nie uruchamia ani Redis, ani żadnego automatycznego rozwiązania do buforowania. Jaką rolę mogą odgrywać Redis i Memcached jako trwała pamięć buforowa obiektów, wyjaśnia artykuł poświęcony Redis i Memcached w hostingu WordPress.

Przygotowanie porównania i zatwierdzeń

Aby porównać oferty hostingowe, najpierw potrzebujesz porównywalny stan strony internetowej. Utwórz oczyszczoną kopię o tej samej treści, tym samym zbiorze danych, tym samym motywie i tych samych wtyczkach, łącznie z ich wersjami. Usuń lub zastąp dane osobowe oraz dane dostępowe do środowiska produkcyjnego w taki sposób, aby strona testowa nadal odzwierciedlała pożądany przypadek użycia.

W miarę możliwości należy zastosować te same wersje PHP i bazy danych oraz odpowiednie ustawienia. Odnotuj różnice, których nie da się wyeliminować lub które wynikają z wybranego pakietu. Porównanie poszczególnych pakietów standardowych odpowiada na inne pytanie niż porównanie stosów, które są jak najbardziej zharmonizowane: wynik nie może być w prosty sposób przypisany wyłącznie wydajności serwera.

Przed pierwszym uruchomieniem należy sporządzić plan pomiarowy. Musi on być na tyle szczegółowy, aby inna osoba mogła odtworzyć konfigurację i wykryć odchylenia w przypadku powtórzenia pomiaru. Poniższa lista kontrolna rozróżnia cechy oferty hostingowej od cech strony internetowej i pomiaru.

• Taryfa, limity zasobów, lokalizacja serwera oraz wersje oprogramowania w obu środowiskach.
• Adresy URL testowe i typy stron, status logowania, pliki cookie oraz wykorzystywane konta testowe.
• CDN, pamięć podręczna stron i pamięć podręczna obiektów, w tym reguły, faza rozgrzewania i planowane obejście.
• Miejsce pomiaru, wersja narzędzia, profil przeglądarki i urządzenia, warunki sieciowe, momenty pomiaru i liczba powtórzeń.
• Profil obciążenia, zakresy odpowiedzialności, uzgodniony przedział czasowy na przeprowadzenie testu oraz konkretne progi przerwania testu.

W przypadku testów obciążeniowych uzgadniasz Zwolnienie Skonsultuj się ze wszystkimi odpowiedzialnymi osobami oraz, w razie potrzeby, z dostawcą usług hostingowych, zanim zaczniesz generować obciążenie. Ustalić osoby kontaktowe, limity zasobów oraz sposób postępowania w przypadku awarii. Wyklucz usługi zewnętrzne bez ich zgody; w szczególności zapobiegaj rzeczywistym płatnościom, zamówieniom i powiadomieniom. Sprawdź wcześniej, czy kopia testowa rzeczywiście uniemożliwia takie operacje.

Koncepcja pomiaru dla typowych stron

Wybierz narzędzie na podstawie pytania, a nie na podstawie jak najlepszej pojedynczej wartości. Jedno Koncepcja pomiarowa przypisuje każdemu wierszowi typ strony i stan pamięci podręcznej. Tabela pokazuje, jakie wyniki można uzyskać przy użyciu poszczególnych metod oraz jakie są ich ograniczenia.

W przypadku publicznego wpisu na blogu należy wielokrotnie zmierzyć ten sam reprezentatywny adres URL, korzystając ze stałego profilu przeglądarki i sieci. Należy odnotować, czy włączone są CDN i pamięć podręczna strony oraz w jaki sposób strona została „rozgrzana” przed pomiarami. W ten sposób można ocenić czas ładowania tej publicznej strony, a nie automatycznie czas ładowania sesji zalogowanej.

Dynamiczne wyszukiwanie lub podgląd konta otrzymuje własną serię pomiarów z udostępnionymi danymi testowymi oraz, w razie potrzeby, konto testowe. Nie sprawdzaj tylko kodu statusu: odpowiedź musi być zgodna z zapytaniem lub zalogowanym kontem oraz musi być aktualna. Sprawdź również, czy zaplanowane Obejście pamięci podręcznej rzeczywiście działa; sam plik cookie tego nie potwierdza.

Różnice w czasach odpowiedzi nie oznaczają jeszcze, że znaleziono przyczynę. Na wynik mogą wpływać logika aplikacji, operacje na bazie danych, trwała pamięć podręczna obiektów oraz środowisko hostingowe. Należy udokumentować różnice w strukturze, a następnie zbadać je w sposób ukierunkowany, zamiast traktować pojedyncze powolne zapytanie jako dowód na istnienie konkretnego wąskiego gardła.

Stopniowe zwiększanie obciążenia w sposób kontrolowany

Zacznij od wyraźnie zatwierdzonej strony testowej, generując kilka pojedynczych żądań. Sprawdź status i zawartość oraz upewnij się, że nie występują żadne niepożądane skutki uboczne. Dopiero potem należy przeprowadzić oddzielnie uzgodniony test obciążeniowy, na przykład dla zatwierdzonych stron produktów w sklepie. Prawdziwe zamówienia, płatności i powiadomienia pozostają wykluczone.

Zaplanuj obciążenie stopniowe wraz z poziomem początkowym, czasem trwania i stopniami nasilenia. Uzgodnij z wyprzedzeniem mierzalne progi przerwania testu dotyczące błędów, czasu odpowiedzi lub innych dostępnych parametrów operacyjnych, a także osobę kontaktową w przypadku przerwania testu. Trzymaj się wyraźnie dozwolonych procedur; podgląd produktu nie dostarcza informacji na temat nieprzetestowanego procesu realizacji zamówienia.

W modelu obciążenia zamkniętego wirtualna instancja użytkownika czeka na zakończenie bieżącej iteracji, zanim rozpocznie kolejną. Jeśli aplikacja działa wolniej, może to spowodować spadek oferowanego obciążenia. Model ten nadaje się do procesów, w których właśnie takie oczekiwanie stanowi część zadania; nie zapewnia on jednak stałej częstotliwości przybywania.

A model obciążenia otwartego Natomiast planuje nowe iteracje niezależnie od tego, czy poprzednie zostały zakończone. W tym celu generator obciążenia musi dysponować wystarczającą wydajnością i dostępnymi wirtualnymi instancjami użytkowników. Jeśli nie będzie w stanie uruchomić iteracji, test nie osiągnie zaplanowanego profilu; dlatego należy udokumentować również te nieuruchomione iteracje.

Zapisz zarówno ustawioną, jak i faktycznie osiągniętą częstotliwość. Liczba iteracji na sekundę odpowiada liczbie żądań na sekundę tylko wtedy, gdy każda iteracja generuje dokładnie jedno żądanie. Należy również zarejestrować rozkład czasów odpowiedzi, błędy i przekroczenia limitów czasu, a także sprawdzić poprawność treści: wysoka przepustowość przy błędnych odpowiedziach nie stanowi udanego testu obciążeniowego.

Przeprowadzać przejrzystą analizę serii pomiarów

Seria pomiarów ma znaczenie tylko w połączeniu z jej zakresem. Dlatego dla każdej testowanej strony i każdego etapu obciążenia należy odnotować liczbę przeanalizowanych żądań, a także liczbę błędów i przekroczeń limitu czasu. Należy oddzielić pomyślne odpowiedzi od nieudanych, nie pomijając w raporcie przypadków niepowodzeń: krótki czas odpowiedzi przy dużej liczbie błędów nie świadczy o niezawodnej szybkości działania serwisu.

Der Mediana określa średnią wartość posortowanych pomiarów zakończonych powodzeniem. 95. percentyl, w skrócie p95, wskazuje dodatkowo próg, poniżej którego znajduje się około 95 procent tych wartości pomiarowych. W przypadku niewielkiej liczby zapytań wartość p95 w dużym stopniu zależy od poszczególnych obserwacji; dlatego należy zawsze podawać wielkość próby i z rezerwą interpretować różnice.

W przypadku każdego przebiegu należy również zapisać model obciążenia oraz faktycznie osiągniętą częstotliwość. Sama skonfigurowana częstotliwość nie wskazuje, czy generator był w stanie uruchomić wszystkie zaplanowane iteracje. Poniższy szablon pozostaje pusty do momentu wykonania pomiaru; każdy z przebiegów otrzymuje osobny protokół.

Zachowaj dane surowe, skrypt testowy i konfigurację wraz z protokołem. Dzięki temu będzie można później sprawdzić, które zapytania zostały uwzględnione w analizie oraz czy dwie serie są w ogóle porównywalne. Nie wybieraj a posteriori tylko najszybszego przebiegu: jeśli wyniki znacznie się pokrywają, zaobserwowana różnica może mieścić się w granicach wahań.

Oprócz wskaźników należy również odnotować nietypowe zjawiska dotyczące treści, na przykład nieoczekiwaną stronę logowania zamiast oczekiwanego widoku konta. Status „technicznie pomyślny” nie oznacza jeszcze, że wyświetlono właściwą stronę. Takie odchylenia należy opisać oddzielnie w opisie błędu i mogą one sprawić, że seria pomiarów stanie się bezużyteczna dla planowanej decyzji.

Określić przyczyny i ponownie przeprowadzić pomiar

Rozpocznij poszukiwanie błędu od otrzymanej odpowiedzi: czy treść, status logowania i testowany adres URL są prawidłowe? Następnie sprawdź udokumentowane Stan pamięci podręcznej oraz środowisko pomiarowe. Różne pliki cookie, inna lokalizacja pomiaru lub zmieniona reguła CDN mogą spowodować, że dwa przebiegi będą się różnić, mimo że wydajność samego stosu aplikacji nie uległa zmianie.

Dopiero wtedy dostępne dane operacyjne pomagają zawęzić zakres poszukiwań: wykorzystanie zasobów i kolejki mogą wskazywać na wąskie gardła, a informacje dotyczące aplikacji lub bazy danych – na czasochłonne przetwarzanie. Pojedyncza niska wartość HTTP nie wskazuje przyczyny. WordPress wymienia jako czynniki mające wpływ na wydajność nie tylko hosting, ale także oprogramowanie, konfigurację i treści.

Aby przeprowadzić porównanie „przed i po”, należy celowo zmienić tylko jedno ustawienie, na przykład włączyć trwałą pamięć podręczną obiektów. Stan strony internetowej, strona testowa, profil obciążenia i lokalizacja pomiaru powinny pozostać w miarę możliwości niezmienione; należy również udokumentować proces rozgrzewania pamięci podręcznej. Pamięć podręczna obiektów WordPressa bez odpowiedniej trwałej implementacji jest ograniczona do pojedynczego żądania, dlatego należy sprawdzić jej faktyczne wdrożenie.

Przeprowadź kilka serii testów przed i po wprowadzeniu zmiany, rozkładając je w czasie. Dzięki temu łatwiej zorientujesz się, czy różnica pojawia się powtarzalnie, czy też może wynikać z normalnych wahań. Porównaj przy tym nie tylko medianę i p95, ale także błędy, treść odpowiedzi i osiągnięty wskaźnik; w przeciwnym razie pozorne przyspieszenie może wynikać ze zmienionych warunków testowych.

Nawet dokładne porównanie nie pozwala uwzględnić wszystkich czynników. W przypadku hostingu współdzielonego na wynik mogą wpływać inni użytkownicy oraz infrastruktura, do której nie ma się wglądu. Jeśli brakuje danych dotyczących zasobów lub kolejki, należy wyraźnie zaznaczyć tę lukę i sformułować przypuszczalną przyczynę jako hipotezę, a nie jako potwierdzony fakt.

Właściwa interpretacja wyników hostingu

Wybór hostingu należy uzależnić od stron i procesów, które są istotne dla Twojej witryny. Publiczny wpis na blogu z dobrze zapełnioną pamięcią podręczną strony może generować inne obciążenie niż wyświetlanie strony po zalogowaniu się na konto. Dobra skuteczność pamięci podręcznej na stronach publicznych nie świadczy zatem ani o szybkich, spersonalizowanych odpowiedziach, ani o niezawodnym procesie realizacji transakcji.

Przed porównaniem należy określić, jakie czasy odpowiedzi, wskaźniki błędów i profil obciążenia są dopuszczalne dla danego procesu. Następnie sprawdź, czy udokumentowane serie pomiarów spełniają te wymagania w uzgodnionych warunkach. Obejmuje to również poprawną treść i stabilny przebieg; sama wysoka częstotliwość zapytań nie stanowi wystarczającej podstawy do podjęcia decyzji.

Zestaw wirtualni użytkownicy nie są tożsame z rzeczywistymi użytkownikami obecnymi w tym samym czasie. Ich zachowanie wynika ze skryptu testowego i modelu obciążenia: w modelu zamkniętym instancja czeka na zakończenie swojej iteracji, zanim rozpocznie kolejną. Bez odpowiedniego modelu zachowania nie można zatem na podstawie ich liczby oszacować rzeczywistej liczby użytkowników.

Przedstaw wynik wraz z taryfą, stanem strony internetowej, przetestowanymi adresami URL, regułami pamięci podręcznej i CDN, lokalizacją pomiaru oraz okresem. Wyróżnij również, czy porównywałeś jak najbardziej zbliżone stosy technologiczne, czy też oferowane pakiety kompleksowe. W porównaniu pakietów różnice w konfiguracji mogą wpływać na wynik; nie pozwala ono automatycznie wyodrębnić czystej wydajności serwera.

Jeśli wyniki są bardzo zbliżone lub nie da się wystarczająco kontrolować warunków otoczenia, stwierdzenie „nie wykazano istotnej różnicy“ może być przydatnym wnioskiem. Nie oznacza to, że obie opcje działają z taką samą szybkością we wszystkich warunkach. Oznacza to jedynie, że przeprowadzony test nie pozwala na dokonanie pożądanego rozróżnienia.

W celu przeprowadzania kontroli operacyjnych należy zachować profil pomiarowy i powtarzać wybrane pomiary przeglądarki oraz obciążenia po wprowadzeniu większych zmian lub w ustalonych odstępach czasu. Nowe wyniki należy porównywać wyłącznie z odpowiednimi wcześniejszymi seriami pomiarów oraz dokumentować zmiany w treściach, wersjach i regułach pamięci podręcznej. Testy obciążeniowe nadal wymagają wyznaczonego przedziału czasowego oraz uzgodnionych progów przerwania.