Wydajność FastCGI względem mod-php

[Jarosław Szmańda 42]

Cześć,

 

Czy ktoś mógł by mi naświetlić temat na dzień dzisiejszy?

 

Pomijając kwestię bezpieczeństwa (tylko jeden użytkownik serwera), skrypty raczej bezpieczne - nie wrzucane 'śmieci' jak jest z wydajnością? Wiadomo, że FastCGI alokuje 'na stałe' część pamięci - jaki jest jest - o ile jest przerost wydajność podczas wykonywania skryptów?

 

Będę wdzięczny za opinie użytkowników obu rozwiązać.

 

 

Pzdr!

[www.ionic.pl 535]

względem czego ?

[kafi 2425]

Jemu chodzi chyba o php-fcgi i apache2-mod_php.

 

Swoją drogą - też ciekawy jestem owego porównania, zwłaszcza z workerem itk.

[Jarosław Szmańda 42]

@Fiercio - dokładnie tak.

[^^KaMaZZ~.^ 154]

Dla mnie fakt, że żaden sensowny cacher nie zachowuje się dobrze z FastCGI (przynajmniej tak było, kiedy ja kombinowałem z optymalizacją Apache2) przechyla całą szalę zwycięstwa na korzyść mod_php.

Całe szczęście, że istnieje jeszcze LSAPI w LiteSpeedzie który radzi sobie z cacherami

[tym 205]

Wszystko zależy od contentu...

[Krystian 17]

Wszystko zależy od contentu...

 

A skąd! Wszystko zależy od zastosowanej obudowy w serwerze

[www.ionic.pl 535]

Dla mnie fakt, że żaden sensowny cacher nie zachowuje się dobrze z FastCGI (przynajmniej tak było, kiedy ja kombinowałem z optymalizacją Apache2) przechyla całą szalę zwycięstwa na korzyść mod_php.

Całe szczęście, że istnieje jeszcze LSAPI w LiteSpeedzie który radzi sobie z cacherami

 

Mylisz się - odpowiednio cacher, odpowiednio skonfigurowany i jazda - a nie apt-get install memcached

 

mod_fastcgi (fcgig bardzo rzadko używam, prawie wcale) ma o wiele więcej opcji konfiguracyjnych niż mod_php i co ważne per user, per domena / subdomena można upchać php.ini, starter itd (można to także uzyskać za pomcą np. suphp, aczkolwiek dostaniemy turbo po wydajności) , bardzo dużego skoku wydajności nie będzie natomiast zauważymy na zużyciu pamięci (dla rozsądnego klienta mod_php jest totally OK B) ), ważne by konfiguracja fastcgi i odpalacza była odpowiednia, możemy z fastcgi zrobić "muła" jeśli go odpowiednio spapramy.

Worker to moim zdaniem mały połykacz RAMu - niestety w niektórych przypadkach stosujemy go bardzo często (spora ilość połączeń i gracefull).

 

JarekMK musisz zwrócić uwagę na to, ze niektórzy programiści są zatrzaśnięci i trzeba im potłumaczyć dlaczego pewne opcje są inaczej obsługiwane

@Krystian, @tym ma rację - może nie tylko kontentu co zastosowania serwera, jak widzę hostingi na mod_php5 to mi kapcie spadają, a są takie

 

 

Tu jest z cacherami ale zawsze coś widać;

http://www.brandontu...che_benchmarks/

[kafi 2425]

jak widzę hostingi na mod_php5 to mi kapcie spadają, a są takie

Mogę tak z ciekawości wiedzieć czemu?

[Gość patrys]

Mogę tak z ciekawości wiedzieć czemu?

Pewnie z racji wykonywania php z prawami serwera apache.

[www.ionic.pl 535]

Mogę tak z ciekawości wiedzieć czemu?

 

Jeśli system nie jest odpowiednio "zrobiony" to patrz podstawowa różnica pomiędzy fastcgi a mod_php5

Ale oczywiście pisałem o hostingach nie tych które się reklamują w tv itd. a o tych które mają DA + PHP5 CLI

[kafi 2425]

Pewnie z racji wykonywania php z prawami serwera apache.

Można przecież tak skonfigurować serwer Apache, żeby wykonywał je z określonym przez nas UID...

Do tego na frontendzie jakieś proxy, żeby odciąć ZU od bezpośredniego Apache i to chyba nawet w miarę bezpieczne jest

[www.ionic.pl 535]

Można przecież tak skonfigurować serwer Apache, żeby wykonywał je z określonym przez nas UID...

Do tego na frontendzie jakieś proxy, żeby odciąć ZU od bezpośredniego Apache i to chyba nawet w miarę bezpieczne jest

 

itk + suexec ?

a no squid

patrz bodajże nazwa.pl ?

[Gość patrys]

Można przecież tak skonfigurować serwer Apache, żeby wykonywał je z określonym przez nas UID...

w wspomnianej konfiguracji apache prefork + php cli ?

[kafi 2425]

itk nie wymaga suexecka... bo tak właściwie to on sam przełącza UID dla jakiegokolwiek requestu w ramach vhosta.

Problem tylko taki, że wymaga to pracy procesu głównego z uid=0, więc stąd pomysł na proxy (czy to nginx, czy to squid), żeby maksymalnie utrudnić jakieś sztuczki przepełniania buforów itp.

 

w wspomnianej konfiguracji apache prefork + php cli ?

Najdmen mówił, że ogólnie nie lubi mod_php na serwerach hostingowych

A przy umiejętnej konfiguracji ma to szansę nawet jako-tako działać.

[www.ionic.pl 535]

itk nie wymaga suexecka... bo tak właściwie to on sam przełącza UID dla jakiegokolwiek requestu w ramach vhosta.

Problem tylko taki, że wymaga to pracy procesu głównego z uid=0, więc stąd pomysł na proxy (czy to nginx, czy to squid), żeby maksymalnie utrudnić jakieś sztuczki przepełniania buforów itp.

 

 

Najdmen mówił, że ogólnie nie lubi mod_php na serwerach hostingowych

A przy umiejętnej konfiguracji ma to szansę nawet jako-tako działać.

Wszystko się da jak się chce i pomyśli.

Nadal nie rozumiem koncepcji mod_php na hostingu shared bez odpowiedniego tuningu systemu.

[Gość patrys]

Najdmen mówił, że ogólnie nie lubi mod_php na serwerach hostingowych

tak ale czytając to odebrałem jako np. Directadmin ./setup.sh

A przy umiejętnej konfiguracji ma to szansę nawet jako-tako działać.

FastCGI to sprawniejsza kontrola nad procesami i użytkownikami.

 

Wracając do tematu, lepszym rozwiązaniem będzie Lighty + spawn-fcgi i xcache.

Od fastcgi do apache, mod_php będzie szybszy ( nie wiem jak z wspomnianym itk).