Testy wydajności procesorów serwerowych pod kątem PHP: testy rzeczywistych obciążeń w hostingu internetowym

Na jakie pytania powinien odpowiadać test wydajnościowy PHP

Test wydajności procesora w PHP może przede wszystkim pokazać, ile czasu system potrzebuje na wykonanie określonego zadania obliczeniowego. Jest to szczególnie przydatne, gdy pojedyncze żądanie zajmuje dużo czasu na obliczenia w PHP. Wyższa Wydajność jednonukleowa może skrócić czas przetwarzania takich zadań; jednak na podstawie samej wartości CPU nie da się określić czasu odpowiedzi całej witryny internetowej.

Drugie pytanie dotyczy zachowania aplikacji w przypadku jednoczesnych dostępów: ile poprawnych odpowiedzi generuje ona na sekundę i jak długo użytkownicy muszą w tym przypadku czekać? W tym celu służy Test porównawczy usług hostingowych przez HTTP. Uwzględnia on przebieg przetwarzania przez serwer WWW i PHP, a także – w razie potrzeby – bazę danych, pamięć podręczną i sieć. Właśnie ta kombinacja sprawia, że jest on zbliżony do rzeczywistych warunków, uniemożliwia jednak sformułowanie izolowanej oceny dotyczącej procesora.

Trzecie pytanie dotyczy wąskiego gardła. Jeśli na przykład żądanie oczekuje na wynik zapytania do bazy danych, szybsze wykonanie operacji obliczeniowej nie ma większego wpływu na jego całkowity czas. Również pamięć podręczna wpływa na wynik: jeśli strona zostanie w całości dostarczona jeszcze przed uruchomieniem PHP, wywołanie nie mierzy czasu wykonania dynamicznej aplikacji.

Ponadto przy obciążeniu równoległym pula PHP-FPM może ograniczać liczbę żądań przetwarzanych jednocześnie. Jej strona stanu zawiera między innymi informacje o zajętych procesach i żądaniach oczekujących. Rosnąca kolejka jest zatem powodem do przeprowadzenia diagnostyki, a nie bezpośrednim dowodem na zbyt wolne działanie procesora.

Przy wyborze hostingu warto rozpatrywać te kwestie osobno: najpierw porównywalną jednostkę pracy, następnie działanie przy niskim i wyższym obciążeniu, a na koniec zasoby, które ograniczają wynik. Jak zasadniczo współdziałają ze sobą procesor, pamięć operacyjna i pamięć masowa, wyjaśnia artykuł poświęcony Sprzęt do wysokowydajnego hostingu internetowego.

Rozróżnienie wyników testów procesora i testów aplikacji

A Mikrobenchmark wielokrotnie wykonuje niewielkie, ściśle zdefiniowane zadanie. Za pomocą PHPBench można na przykład zbadać działanie funkcji przetwarzającej dane w określonych warunkach. Wynik pomaga w porównaniu tej funkcji z jej środowiskiem wykonawczym; nie opisuje on jednak automatycznie ani kompletnego zapytania, ani wydajności systemu CMS lub sklepu internetowego.

Test aplikacji HTTP odpowiada na inne pytanie: jak wybrana aplikacja reaguje w ramach faktycznie wykorzystywanej struktury internetowej? Uwzględnia on na przykład PHP-FPM, bazę danych i pamięci podręczne, o ile biorą one udział w testowanym wywołaniu. Dzięki temu nadaje się on do oceny oferty hostingowej, ale sam w sobie nie jest w stanie wykazać, który komponent odpowiada za daną różnicę.

SPEC CPU uzupełnia takie testy o znormalizowane obciążenia wymagające intensywnych obliczeń. SPEC CPU 2026 zawiera zestawy testów dla liczb całkowitych i zmiennoprzecinkowych, a także wyniki dotyczące prędkości (Speed) i przepustowości (Rate). Prędkość odnosi się do czasu wykonania zadań, a przepustowość – do wydajności. Wartość prędkości nie jest automatycznie wartością odnoszącą się wyłącznie do jednego rdzenia: w testach prędkości operacji całkowitoliczbowych w pakiecie 2026 SPEC wskazuje na dodatkową równoległość.

Aby porównanie SPEC było miarodajne, należy uwzględnić pakiet testów, metrykę oraz rodzaj wyników wartość bazowa lub szczytowa są zgodne. Równie ważne jest, aby system został w pełni przetestowany: oprócz procesora na wynik wpływają między innymi pamięć, kompilator i konfiguracja. Opublikowane wartości nie są zatem odosobnioną cechą danego modelu procesora i nie zastępują testu PHP.

