Porównanie handlerów PHP: CGI, FPM i LSAPI w hostingu

Porównanie obsługi PHP jasno pokazuje, w jaki sposób CGI, PHP-FPM i LSAPI kontrolują wykonywanie skryptów PHP, a tym samym charakteryzują opóźnienia, izolację i wymagania dotyczące pamięci RAM w hostingu. Wyjaśniam różnice w praktyczny sposób, kategoryzuję je według obciążeń i podaję zalecenia dotyczące wyboru i konfiguracji w codziennej pracy.

Punkty centralne

• WydajnośćLSAPI prowadzi pod względem opóźnień, PHP-FPM zapewnia bardzo stały czas odpowiedzi.
• BezpieczeństwoCGI ściśle oddziela, PHP-FPM izoluje za pomocą pul, LSAPI hermetyzuje na użytkownika.
• ZasobyLSAPI oszczędza pamięć RAM, PHP-FPM pozostaje wydajny, CGI generuje narzut.
• KompatybilnośćPHP-FPM pasuje do Apache/Nginx, LSAPI świeci z LiteSpeed.
• PraktykaDla CMS i sklepów używam głównie PHP-FPM; duży ruch często korzysta z LSAPI.

Podstawy obsługi PHP

Program obsługi PHP łączy serwer WWW z usługą Interpreter PHP. CGI uruchamia nowy proces dla każdego żądania i w ten sposób osiąga bardzo czystą separację między kontami. Separacja ta kosztuje czas, ponieważ każde żądanie przeładowuje rozszerzenia i konfigurację. PHP-FPM utrzymuje stałych pracowników i dystrybuuje żądania do pul, co zmniejsza koszty uruchamiania i utrzymuje niskie opóźnienia. LSAPI głęboko integruje się z LiteSpeed i używa bardzo lekkich, długotrwałych procesów dla Wysoka wydajność.

Mod_php integruje PHP bezpośrednio z serwerem WWW, ale izolacja jest słaba. Preferuję nowoczesne programy obsługi, ponieważ minimalizują one źródła błędów i utrzymują platformę bardziej stabilną pod obciążeniem. Jeśli hostujesz wielu użytkowników w jednym systemie, z pewnością skorzystasz z oddzielnych Konteksty użytkownika. To właśnie tutaj pule FPM i LSAPI wykorzystują swoje mocne strony. CGI pozostaje bezpieczną, ale powolną opcją dla bardzo małych witryn i specjalnych scenariuszy testowych.

Tabela porównawcza: mocne strony i scenariusze zastosowań

Poniższa tabela podsumowuje podstawowe funkcje i przypisuje je do typowych obciążeń. Używam jej jako szybkiej pomocy w podejmowaniu decyzji dla hosting php-konfiguracje z CMS, sklepami lub API. Należy pamiętać, że rzeczywista wydajność zależy również od buforowania, pamięci masowej i profilu sieci. Niemniej jednak przegląd ten stanowi solidny punkt wyjścia do wstępnego wyboru. Następnie dopracowuję konfigurację w oparciu o konkretne profile obciążenia i Zmierzone wartości.

Handler	Wydajność	Bezpieczeństwo	Zużycie pamięci RAM	Skalowalność	Odpowiedni dla
CGI	Niski	Bardzo wysoki	Wysoki	Niski	Testy, strony statyczne lub rzadko odwiedzane
PHP-FPM	Bardzo wysoki	Wysoki	Niski	Wysoki	Hosting współdzielony, CMS, API
LSAPI	Najwyższy	Średni do wysokiego (na użytkownika)	Bardzo niski	Bardzo wysoki	Duży ruch, e-commerce, współbieżność

Wyniki CGI z Separacja, ale cierpi z powodu kosztów uruchomienia procesu. PHP-FPM oferuje najlepszy stosunek opóźnień, przepustowości i izolacji w systemach z Apache lub Nginx. LSAPI zapewnia bardzo niskie opóźnienia przy dużej konkurencji na stosach LiteSpeed. Jeśli nie korzystasz z serwera LiteSpeed, FPM oferuje najszersze wsparcie. W przypadku bardzo małych witryn trzymam się prostych konfiguracji; w przypadku rozwijających się projektów przełączam się na FPM lub LSAPI.

