Wykorzystanie strony stanu PHP-FPM do analizy wydajności

Co pokazuje strona stanu dotycząca puli

Strona stanu PHP-FPM pokazuje, jak działa określony basen Przetwarzane żądania PHP: między innymi liczba aktywnych lub wolnych procesów oraz to, czy są żądania oczekujące. Warunkiem jest, aby aplikacja była faktycznie obsługiwana przez PHP-FPM. Sama wersja PHP wyświetlana w wierszu poleceń nie określa ani tego, ani wersji odpowiedniej usługi FPM.

W związku z tym należy najpierw ustalić wersję FPM oraz pulę, do której serwer WWW przekierowuje aplikację. Obejmuje to używane gniazdo Unix lub słuchacz TCP oraz routing w odpowiednim wirtualnym hoście. To przyporządkowanie jest ważne, aby późniejsze zapytanie o status nie dotyczyło przypadkowo innej puli.

Jeśli serwer obsługuje kilka pul, wyświetlane informacje dotyczą konkretnej puli, o którą zapytano, a nie automatycznie wszystkich aplikacji PHP. W przypadku hostingu współdzielonego możesz nie mieć uprawnień do konfiguracji puli lub serwera WWW. W takim przypadku musisz polegać na tym, że dostawca udostępni stronę stanu lub podobne wskaźniki w trybie chronionym.

Wywołanie to przede wszystkim Migawka: Pomiędzy dwoma zapytaniami mogą pojawiać się i znikać krótkie kolejki. Inne wartości odliczają zdarzenia od momentu uruchomienia FPM; po ponownym uruchomieniu są one resetowane. Aby uzyskać miarodajny przebieg, należy zatem zapisywać czas pobrania i identyfikator puli wraz z wartościami.

Strona ta nie wyjaśnia całego czasu oczekiwania w przeglądarce. Na czas odpowiedzi mogą mieć wpływ również sieć, serwer WWW, baza danych i usługi zewnętrzne. Stanowi ona zatem punkt wyjścia do diagnozy puli PHP-FPM, a nie kompletny test wydajności strony internetowej.

Zrozumieć rolę pracowników i menedżerów procesów

Menedżer procesów określa, w jaki sposób pula udostępnia swoich pracowników. W przypadku static ich liczba pozostaje stała. dynamic dostosowuje liczbę do potrzeb w ramach skonfigurowanych limitów; ondemand uruchamia procesy w razie potrzeby. To, jakich wolnych mocy produkcyjnych możesz się spodziewać, zależy zatem również od ustawionego trybu pracy.

Aktywny proces właśnie przetwarza zapytanie; wolny proces jest gotowy do pracy. Duża liczba aktywnych procesów nie musi automatycznie oznaczać błędu: obciążona pula może szybko przetwarzać zapytania. Obserwacja ta nabiera większego znaczenia, gdy jednocześnie czekają zapytania, wydłużają się czasy odpowiedzi, a dostępnych jest niewiele wolnych procesów.

Nawet chwilowe wyczerpanie rezerwy samo w sobie nie stanowi jeszcze dowodu na trwały niedobór. Porównaj powtarzające się pobrania z skonfigurowanym Limit procesu oraz momentami, w których użytkownicy faktycznie odczuwają opóźnienia. W ten sposób łatwiej odróżnisz krótkotrwały skok obciążenia od powtarzającego się przeciążenia.

Większa liczba procesów może obsługiwać więcej żądań równolegle, ale wymaga dodatkowej pamięci i może powodować większe obciążenie baz danych lub usług zewnętrznych. Jeśli wiele procesów czeka na tę samą powolną zależność, zwiększenie limitu nie wyeliminuje przyczyny. Dlatego przed podjęciem działań sprawdź zasoby i czas trwania żądań, pm.max_children zmiana.

W ustaleniu podziału kompetencji w ramach stosu hostingowego pomocne jest porównanie NGINX Unit i PHP-FPM. Stanowi on uzupełnienie perspektywy architektonicznej; konkretne wartości stanów i ustawienia menedżera procesów nadal musisz sprawdzić w faktycznie używanej puli FPM.