SPEC CPU 2017 i CPU 2026 wykorzystują różne zestawy testów; ich wyniki nie są porównywalne w tej samej skali. Osoba dokonująca wstępnego wyboru powinna zatem porównać pełny raport z wynikami zamiast skróconego rankingu. Dopiero odpowiednio skonfigurowany test aplikacyjny pozwoli ustalić, czy dany procesor jest odpowiedni dla danego zastosowania.

Określenie porównywalnych warunków testowych

Rzetelne porównanie zaczyna się od tej samej wersji aplikacji i porównywalnego zbioru danych. Również wybrana ścieżka i oczekiwana odpowiedź muszą być zgodne: strona produktu wymagająca wielu operacji na bazie danych odpowiada na inne pytanie niż prosta funkcja API. Dlatego należy sprawdzić nie tylko, czy odpowiedź nadeszła, ale także, czy jej treść jest zgodna z zamierzonym zadaniem.

Należy odnotować wersję PHP i rozszerzenia, a także serwer WWW, konfigurację PHP-FPM oraz bazę danych. W protokole należy również uwzględnić ścieżkę sieciową między generatorem obciążenia a aplikacją. Różne ścieżki lub lokalizacje baz danych mogą wpływać na zmierzony czas odpowiedzi, nawet jeśli wykonywanie kodu PHP przebiegałoby z taką samą szybkością na obu systemach.

Szczególnie ważne jest oddzielenie CLI i PHP-FPM: Test przeprowadzony w wierszu poleceń nie uwzględnia automatycznie tej samej konfiguracji środowiska uruchomieniowego, co żądanie HTTP. Należy udokumentować faktycznie stosowane ustawienia OPcache i JIT dla obu kontekstów. Ich działanie i wartości domyślne zależą między innymi od wersji PHP; ogólne założenie nie wystarczy do porównania.

The Stan pamięci podręcznej musi być porównywalny. Zimna pamięć podręczna i już rozgrzana pamięć podręczna dostarczają odpowiedzi na różne pytania; obie mogą być istotne, ale należy je analizować oddzielnie. To samo dotyczy ilości danych i danych testowych: jeśli zmienia się zakres prac, różnicy w czasie nie można już jednoznacznie przypisać systemowi.

Należy również odnotować model procesora, przydzielone vCPU i widoczne limity zasobów, a także wybrane obciążenie i liczbę powtórzeń. Jeśli celowo porównuje się dwa różne pakiety hostingowe, wynik stanowi informację na temat ich odpowiednich konfiguracji ogólnych. Różnice dotyczące procesora, limitów, bazy danych lub buforowania nie mogą być wówczas interpretowane wyłącznie jako przewaga procesora bez przeprowadzenia dalszej diagnostyki.

Wybór odpowiednich obciążeń i wskaźników

Wybór testu zależy od pytania, na które chcesz uzyskać odpowiedź. Jeden Mikrobenchmark analizuje ograniczone zadanie obliczeniowe; test HTTP uwzględnia przebieg przez stos technologiczny. Wyniki testów SPEC uzupełniają porównanie o znormalizowane testy systemowe wymagające dużej mocy obliczeniowej procesora, nie zastępują jednak testu własnej aplikacji PHP.

W przypadku pojedynczego zapytania dynamicznego wybierz reprezentatywną stronę lub trasę API i zacznij od niskiego poziomu równoległości. Trasa musi faktycznie wykonywać kod PHP: odpowiedź dostarczona w całości z poprzedzającej pamięci podręcznej stron byłaby co prawda prawidłowym testem pamięci podręcznej, ale niewiele mówi o przetwarzaniu w PHP.

W przypadku jednoczesnych użytkowników sprawdzasz ten sam punkt końcowy przy kilku określonych poziomach obciążenia. Pozwala to ustalić, czy czasy odpowiedzi i przepustowość z powodzeniem zmieniają się wraz ze wzrostem równoległości. W przypadku trasy intensywnie wykorzystującej bazę danych zasoby danych, lokalizacja bazy danych oraz stan pamięci podręcznej powinny pozostać niezmienne między kolejnymi przebiegami porównawczymi.