Wydajność pod obciążeniem: opóźnienia i przepustowość

Wśród rosnącej konkurencji, opóźnienia P95/P99 i Stabilność przepustowości. LSAPI utrzymuje najwyższe obciążenia z zaskakująco stałymi czasami odpowiedzi. PHP-FPM podąża tuż za nim i bardzo dobrze reaguje na dostrajanie puli, na przykład z dynamicznymi numerami procesów. CGI zauważalnie traci prędkość, gdy tylko pojawi się wiele krótkich żądań. Aby uzyskać bardziej szczegółowe pomiary, zapoznaj się z moimi Porównanie wydajności, który obejmuje typowe obciążenia CMS i sklepu.

Konsekwentnie łączę FPM lub LSAPI z OPcache, dzięki czemu kod bajtowy nie jest generowany ciągle od nowa. Ponadto, cache reverse proxy zmniejsza liczbę trafień PHP dla powtarzających się treści. Kolejka zadań jest opłacalna w przypadku zadań wymagających dużej mocy obliczeniowej, dzięki czemu żądania frontendu pozostają szybkie. Jeśli chcesz przechwycić sporadyczne szczyty, użyj krótkotrwałego skalowania burst za pomocą dodatkowych pracowników FPM. Utrzymuje to opóźnienia ogona w granicach limitów i Czasy reakcji spójne.

Bezpieczeństwo i izolacja w hostingu współdzielonym

Co się liczy w środowiskach wieloużytkownikowych Izolacja co najmniej tak samo jak szybkość. CGI osiąga bardzo czystą separację poprzez procesy per-request, ale z dużym narzutem. PHP-FPM izoluje procesy per pula i pozwala na twarde limity pamięci, czasu wykonania i liczby procesów. LSAPI również przypisuje procesy do kont, ale jest szczegółowo powiązany ze stosem LiteSpeed. Jeśli chcesz skategoryzować ryzyko, najlepiej przeczytaj mój artykuł na temat Łączenie ryzyka z FPM i wyznacza wyraźne granice.

Ustawiłem osobne konto dla każdego konta. basen z własnym UID/GID i restrykcyjnymi uprawnieniami. Ogranicza to promień możliwych ataków i uniemożliwia błędnym skryptom dostęp do danych zewnętrznych. Obejmuje to limity pamięci, maksymalne żądania na pracownika i limity czasu. Regularne aktualizacje i bezpieczne uprawnienia do plików uzupełniają koncepcję. Ograniczam do minimum skrypty administratora, które są dostępne w sieci lub chronię je za pomocą Auth.

Zużycie zasobów i zarządzanie pamięcią RAM

Pamięć RAM często określa Koszty i gęstość na serwer. LSAPI zdobywa tutaj punkty dzięki bardzo małemu śladowi na proces i ekonomicznym przełącznikom kontekstowym. PHP-FPM również pozostaje wydajny, jeśli dynamicznie tworzę pule i odpowiednio wymiaruję limity. CGI marnuje pamięć z powodu częstego przeładowywania rozszerzeń i dlatego nie nadaje się do dynamicznych projektów. W przypadku hostowania wielu kont, FPM lub LSAPI zapewnia znacznie większe rezerwy na węzeł i utrzymuje Całkowite koszty możliwe do zaplanowania.

Regularnie mierzę szczytową ilość pamięci RAM i obserwuję jej rozkład w ciągu dnia. Szczyty wskazują na zbyt niską liczbę pracowników lub niekorzystne strategie buforowania. Zmniejszam zapotrzebowanie dzięki dokładniejszemu doborowi puli i ukierunkowanemu dostrajaniu OPcache. Zmniejsza to ryzyko związane z wymianą i zapobiega nieprzewidywalnym wartościom odstającym opóźnień. Na przepełnionych hostach przenoszę poszczególne Strony na własnych węzłach, zanim ucierpi na tym ogólna wydajność.

Kompatybilność z Apache, Nginx i LiteSpeed

