Mod_php Czy Fastcgi

[megi 358]

Cześć!

 

W jaki sposób najczęściej u różnych providerów uruchamiane jest PHP? Czy można przyjąć, że standardem jest fastcgi czy raczej mod_php, czy też nie da się wyróżnić dominującego sposobu? Potrzebuję tej informacji do artykułu o hostingu ruby i pythona a niestety wiem tylko jak jest w nazwie i kei.

[Hekko.pl 239]

U nas od niedawna fcgi. I raczej już na stałe. Jest to raczej bardziej użyteczna opcja i więcej możliwości daje.

[ednet 136]

Cześć!

 

W jaki sposób najczęściej u różnych providerów uruchamiane jest PHP? Czy można przyjąć, że standardem jest fastcgi czy raczej mod_php, czy też nie da się wyróżnić dominującego sposobu? Potrzebuję tej informacji do artykułu o hostingu ruby i pythona a niestety wiem tylko jak jest w nazwie i kei.

 

fastcgi pomału chyba staje się standardem (mówię o większych firmach)

 

Ed

[Prohost 345]

Jeśli chodzi o php to nie zawsze opłaca się tylko fastcgi. Najlepiej włączać tylko najczęściej używającym php. Oszczędzi się ram i liczba odpalonych procesów nie będzie wysoka. Reszcie można odpalać w cgi.

[Gość adamszendzielorz]

Jeśli chodzi o php to nie zawsze opłaca się tylko fastcgi. Najlepiej włączać tylko najczęściej używającym php. Oszczędzi się ram i liczba odpalonych procesów nie będzie wysoka. Reszcie można odpalać w cgi.

 

A dodatkowo w Fast/CGI nie ma wiekszego problemu zeby uruchamiac kilka roznych wersji PHP bez kombinacji, ze np. PHP4 w trybie mod_php, a PHP5 w trybie Fast/CGI, co jest moim zdaniem kompletnie bez sensu:)

pozdr.

[pleple 0]

To jak już tak ludzie wymieniają zalety (Fast)CGI to i ja dołożę swoje trzy grosze. Używanie (Fast)CGI jest w tej chwili jedynym sposobem na posiadanie bezpiecznego serwera WWW. Używanie mod_php jest po prostu tragedią z punktu widzenia bezpieczeństwa. Moduł działa w kontekście serwera WWW, ma dostęp do wszystkich jego struktur danych w tym do tablicy procesów dzieci. Błąd w PHP (już ładnych parę takich było) można wykorzystać do zrobienia DOS-a serwera WWW a nawet całego serwera (proces odpowiadający za spawnowanie procesów pomocniczych działa na prawach roota więc może zabić wszystkie procesy w systemie).

[beliq 442]

Używanie (Fast)CGI jest w tej chwili jedynym sposobem na posiadanie bezpiecznego serwera WWW.

Jest to też jedyna metoda na stworzenie środowiska dającego wprost wyłonić

"czarną owcę" wśród klientów w czasie niemal rzeczywistym.

Pisanie jakichkolwiek parserów analizujących wyniki mod_status Apache

jest nonsensem - nie da się w ten sposób zebrać dokładnych danych.

[thinkbot 0]

kwestia wydajnosciowa

 

mod_php ładuje interpreter php do kazdego rodzaju plikow, żądanie jest po obrazek to i tak interpreter jest ładowany (a z nim wszystkie biblioteki do RAMu), bez sensu

 

fastcgi laduje interpreter na starcie do pamieci i siedzi tam caly czas, uzywany jest tylko do php

[pleple 0]

Ech, odsmażyłeś tylko po to żeby napisać takie bzdury? mod_php, jako moduł Apache, ładowane jest do pamięci przy starcie serwera i znajduje się tam aż do czasu jego zatrzymania. Oczywiście jest on używany, identycznie jak w przypadku FastCGI, tylko i wyłącznie do tych plików, które są wybrane w konfiguracji serwera.

[JohnyByk 1]

Witam

 

Odkurzę dosyć stary temat.

 

Jakiś czas używałem suPHP.

Jest mało bezpieczny, ale ma udogodnienie w postaci możliwości uruchomienia custom php.ini (tworzę plik php.ini w katalogu domeny i już mam nowe ustawienia). Udogodnieniem jest to, że nie jest to główny plik konfiguracyjny, a nadpisuje jedynie ustawienia, które w custom,owym pliku się znajdują (additional php.ini).

 

Niestety suPHP nie jest bezpieczny i wydajnością też nie urywa.

 

Zastanawiam się nad mod_php+mod_ruid2, php-fpm oraz fastcgi.

Wszystkie powyższe rozwiązania są bezpieczniejsze od suPHP i też nie są wolniejsze.

 

mod_ruid2 jest o tyle fajny, że bez problemu mogę sobie dopisać customowe ustawienia do konfiguracji Vhosta (używam DirectAdmina).

 

php-fpm wydaje mi się najszybszy (może tu subiektywne odczucie, ale kilka testów własnych potwierdziło tą tezę, do tego miał najmniej Failed Request przy ab)

 

fastcgi też wydaje się OK, ale miałem z nim kilka problemów, których nie udało mi się rozwiązać: http://www.webhostingtalk.pl/topic/42589-blad-mod-fcgid-32broken-pipe/

 

W przypadku php-fpm i fastcgi miałem jeszcze jeden problem z rewrite'ami.

Część gratów leżących na serwerze działa w oparciu od cakePHP. Webroot znajduje się w /app/webroot (dopowiednie reguły .htaccess - jest to standard przy cakePHP). W przypadku suPHP czy mod_php wpisanie adresu strona.pl/phpinfo.php powoduje odpalenie skryptu. W przypadku fastcgi i php-fpm nie działa poprawnie taki link. Dostęp uzyskuję przez strona.pl/app/webroot/phpinfo.php

Może to jakiś problem konfiguracyjny, a może jakaś typowa bolączka. Co ciekawe nie ma to wpływu na ogólne działanie aplikacji.

 

Którą metodę serwowania php'a byście polecili.

Zależy mi na w miarę nietrudnej możliwości manipulowania ustawieniami php'a per user (z poziomu DA) oraz bezawaryjności.

Najchętniej wybrałbym fstcgi, ale generuje to problem, o którym pisałem wyżej.

A może mod_php + mod_ruid2 wcale nie jest złym wyborem? Własne testy wykazały, że wydajność jest OK, ale może ma inne przeciwwskazania o których nie wiem.

 

Proszę o opinie doświadczonych kolegów.

 

Pozdrawiam

[Gość patrys]

Najmniej problemów / wydajność = mod_ruid2

Wyższa wydajność ale możliwe problemy z skryptami = apache 2.4 event + fpm