Bajki o FastCGI w PHP
Ostatnio docierały do mnie głosy o FastCGI w PHP. Jednak ja w bajki nie wierzę. To co znalazłem w PHP tylko przypomina FastCGI.
Otóż, jak sama nazwa wskazuje FastCGI powinno być szybsze od CGI. Tymczasem, FastCGI dla PHP nie ma wpływu na szybkość działania a na zużycie pamięci. Czyli może działać szybciej, ale nie musi zależy od sposobu mierzenia. Tutaj jest porównanie szybkości mod_php i php-fpm.
Brodaci i brzuchaci programiści, tacy jak ja, którzy pamiętają jeszcze czasy Perla, wyobrażają sobie że FastCGI działa w następujący sposób. Serwer WWW uruchamia proces aplikacji, aplikacja startuje (co zwykle trochę trwa) i czeka na kolejne żądania. Aplikacja staje się jedną częścią z serwerem. W porównaniu z CGI lub standardowym sposobem uruchamiania PHP pozwala to zaoszczędzić czas potrzebny na start aplikacji. Wymaga to jednak specjalnego sposobu programowania i sumienności w zarządzaniu zasobami. Tymczasem sumienność w zarządzaniu zasobami nie była potrzebna w świecie PHP. W świecie PHP serwer WWW uruchamia aplikację, aplikacja drukuję stronę, kończy pracę i serwer po niej sprząta. Programista programuje szybciej, bo nie traci czasu na programowanie zarządzania pamięcią. Jednak aplikacja działa wolniej, bo nie może korzystać z dobrodziejstw FastCGI. Coś za coś. Programiści piszą szybko lub aplikacja działa szybko. Wybór należy do biznesu. W PHP nie ma FastCGI takiego, jak znają programiści Perla. W PHP nie ma FastCGI które było by szybsze i pozwalało zaoszczędzić czas potrzebny na inicjalizację aplikacji.
PHP działa tak:
Tak działa prawdziwe, szybkie i brodate FastCGI:
Nie wiem jak działa FastCGI w PHP ale na pewno nie tak gdyż nie ma do tego API i biblioteki w PHP nie są przystosowane do takiej pracy. Jeżeli FastCGI w PHP będzie działać tak jak w Perlu, to chcę o tym wiedzieć.
Dlaczego PHP nie działa tak jak powinno? Bo nie jest w stanie. Na początku wydawało się, że mod_php to super rozwiązanie, szybko odkryto pewien problem – PHP ma tragiczne zarządzanie pamięcią, procesy puchły niesamowicie. Były dwa rozwiązania – ograniczyć w Apache ilość żądań, który przetworzy jeden worker przed jego ubiciem albo zmusić PHP do współpracy z CGI i chyba większość wybrała ten drugi sposób. Teoretycznie powinno to chodzić gorzej – bo jest narzut związany z każdorazowym uruchamianiem, ale nie ma już szansy, że błędy w PHP unieruchomią cały serwer i to chyba przeważyło.
PHP 5.3 ma usprawniony GC, podobno w końcu potrafi sobie radzić z cyklicznymi referencjami, ale pewnie na cud nie ma co liczyć. Ten język nigdy nie był zaprojektowany do takiego działania jak opisujesz w swoim wpisie i pewnie bez przepisania od zera silnika a przede wszystkim rozszerzeń nigdy nie będzie w stanie tak działać.
O php_fpm jeszcze nie słyszałem, ale wygląda raczej na narzędzie które ma zapewnić taką funkcjonalność jak komercyjne wydanie Zend Server, czyli lepszy monitoring i zarządzanie niż polepszyć w jakiś sposób współpracę PHP i CGI.
…ha ha – to proponuje przejsc na mod_lua to dopiero zobaczycie ulge w pamieci, notabene bedzie “out-of-the-box” w apache 2.4
“FastCGI powinno być szybsze od CGI” – FastCGI jest szybsze od zwykłego CGI ponieważ odpada czas potrzebny do stworzenia procesu. To że działa porównywalnie do mod_php (lub wolniej) – zgoda. W obu przypadkach pomijany jest etap fork() + exec().