Wybór serwera internetowego kieruje decyzją na poziomie Handler. PHP-FPM działa doskonale za Nginx i może być czysto podłączony do Apache przez proxy. W środowiskach Apache zalecam mpm_event, strojenie keep-alive i stabilną konfigurację proxy. LSAPI rozwija swój pełny potencjał z LiteSpeed i sprawnie odczytuje pliki .htaccess. Ci, którzy już korzystają z LiteSpeed, często uzyskują ostatni bit wydajności dzięki LSAPI. Wydajność na zewnątrz.

W przypadku treści statycznych używam Nginx lub LiteSpeed bezpośrednio z pamięci podręcznej serwera WWW. PHP przetwarza tylko to, co musi pozostać dynamiczne. Taka separacja zmniejsza obciążenie programu obsługi i oszczędza czas procesora. Efektem ubocznym jest zwiększenie spójności TTFB przy powtarzających się żądaniach stron. Oznacza to, że frontend pozostaje responsywny, nawet jeśli Backendy są pod presją.

Najlepsze praktyki dla pul PHP FPM

Zaczynam od konserwatysty Układ basenu na witrynę i mierzę rzeczywiste wartości szczytowe. Następnie dostosowuję pm, pm.max_children, pm.start_servers i pm.max_requests. Zbyt małe pule powodują, że żądania czekają, a zbyt duże pule pochłaniają pamięć RAM i generują przełączniki kontekstu. W przypadku WordPress, WooCommerce lub TYPO3 zwykle wybieram dynamiczne lub na żądanie i ściśle reguluję limity. Szczegóły dotyczące pm.max_children można znaleźć w moim przewodniku pm.max_children podsumował.

Ustawiłem limity takie jak memory_limit i max_execution_time na pulę. Zapobiega to blokowaniu zasobów przez poszczególne skrypty lub wymykaniu się spod kontroli. request_terminate_timeout chroni przed zawieszaniem się procesów, które w przeciwnym razie mogłyby się spiętrzać. max_input_vars i upload_max_filesize są rozsądnie zabezpieczone, w zależności od projektu. Dzięki temu pule sterowalny a host jest stabilny.

Buforowanie i OPcache w praktyce

Dla mnie OPcache jest częścią każdego Instalacja PHP. Aktywuję go, sprawdzam rozmiar i monitoruję wskaźnik trafień. W przypadku wielu wdrożeń ustawiam file_cache_only i dostrajam revalidate_freq, aby wdrożenia zaczęły działać szybko. Używam również odwrotnych cache proxy i wtyczek page cache w CMS, aby zmniejszyć współczynnik trafień PHP. Im mniej żądań faktycznie trafia do PHP, tym lepiej się skaluje wszystko.

Ci, którzy intensywnie korzystają z sesji po stronie serwera, często korzystają z Redis. Reguluję TTL i ściśle zarządzam limitami pamięci. W przypadku cache'owania pełnostronicowego rozważam klucze cache'owania i strategie unieważniania, aby sklepy dostarczały poprawnie po zmianach cen lub zapasów. Przejrzysty plan pamięci podręcznej oszczędza procesor, pamięć RAM i czas. Interakcja między OPcache, proxy cache i Pamięć podręczna aplikacji ostatecznie określa postrzeganą prędkość.

Matryca decyzyjna: Który handlowiec pasuje do którego projektu?

Małe witryny z niewielkim ruchem działają bezpiecznie z PHP-FPM i konserwatywne limity. Czyste środowiska testowe lub specjalne wymagania dotyczące zgodności mogą sprawić, że CGI będzie przydatne, pomimo utraty szybkości. Sklepy o dużym natężeniu ruchu i wysoce konkurencyjne API często korzystają z LSAPI na LiteSpeed. Jeśli potrzebujesz maksymalnej kompatybilności i elastyczności, możesz polegać na FPM. W przypadku hostingu php z WordPressem lub WooCommerce preferuję FPM jako wszechstronne rozwiązanie. Wszechstronny Przedtem.

