Home > PHP > Bajki o FastCGI w PHP

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ć.

Tu jest info o FastCGI dla Perla.

Categories: PHP Tags:
  1. February 11th, 2010 at 15:50 | #1

    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.

  2. noname
    June 9th, 2010 at 13:19 | #2

    …ha ha – to proponuje przejsc na mod_lua to dopiero zobaczycie ulge w pamieci, notabene bedzie “out-of-the-box” w apache 2.4

  3. June 9th, 2010 at 21:42 | #3

    “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().

  1. No trackbacks yet.

Subscribe without commenting