Zabezpieczenie dostępu do statusu i FastCGI

Wyświetlane informacje o stanie mogą ujawniać poufne dane dotyczące zapytań i zasobów. W szczególności szczegóły procesu mogą zawierać adresy URI żądań, które pozwalają na identyfikację wywołanych funkcji lub przesłanych parametrów. Dlatego należy traktować tę stronę jako dostęp diagnostyczny, a nie jako publiczny panel stanu.

Ogranicz Dostęp HTTP w odpowiedzi na zapytania wewnętrzne lub w przypadku wyraźnie znanych adresów IP klientów. Należy przy tym sprawdzić, jaki adres serwer WWW faktycznie rozpoznaje jako adres klienta, jeśli przed nim znajduje się serwer proxy. Ochrona musi obejmować routing strony statusowej i powinna zostać sprawdzona przed jej udostępnieniem.

Niezależnie od tego, zapewnij sobie Dostęp do FastCGI samodzielnie. W przypadku gniazda Unix istotne są informacje o właścicielu i uprawnieniach; w przypadku protokołu TCP należy sprawdzić powiązanie sieciowe oraz dopuszczonych klientów. Blokada na serwerze WWW nie chroni portu FastCGI, do którego można uzyskać dostęp osobno z niewiarygodnej sieci.

W ramach projektu PHP odnotowano lukę typu XSS w wyświetlaniu statusu FPM (CVE-2026-6735). Wersje zawierające poprawki to PHP 8.4.21 i 8.5.6. W przypadku innych gałęzi wersjonowania i pakietów dystrybucyjnych należy sprawdzić aktualny stan zabezpieczeń lub dostępność poprawek przeniesionych do starszych wersji, zamiast opierać się wyłącznie na wyświetlanym numerze wersji przy ocenie poziomu ochrony.

Aktualizacja nie zastępuje ograniczeń dostępu: nawet poprawiona strona stanu może nadal ujawniać szczegóły operacyjne. Ogranicz zarówno dostęp HTTP, jak i moduł nasłuchujący do przewidzianego kręgu użytkowników i uwzględnij te dwie warstwy zabezpieczeń przy późniejszych zmianach w routingu.

Udostępnienie strony stanu w trybie chronionym

Najpierw należy ustalić, która pula FPM obsługuje daną aplikację oraz za pośrednictwem jakiego gniazda lub adresu TCP serwer WWW się z nią łączy. W przypadku wielu pul zapytanie o stan należy skierować do tej puli, do której zostanie ono przekazane. Sama wersja PHP podana w wierszu poleceń nie wskazuje, która usługa FPM jest odpowiedzialna za daną aplikację.

W pliku konfiguracyjnym odpowiedniej puli poniższy fragment aktywuje Ścieżka statusu. Nie jest to plik PHP, który musisz utworzyć w katalogu dokumentów. Ten fragment stanowi propozycję konfiguracji i zakłada, że masz uprawnienia do edycji konfiguracji puli.

pm.status_path = /fpm-status

Skonfiguruj na serwerze WWW odpowiednią trasę, która będzie przekierowywać żądania kierowane do tej ścieżki bezpośrednio przez FastCGI do wyznaczonej puli. Standardowy system routingu aplikacji nie może przechwytywać tego żądania. Ogranicz dostęp HTTP do żądań wewnętrznych lub znanych adresów IP klientów, a gniazdo FastCGI zabezpiecz niezależnie od tego za pomocą uprawnień lub powiązania sieciowego oraz dozwolonych klientów.

Przed zatwierdzeniem wdrożenia sprawdź zarówno konfigurację serwera WWW, jak i FPM, korzystając z procedur testowych przewidzianych w Twoim środowisku. Upewnij się, że wprowadzasz zmiany w odpowiedniej usłudze i puli oraz że ograniczenie dostępu obowiązuje również dla ścieżki statusu. Samo ustawienie ścieżki nie sprawia, że dane wyjściowe są dostępne przez HTTP.