Nigdy nie podejmuję decyzji wyłącznie na podstawie benchmarku. Zamiast tego mierzę rzeczywistą mieszankę statycznych odsłon, dynamicznych stron i wywołań API. Średni czas skryptu i odsetek trafień z pamięci podręcznej również wpływają na wybór. Biorę również pod uwagę nawyki administratorów, takie jak częste wdrożenia lub procesy kompilacji. Najlepszym rozwiązaniem pozostaje to, które działa w rzeczywistych warunkach. Warunki stabilny i szybki.

Koszty, licencja i eksploatacja - co się opłaca?

Na temat czystych kosztów FPM atrakcyjny, ponieważ nie wymaga dodatkowych licencji. LSAPI może obniżyć koszty operacyjne na witrynę dzięki lepszej gęstości i niższym opóźnieniom, ale wymaga licencji LiteSpeed w euro. Dla wielu płacących klientów jest to często opłacalne, ale zwykle nie dla projektów hobbystycznych. CGI powoduje koszty pośrednie poprzez nieefektywne wykorzystanie zasobów i dłuższe czasy reakcji. Dlatego obliczam ogólną operację i oszczędzam tam, gdzie ma to sens. jakość nie są zagrożone.

Zdolność do planowania pozostaje ważna. Host, który jest zbyt mocno przepełniony, oszczędza pieniądze w krótkim okresie, ale płaci za to przestojami i niezadowolonymi użytkownikami. Nowoczesne narzędzia obserwacyjne pomagają rozpoznać wąskie gardła na wczesnym etapie. Ci, którzy regularnie zwiększają przepustowość, utrzymują opóźnienia na stabilnym poziomie i odciążają dział wsparcia. Ostatecznie, rozwiązanie, które oszczędza zasoby i minimalizuje Czas sprawności wysoki.

Wiele wersji PHP, rollouty i zero przestojów

W codziennym życiu często korzystam z kilku Wersje PHP równolegle. Dzięki FPM jest to osiągane w sposób czysty poprzez oddzielne pule i oddzielne gniazda dla każdej wersji. Pozwala mi to na migrację witryn krok po kroku bez zakłócania działania całego systemu. Planuję aktualizacje kroczące: najpierw staging, potem mała grupa produkcyjna, potem reszta. Graceful Reloads (FPM: przeładowanie zamiast restartu) unikaj twardych rozłączeń i utrzymuj otwarte połączenia. W przypadku LSAPI używam analogicznych mechanizmów w stosie LiteSpeed, aby wstępnie rozgrzać pracowników i zminimalizować efekt zimnego startu.

W przypadku wdrożeń bez przestojów zwracam uwagę na strategie wydań atomowych z dowiązaniami symbolicznymi i Walidacja OPcache. Po przełączeniu selektywnie czyszczę pamięć podręczną bez odrzucania wszystkiego. Dzięki temu opóźnienia ogona są stabilne, a nowe wdrożenia szybko lądują w stanie ciepłym. Ważne: Uprawnienia i właściciele plików muszą być poprawni, w przeciwnym razie pracownicy FPM lub LSAPI zablokują nowe wydania.

Gniazda vs. TCP: decyzje architektoniczne z konsekwencjami

Obsługujący jest podłączony przez Gniazdo Unix lub przez TCP. Gniazda oszczędzają narzut i zwykle zapewniają minimalnie lepsze opóźnienia na hoście. TCP jest opłacalny, jeśli serwer WWW i program obsługujący działają oddzielnie lub jeśli chcę rozdzielić pule na kilka węzłów. Skala chciałbym. W przypadku TCP definiuję timeouty, keep-alive i backlog w sposób czysty, aby podczas szczytów obciążenia nie występowały błędy 502/504. W konfiguracjach Apache zwracam uwagę na liczbę aktywnych pracowników proxy, w Nginx na limity otwartych połączeń. W przypadku LSAPI, LiteSpeed obsługuje wiele rzeczy wewnętrznie, ale nadal regularnie sprawdzam backlog i kolejki pod obciążeniem.

Monitoruję długość kolejki w statusie FPM, wykorzystanie pracowników i nasycenie procesora. Wysoka kolejka przy niskim wykorzystaniu często wskazuje na wąskie gardła we frontendzie (np. zbyt mało pracowników Nginx) lub Hamulce we/wy tam. Dopiero gdy znam wąskie gardło, zwiększam liczbę procesów podrzędnych lub dostosowuję parametry sieci.