Funkcję aplikacji obciążającą procesor można dodatkowo zbadać w izolacji za pomocą narzędzia PHPBench – na przykład przetwarzanie danych bez dostępu do sieci. Lepszy wynik wskazuje na razie jedynie na korzyść dla tej funkcji w wybranych warunkach działania. Czy przełoży się to na odczuwalną korzyść dla całej strony, musi wykazać test aplikacji.

Przeprowadź test stagingowy za pomocą wrk

Testy należy przeprowadzać wyłącznie za wyraźną zgodą, w odizolowanym środowisku testowym. Należy skonfigurować bezpieczną, reprezentatywną ścieżkę odczytu i wykorzystać odpowiednie dane testowe. Przed rozpoczęciem należy określić maksymalne obciążenie oraz kryteria przerwania testu, takie jak występujące błędy, przekroczenie limitów czasu lub zakłócenie działania innych usług.

Poniższe polecenie jest przeznaczone dla terminala działającego na lokalnej instancji stagingowej, skonfigurowanej specjalnie w tym celu. Przygotowana trasa musi być dostępna na porcie 8080; polecenie to faktycznie generuje obciążenie i nie jest przeznaczone dla nieznanego lub produkcyjnego systemu.

wrk -t2 -c4 -d30s --latency http://127.0.0.1:8080/

Wywołanie wykorzystuje dwa wątki generatora obciążenia, cztery otwarte połączenia i czas trwania wynoszący 30 sekund. Opcja --latency żąda szczegółowych danych dotyczących opóźnień. Cztery połączenia stanowią w tym przypadku wybrany punkt wyjścia dla tego przykładu, a nie ogólną rekomendację dotyczącą liczby odwiedzających lub wydajności serwera.

Jednak standardowe dane dotyczące percentyli generowane przez wrk nie zawierają wartości p95. Aby uzyskać powtarzalną analizę p95, zapisz poniższy skrypt Lua na generatorze obciążenia jako percentiles.lua. Statystyka latencji podaje wartości p50 i p95 w mikrosekundach; po podzieleniu przez 1 000 otrzymujemy milisekundy.

function done(summary, latency, requests)
  io.write(string.format("p50: %.0f us\n", latency:percentile(50.0)))
  io.write(string.format("p95: %.0f us\n", latency:percentile(95.0)))
end

Aby przeprowadzić właściwy pomiar, uruchom ten sam lokalny test stagingowy za pomocą skryptu. Ścieżka do pliku odnosi się do terminala znajdującego się w katalogu, w którym znajduje się plik skryptu. Również to wywołanie generuje obciążenie; udokumentuj oba wyświetlone percentyle wraz z błędami oraz oddzielnie sprawdzoną jakością odpowiedzi.

wrk -t2 -c4 -d30s --latency -s percentiles.lua http://127.0.0.1:8080/

Zaplanuj osobną Faza rozgrzewki zanim zaczniesz rejestrować właściwe pomiary. Następnie powtórz każdy ustalony poziom obciążenia i, w miarę możliwości, zmieniaj kolejność systemów porównawczych. Zanotuj, jak długo trwało rozgrzewanie oraz czy pamięć podręczna znajdowała się w pożądanym stanie na początku pomiaru.

Zwiększaj liczbę połączeń wyłącznie w ramach uzgodnionych limitów i po każdym etapie sprawdzaj kryteria przerwania. Obserwuj również generator obciążenia: jeśli sam jest w pełni obciążony, może to ograniczyć wynik. Dodatkowo sprawdź kody statusu i treść odpowiedzi; szybko wyświetlona strona błędu lub nieprawidłowa odpowiedź nie są uznawane za pomyślne żądanie aplikacji.

Dokumentowanie poziomów obciążenia i wyników

Protokół pomiarowy łączy dane liczbowe z warunkami, w jakich zostały uzyskane. Dla każdego przebiegu zanotuj warunki otoczenia, punkt końcowy, stan pamięci podręcznej oraz poziom obciążenia wraz z wynikami. Poniższa tabela wykorzystuje między innymi wartości dostarczane przez wrk lub stronę stanu FPM; musisz samodzielnie uzupełnić weryfikację treści odpowiedzi.

Mediana określa środek obserwowanych czasów odpowiedzi. To p95 jest to wartość, której nie przekracza 95 procent zmierzonych odpowiedzi. Obie wielkości razem pokazują, czy oprócz typowych zapytań zmienia się również wolniejsza część rozkładu. Należy je zawsze interpretować w połączeniu z błędami i przekroczeniami limitu czasu.

