By: Dariusz Cieślak

Dariusz Cieślak — Wed, 09 Jun 2010 20:42:49 +0000

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

By: noname

noname — Wed, 09 Jun 2010 12:19:55 +0000

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

By: lstosik

lstosik — Thu, 11 Feb 2010 14:50:53 +0000

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.

Comments on: Bajki o FastCGI w PHP

By: Dariusz Cieślak

By: noname

By: lstosik