W przypadku już skonfigurowanego, chronionego lokalnie środowiska poniższe polecenie terminala odczytuje dane wyjściowe w formacie JSON. Wymaga to, aby pod podanym adresem był dostępny odpowiedni lokalny wirtualny host HTTP. W przeciwnym razie należy dostosować adres i routing hosta, a także, w razie potrzeby, TLS do swojego środowiska; pobranie danych nie powoduje żadnych zmian w konfiguracji.

curl --fail --silent --show-error 'http://127.0.0.1/fpm-status?json'

W odpowiedzi sprawdź przede wszystkim nazwę puli. Komunikat o błędzie lub nieoczekiwany wynik działania aplikacji może wskazywać na nieprawidłowe przekierowanie; również blokada dostępu może uniemożliwić pobranie danych. Zanim pochopnie usuniesz zabezpieczenie, sprawdź konfigurację odpowiedniego serwera WWW oraz logi.

Jak prawidłowo interpretować i obliczać wskaźniki

Wartości stanu odnoszą się do różnych okresów: niektóre odzwierciedlają stan w momencie odczytu, inne zliczają zdarzenia lub rejestrują wartość maksymalną od momentu uruchomienia. Dla celów diagnostycznych to rozróżnienie jest ważniejsze niż pojedyncza nietypowa wartość. Poniższa tabela przedstawia klasyfikację kluczowych danych.

Dla Prędkość połączeniaodjąć dwie wartości od accepted conn od siebie i podziel różnicę przez upływający czas. Hipotetyczny przykład obliczeniowy, bez pomiaru: jeśli w ciągu 60 sekund licznik wzrośnie z 12 000 do 12 600, daje to średnio dziesięć hipotetycznych połączeń na sekundę. Nie można z tego bezpośrednio wywnioskować ani liczby wyświetleń stron, ani opóźnienia aplikacji.

Wraz z każdym punktem pomiarowym zapisz czas i identyfikator puli. Po ponownym uruchomieniu FPM wartości stanu zostaną zresetowane; różnica wykraczająca poza ten przedział nie stanowi zatem prawidłowej wartości. Wykryj spadek stanu licznika lub zmianę czasu rozpoczęcia i ponownie rozpocznij obliczenia dla nowego okresu.

Na stronie max children reached kluczową rolę odgrywa menedżer procesów: przykładowa konfiguracja PHP 8.4.21 opisuje licznik dla opcji „dynamic” i „ondemand”. W przypadku opcji „static” nie wolno traktować wartości zerowej jako dowodu na dostępną pojemność. Dla slow requests Próg i Slowlog muszą być odpowiednio skonfigurowane; próg określa, które długie zapytania są w ogóle rejestrowane.

Porównanie formatów wyjściowych i szczegółów procesu

Wersja skrócona pozwala uzyskać ogólny przegląd całej puli. Przy wyborze formatu decydujące znaczenie ma to, czy chcesz odczytywać wartości ręcznie, czy też regularnie przetwarzać je za pomocą systemu monitorowania. Parametr full rozszerza dane wyjściowe o szczegóły procesu; nie jest to samodzielny format wymiany danych.

Podręcznik PHP zawiera również informacje na temat XML i HTML. W przypadku automatycznego pobierania danych sprawdź faktycznie zainstalowaną wersję FPM oraz jej dane wyjściowe, zanim zaczniesz polegać na konkretnych polach lub szczegółach procesu. W szczególności należy zwrócić uwagę na połączenie OpenMetrics i full sprawdzić w własnej wersji, zamiast zakładać z góry dane dotyczące poszczególnych procesów.