Należy odróżnić stałą liczbę połączeń od z góry określonej częstotliwości zapytań. W przypadku testu opartego na połączeniach, takiego jak ten z przykładu, powolne odpowiedzi mogą spowodować, że przez te same połączenia generowanych będzie mniej nowych zapytań na sekundę. Zmierzona latencja nie odzwierciedla wówczas wprost zachowania przy niezmiennie wysokiej częstotliwości przychodzących żądań.

Dlatego należy porównywać wyłącznie wystarczająco podobne punkty obciążenia: tę samą trasę i test odpowiedzi, porównywalne stany pamięci podręcznej, a także ten sam model obciążenia i ten sam poziom obciążenia. Niska wartość p95 przy niskim stopniu równoległości nie jest bezpośrednio porównywalna z wartością p95 w warunkach przeciążenia. Należy przedstawić wyniki kilku przebiegów testu wraz z ich rozrzutem, zamiast podawać jako wynik pojedynczą korzystną wartość.

Analiza FPM i limitów zasobów

Jeśli wraz ze wzrostem obciążenia rośnie zarówno długość kolejki, jak i czas odpowiedzi p95, warto przyjrzeć się puli PHP-FPM. Porównaj aktualne wartości dla active processes, idle processes oraz listen queue z ustawionym limitem górnym pm.max_children. Jeśli wszystkie dozwolone procesy są aktywne, nie ma wolnych procesów, a żądania oczekują, oznacza to, że Granica basenu lub pracowników zatrudnionych od dłuższego czasu, ale niekoniecznie oznacza to, że procesor działa zbyt wolno.

Ogłoszenie max children reached Natomiast dokumentuje to wcześniejsze osiągnięcie limitu procesów od momentu uruchomienia puli. Samo w sobie nie świadczy to ani o obecności kolejki, ani o tym, że wszystkie istniejące procesy są właśnie zajęte. Podobnie maksymalna liczba istniejących procesów nie oznacza, że wszystkie są aktywne.

Procesy robocze mogą również czekać na wyniki zapytań do bazy danych lub inne usługi zewnętrzne. Dlatego należy porównać stan puli i obciążenie procesora z obserwowanymi czasami odpowiedzi: pełna kolejka przy niskim obciążeniu procesora sugeruje, że należy najpierw zbadać czasy oczekiwania i zajętość procesów roboczych. Zwiększenie liczby puli nie jest automatycznie rozwiązaniem, ponieważ dodatkowe procesy również wymagają zasobów.

Wartości stanu FPM dotyczą danej puli; liczniki są resetowane po ponownym uruchomieniu. W związku z tym należy odnotować w protokole pomiarowym informacje o puli oraz momencie ponownego uruchomienia i porównywać stany liczników wyłącznie w ramach odpowiedniego okresu. Należy zabezpieczyć aktywowaną stronę stanu przed nieuprawnionym dostępem, ponieważ ujawnia ona informacje dotyczące działania puli.

W przypadku serwerów VPS i hostingu współdzielonego przydzielony procesor vCPU niekoniecznie oznacza wyłączny rdzeń fizyczny. Tam, gdzie dostępne są dane cgroup-v2, pokazuje cpu.max skonfigurowane ograniczenie przepustowości procesora; cpu.stat może obejmować między innymi liczniki dla Dławienie zawarte. Zmiany wartości tych liczników w trakcie działania pomagają w zdiagnozowaniu skutecznego ograniczenia.

W miarę możliwości sprawdź również nadrzędne grupy cgroup: limit ustawiony w tych grupach może wpływać na dostępny czas obliczeniowy, nawet jeśli bezpośrednio widoczna konfiguracja wydaje się dość liberalna. Nie każdy licznik w pełni odzwierciedla odziedziczone ograniczenia. Jeśli informacje te nie są zawarte w pakiecie hostingowym, ograniczona widoczność stanowi wyraźne ograniczenie analizy.

Wykrywanie rozrzutu i błędów pomiarowych

Pojedynczy przebieg może dać przypadkowo korzystny lub niekorzystny obraz sytuacji. Powtórz te same poziomy obciążenia w ustalonych momentach i, w miarę możliwości, zmieniaj kolejność systemów porównawczych. Zwłaszcza w przypadku współdzielonych zasobów dostępna moc może ulegać wahaniom; dlatego oprócz typowego wyniku podaj również zaobserwowaną rozproszenie oraz liczbę biegów.