Monitorowanie, wskaźniki i wyszukiwanie błędów

Jeśli chodzi o obserwację, polegam na Monitorowanie całościoweDzienniki serwera WWW, status FPM, metryki systemowe (CPU, RAM, I/O), dzienniki aplikacji i kontrole syntetyczne. Szczególnie cenny jest FPMSlowlog, aby wykryć wartości odstające. Koreluję opóźnienia P95/P99 ze skokami CPU, wskaźnikiem trafień OPcache, liczbą uruchomionych procesów i opóźnieniami bazy danych. Jeśli opóźnienie P99 wzrasta, najpierw sprawdzam kolejki i timeouty między proxy a programem obsługi.

W przypadku incydentu pracuję z zewnątrz: 1) kody błędów HTTP i czas, 2) błędy proxy/serwera WWW, 3) kolejki obsługi i stany pracowników, 4) dzienniki aplikacji, 5) systemy zaplecza (DB, pamięć podręczna, system plików). Częstymi przyczynami błędów 502/504 są zbyt rygorystyczne limity czasu, blokowanie strumieni w górę lub wyczerpany Pojemność puli. Proste środki zaradcze: realistyczne limity czasu, wyraźne limity i ostrzeżenia, że przed wyczerpania.

Systemy plików, szczegóły realpath i OPcache

Dostęp do plików ma większy wpływ na opóźnienia, niż wiele osób się spodziewa. Zwracam uwagę na szybkie Ścieżki przechowywania dla kodu i szablonów. W sieciowych systemach plików (np. NFS) parametry realpath i OPcache są krytyczne. Wystarczająco duży realpath_cache_size i odpowiedni ttl zapobiegają trwałemu rozwiązywaniu ścieżek. W OPcache, wymiaruję memory_consumption, interned_strings_buffer i liczbę plików w pamięci podręcznej. Tabele skrótów Ustawiam validate_timestamps i revalidate_freq tak, aby odpowiadały przepływowi pracy wdrażania, dzięki czemu zmiany są wprowadzane szybko, ale nie powodują sprawdzania co sekundę.

W przypadku dużych baz kodu warto Ładowanie wstępne dla centralnych klas i funkcji. Oszczędza to czas procesora pracowników FPM lub LSAPI w gorącej ścieżce. Testuję JIT tylko tam, gdzie występują prawdziwe wąskie gardła procesora (dużo logiki numerycznej). JIT rzadko przynosi korzyści klasycznemu CMS; ważniejsza jest czysta konfiguracja OPcache i szybka ścieżka I/O.

Połączenie z bazą danych i pamięcią podręczną: unikaj opóźnień

Wiele problemów z wydajnością nie wynika z obsługi, ale z Bazy danych i cache. Monitoruję czasy wykonywania zapytań, pule połączeń i blokady. Trwałe połączenia mogą pomóc, ale wiązanie RAM w pracownikach. Dlatego wymiaruję pm.max_children zgodnie z limitami połączeń bazy danych i kontroluję timeouty. W przypadku dostępu do Redis/Memcached kluczowe są również niskie opóźnienia sieciowe i timeouty. Używam śledzenia w aplikacji do rozpoznawania i redukowania zapytań N+1 - zmniejsza to obciążenie obsługi i backendu w tym samym czasie.

Często ma to sens w wysoce konkurencyjnym środowisku, pisanie oddziela procesy (kolejki, zadania asynchroniczne) od dostępu do odczytu z pamięci podręcznej. Dzięki temu żądania front-end są krótkie, a czas odpowiedzi jest mniej zmienny.

Kontener, chroot i aspekty systemu operacyjnego

Każdy, kto używa FPM lub LSAPI w kontenerowanie zyskuje elastyczność dzięki wersjom i limitom. Prawidłowe limity, wydajny harmonogram procesów i odpowiednie limity procesora/pamięci są ważne. Zbyt wysokie limity powodują zacinanie się w opóźnieniach P99. W klasycznych konfiguracjach chroot/jail lub izolacja użytkowników za pomocą przestrzeni nazw pomaga ściśle oddzielić dostęp do plików. Utrzymuję szczupłe obrazy, aby skrócić czas zimnego startu (np. po wdrożeniu) i wstępnie podgrzać pule przed przełączeniem ruchu.