Die Czas trwania żądania W wersji Full wartość ta podawana jest w mikrosekundach. W przypadku aktywnego procesu odnosi się ona do czasu trwania aktualnie przetwarzanej prośby; w przypadku procesu nieaktywnego dotyczy ostatnio przetworzonej prośby. Wysoka wartość dla wolnego pracownika nie oznacza zatem, że jest on w danej chwili zajęty przetwarzaniem tej prośby.

Pola last request cpu oraz last request memory w przypadku procesów aktywnych są wyświetlane jako zero, ponieważ ich ocena następuje dopiero po zakończeniu zapytania. Te wartości zerowe nie oznaczają zatem braku zużycia procesora lub pamięci. Powtarzające się odczyty mogą wskazać, czy proces pozostaje aktywny przez dłuższy czas; nie zastępują one jednak pełnego śledzenia aplikacji.

Analiza kolejek i powolnych żądań

Jeśli kolejka Jeśli sytuacja ta powtarza się, gdy wiele procesów jest aktywnych, a tylko kilka jest wolnych, to przeciążenie puli jest prawdopodobną hipotezą roboczą. Pojedyncze sprawdzenie nie wystarczy: porównaj kilka momentów i zwróć uwagę, czy w tym samym czasie wydłużają się czasy odpowiedzi na zapytania. Sama maksymalna długość kolejki nie wskazuje, czy w danej chwili czekają jeszcze jakieś zapytania.

Porównaj ten okres z logami FPM, obciążeniem procesora i dostępną pamięcią. Weź pod uwagę również bazę danych, pamięć podręczną i usługi zewnętrzne: jeśli PHP czeka na powolną zależność, procesy robocze pozostają zajęte, chociaż sama dodatkowa moc procesora niekoniecznie musi rozwiązać ten problem. Strona stanu pokazuje obciążenie, ale nie wskazuje w sposób wiarygodny jego przyczyny.

Wykorzystaj wielokrotnie chronioną wersję pełną podczas fazy, w której występują nietypowe zjawiska. Długi czas trwania żądania w ramach tego samego aktywnego procesu może wskazywać na długotrwałe zajęcie pracownika; w takim przypadku sprawdź stan procesu, ponieważ w przypadku procesu nieaktywnego czas ten odnosi się do jego ostatniego żądania. PID, URI i skrypt pomagają w identyfikacji, ale nie zapewniają pełnego śladu.

Zwłaszcza w przypadku kontrolera front-endowego ta sama nazwa skryptu może obejmować wiele różnych funkcji aplikacji. Dlatego warto uzupełnić tę obserwację o śledzenie działania aplikacji oraz odpowiednio skonfigurowany Slowlog. Jego próg określa, które długie żądania są rejestrowane; brak wpisu nie oznacza, że wszystkie żądania były szybkie. Jak dokładniej zinterpretować te wyniki, pokazuje artykuł na temat Analiza pliku slowlog PHP-FPM.

W celu porównania należy odnotować przedział czasowy oraz odpowiednią pulę. Dzięki temu można na przykład sprawdzić, czy powolne zapytanie do bazy danych zbiega się czasowo z zajętością procesorów, czy też kolejka zaczęła się wydłużać już wcześniej. Korelacja zawęża zakres poszukiwań, ale nie zastępuje jeszcze sprawdzenia konkretnego żądania.

Monitorowanie i awarie strony stanu

W przypadku powtarzających się szczytów obciążenia regularne, zabezpieczone odczyty są bardziej miarodajne niż sporadyczne pojedyncze pomiary. JSON nadaje się do zautomatyzowanego przetwarzania; OpenMetrics stanowi alternatywę, o ile zainstalowana wersja PHP i klient monitorujący są ze sobą zgodne. W przypadku każdego punktu pomiarowego zapisz czas oraz identyfikator puli, aby nie porównać przypadkowo różnych pul.

Lecz brakujące wywołania jako odrębne zdarzenia, a nie jako wartości zerowe. Luka może wynikać z problemów z siecią, zabezpieczeniami dostępu lub usługą stanu; sama w sobie nie oznacza ani pustej puli, ani awarii aplikacji. Dlatego należy również rejestrować błędy i przekroczenia limitu czasu podczas pobierania danych, aby luka była widoczna podczas późniejszej analizy.