Upewnij się, że powtórzenia korzystają z tego samego stanu pamięci podręcznej i tego samego zestawu danych. Przebieg z „ciepłą” pamięcią podręczną stron lub bazy danych nie jest bezpośrednio porównywalny z przebiegiem z „zimną” pamięcią podręczną. Jeśli pozornie szybsza odpowiedź pochodzi w całości z pamięci podręcznej stron, nie mówi to zbyt wiele o tym, jak szybko PHP wykonuje operacje dynamiczne.

Mikrobenchmark CLI również nie jest wynikiem FPM: działa on w innym kontekście wykonania i może korzystać z innych ustawień OPcache lub JIT. Należy oddzielnie udokumentować faktycznie aktywne ustawienia obu środowisk uruchomieniowych, zamiast wywodzić je z wersji PHP. Przewaga osiągnięta w mikrotestach niekoniecznie musi przejawiać się w takim samym stopniu w teście HTTP aplikacji.

Do pomyślnej przepustowości zaliczaj wyłącznie poprawne merytorycznie i pomyślnie zakończone odpowiedzi. Szybkie strony błędów lub przekroczenia limitu czasu mogą w przeciwnym razie znacznie zafałszować porównanie. W przypadku zauważalnych odchyleń sprawdź również czasy oczekiwania na bazę danych, zmiany w pamięci podręcznej oraz widoczne limity zasobów, zanim przypiszesz różnicę wyłącznie procesorowi.

Das Charakterystyka taktowa może również przyczyniać się do rozproszenia. To, jakie ustawienie częstotliwości jest właściwe, zależy od platformy i obciążenia; ogólne ustawienie nie zastępuje porównania przeprowadzonego w tych samych warunkach. Wkład w Regulator wydajności procesora na serwerach hostingowych wyjaśnia zależności niezbędne do przeprowadzenia dogłębnej analizy.

Wykorzystanie wyników przy wyborze dostawcy usług hostingowych

W przypadku zapytań, które w przeważającej mierze obciążają procesor, Czas na jedną jednostkę pracy ważne kryterium wyboru. W tym celu porównaj reprezentatywną funkcję PHP pod kątem udokumentowanego czasu wykonania, a następnie sprawdź, czy ta przewaga jest widoczna również w przypadku dynamicznej trasy HTTP. Mikrotest wydajności opisuje na początku jedynie testowany kod, a nie całą ofertę hostingową.

Jeśli spodziewasz się dużej liczby jednoczesnych użytkowników, szybka odpowiedź na pojedyncze zapytanie nie wystarczy. Decydujące znaczenie ma również to, ile poprawnych odpowiedzi na sekundę system generuje przy określonym poziomie obciążenia oraz jak zachowuje się opóźnienie p95 w ramach dopuszczalnego zakresu błędów. System o większej przepustowości niekoniecznie jest lepszym rozwiązaniem dla Twojego projektu, jeśli jego powolne odpowiedzi przekraczają dopuszczalne wymagania.

W przypadku aplikacji opartych na bazach danych lub pamięci podręcznej należy nadać wagę Test działania jest ważniejszy niż wynik CPU. Typowa trasa z porównywalnym zestawem danych pokazuje, jak współdziała stos w wybranych warunkach. Wynik SPEC może uzupełniać wstępną selekcję, ale opisuje on przetestowany system i nie zastępuje testu hostingu PHP.

Przed dokonaniem wyboru określ, jakie czasy odpowiedzi, wskaźniki błędów i poziomy obciążenia są dopuszczalne dla danej aplikacji. Następnie porównuj wyłącznie wyniki odpowiadające odpowiedniemu modelowi obciążenia i porównywalnemu stanowi pamięci podręcznej. Różne pakiety hostingowe należy oceniać jako całościowe konfiguracje; na podstawie różnic między nimi nie da się wyodrębnić udziału procesora bez przeprowadzenia dalszej diagnostyki.

Decyzja ta dotyczy aktualnego stanu, a nie każdej późniejszej wersji aplikacji ani szczytowego obciążenia. Powtórz odpowiednie testy po wprowadzeniu istotnych zmian w PHP, aplikacji, bazie danych, pamięci podręcznej lub limitach zasobów. W ten sposób sprawdzisz, czy rezerwy, które wcześniej były wystarczające, nadal są dostępne w nowych warunkach.