Rotacja logów i Ciśnienie wsteczne-Strategie są obowiązkowe: pełne dyski lub blokujące zapisy dzienników mają bezpośredni wpływ na czasy odpowiedzi. Kalibruję również strategie swappiness, HugePages (w stosownych przypadkach) i NUMA na hostach z wieloma rdzeniami, aby pracownicy nie byli spowalniani przez dostęp do pamięci między węzłami.

Działające jednostki LSAPI i FPM

LSAPI korzysta ze stabilnych, długotrwałych procesów i wydajnego wysyłania żądań. Reguluję maksymalną liczbę żądań na pracownika, aby ograniczyć efekty wycieku pamięci i monitorować restarty podczas pracy na żywo. Z FPM wybieram na żądanie dla witryn o nieregularnym ruchu, dynamiczny Definiuję pm.max_requests tak, aby sporadyczne wycieki lub fragmentacja nie odgrywały roli. Ustawiam request_slowlog_timeout wystarczająco blisko, aby wcześnie rozpoznać prawdziwe zawieszenie, ale nie tak blisko, aby złożone operacje administracyjne stale wywoływały alarm.

Dla obu światów weryfikuję Ścieżki sygnalizacyjne dla przeładowań i definiowania ścieżek eskalacji, jeśli pracownicy nie uruchomią się ponownie w sposób czysty. Dzięki temu wdrożenie w środku dnia nie spowoduje zakłóceń w działaniu platformy.

Lista kontrolna: Wybór i dostrajanie w praktyce

• Zdefiniuj cel: maksimum Kompatybilność (FPM) vs. minimalne opóźnienie ogona (LSAPI) vs. bardzo trudna separacja (CGI).
• Wyjaśnienie roli serwera: Konfiguracja jednego hosta (gniazdo Unix) lub oddzielne poziomy (TCP) - Odpowiednio ustaw timeout/backlog.
• Pule na konto / witrynę: własny UID / GID, ścisłe limity pamięci, żądań i czasu; aktywuj slowlog.
• OPcache: wystarczający rozmiar, wysoki współczynnik trafień, strategia rewalidacji odpowiednia do wdrożenia; w razie potrzeby wstępne ładowanie.
• Pamięć masowa: szybka ścieżka dla kodu / pamięci podręcznej, wymiarowa pamięć podręczna realpath, obserwuj specjalne funkcje NFS.
• DB/Cache: Połączenia i timeouty zgodne z pm.max_children; wyeliminowanie zapytań N+1.
• Warstwa buforowania: połączenie odwrotnego proxy, pamięci podręcznej strony i pamięci podręcznej aplikacji; unieważnianie zamiast opróżniania na ślepo.
• Obserwowalność: P95/P99, długość kolejki, stany pracowników, wskaźnik trafień OPcache, opóźnienia I/O i backendu w skrócie.
• Wdrożenia: Wdzięczny przeładowania, rozgrzewanie, wdrożenia atomowe, selektywne unieważnianie pamięci podręcznej.
• Planowanie przepustowości: rezerwy na wypadek awarii, brak overbookingu; realistyczna ocena kosztów/korzyści licencji LSAPI.

Krótko podsumowując: moja klasyfikacja

Dla mieszanych środowisk hostingowych PHP-FPM najlepszą równowagę między wydajnością, izolacją i kompatybilnością. Na stosach LiteSpeed, LSAPI przynosi wymierne korzyści pod względem opóźnień i zużycia pamięci RAM. CGI nadaje się do ścisłej separacji w niszowych przypadkach, ale pozostaje w tyle w dynamicznych projektach. Początkowo polegam na FPM z wyraźnymi limitami puli, aktywowanym OPcache i czystą konfiguracją serwera WWW. Jeśli spodziewasz się dużej konkurencji, przetestuj LSAPI na LiteSpeed i wtedy podejmij decyzję. Koszty i korzyści-decyzja.