Zwróć również uwagę na zresetowanie skumulowanych liczników po ponownym uruchomieniu FPM. Ujemna różnica między dwiema wartościami nie oznacza ujemnej szybkości połączenia; należy ponownie rozpocząć obliczenia po zresetowaniu i uwzględnić przerwany przedział czasu. Również czas rozpoczęcia i przypisanie do puli pomagają w zidentyfikowaniu takiej przerwy w przebiegu.

Jeśli zapytanie o stan jest przetwarzane przez tę samą pulę co aplikacja, może ono samooczekać w przypadku wyczerpania się liczby procesów roboczych. W takiej sytuacji pm.status_listen oddzielny moduł nasłuchujący FastCGI z niezależnie działającą wewnętrzną pulą. Umożliwia on diagnostykę stanu, gdy pula główna jest zajęta; nie zwiększa jednak jej wydajności przetwarzania.

Dodatkowy moduł nasłuchujący wymaga wyraźnie przypisanej, zabezpieczonej trasy na serwerze WWW. Zabezpiecz również jego dostęp FastCGI i po zatwierdzeniu zmiany sprawdź, czy wywołanie faktycznie zwraca żądany stan puli. W ten sposób diagnostyka pozostaje oddzielona od normalnej ścieżki aplikacji, bez udostępniania danych o stanie publicznie.

Sprawdź wyniki badań i wybierz odpowiednie działania

Komenda „ping” dla FPM i strona stanu dostarczają odpowiedzi na różne pytania. Komenda „ping” pokazuje, czy FPM odpowiada na dane żądanie; nie dostarcza ona jednak równoważnych informacji na temat wolnych procesów roboczych ani oczekujących żądań. Dlatego sam pomyślny wynik komendy „ping” nie oznacza, że nie ma powodu do niepokoju co do obciążenia puli aplikacji.

Jeśli dane procesowe nie zgadzają się z danymi z logów lub innymi obserwacjami, najpierw sprawdź przypisanie do puli, moment wywołania oraz ewentualną konieczność ponownego uruchomienia. Następnie porównaj wartości z innymi dostępnymi danymi procesowymi i eksploatacyjnymi. Traktuj odchylenie początkowo jako niejasny wynik, zamiast od razu wyciągać z niego wnioski dotyczące przyczyny lub koniecznej zmiany konfiguracji.

Jeśli powtarzające się wywołania typu „Full” i wpisy w dzienniku opóźnień (Slowlog) wykazują te same długotrwałe wzorce żądań, należy najpierw zbadać ścieżki aplikacji, których to dotyczy. Jeśli natomiast opóźnienie występuje w bazie danych lub usłudze zewnętrznej, ich analiza może przynieść lepsze efekty niż zmiana liczby procesów roboczych. Decydujące znaczenie ma to, czy dane działanie rozwiązuje zaobserwowaną przyczynę, a nie tylko pojedynczy objaw.

Dostosowanie pm.max_children Można to rozważyć, jeśli można wykazać, że pula działa na granicy swoich możliwości, a procesor, pamięć oraz usługi niższego szczebla są w stanie obsłużyć dodatkową równoległość. Większa liczba procesów roboczych wymaga zasobów i może zwiększyć obciążenie tych usług. Nie ma zatem jednej uniwersalnej wartości; przy ocenie należy uwzględnić tryb pracy menedżera procesów.

Po wprowadzeniu zatwierdzonej zmiany ponownie porównaj tę samą pulę w możliwie podobnych warunkach obciążenia: kolejka, czasy odpowiedzi, błędy i zużycie zasobów są ze sobą powiązane. Odnotuj również, jeśli dane działanie nie przynosi poprawy lub powoduje większe obciążenie zależności. Dopiero to Porównanie „przed i po” umożliwia podjęcie uzasadnionej decyzji co do dalszego postępowania.