Czy php.cgi korzysta z php-cgi.ini?

[Remigiusz 'Enleth' Marcinkiewicz]

On Tuesday January 26 2010 22:45:12 Arkadiusz Rdest wrote:
> Remigiusz 'Enleth' Marcinkiewicz pisze:
> > Swój skrypt startowy mogę udostępnić, jakby ktoś był zainteresowany. Nie
> > jestem pewien, czy jest w pełni "the PLD way", ale IMHO jest wygodny i
> > działa dobrze. Już dawno bym go podrzucił do skomentowania na -devel, ale
> > czasu nie mam żeby dopracować i opisać...
> 
> poproszę na priv'a albo linka do sciagniecia.
> z checia popatrze i pomysle nad zmianami u siebie.
> 
> teraz mam okolo 4k kont. php odpalane przez mod_fastcgid w apachu.
> ale jest problem z reloadami konfiguracji. zwykle w pamieci wisi 2-3k
> procesow PHP, no i przy relaodzie apacha (przez graceful np. w celu
> dodania nowych vhostow) load skacze bardzo konkretnie (czasem do
> 400-500, bo musi ubic te 3k procesow i wystartowac od nowa.
> 
> [...]

Od razu mówię, że skrypt testowany był na maksymalnie kilkudziesięciu 
procesach fcgi, więcej mi potrzebne nie jest. Aktualnie działa na - być może 
śmiesznych dla niektorych - czterech.

Dla mnie akurat to, że działają one stale i niezależnie od serwera HTTP 
(którym u mnie jest lighttpd, więc w sprawach związanych z konfiguracją apacha 
nie pomogę; konfigi lighttpd można w pewnym stopniu skryptować substytucją 
zmiennych np. w ścieżkach socketów) jest pożądane i celowe, choćby dlatego, że 
cache akceleratora dla danego vhosta może bardzo długo wisieć w pamięci. 
Różnica w prędkości ładowania stron zaraz po restarcie procesu fcgi, zanim się 
cache wypełni często używanymi plikami, nie jest może wyraźnie widoczna, ale 
jest mierzalna. Za to restarty jakiegokolwiek pojedyńczego procesu, czy to 
fcgi czy lighttpd, są natychmiastowe i nie wpływają na całą resztę, można 
sobie do woli grzebać w konfiguracji i testować dowolny element.

Skrypt gdzieś wrzucę jakoś pod wieczór.

Aha, fcgi w trybie proces na vhost na usera, z oddzielną dla każdego 
konfigurajcą, jest używane na dość sporą skalę przez kilka dużych firm 
hostingowych, w tym bluehost i dreamhost. Co by nie mówić o uptime ich 
serwerów i jakości obsługi technicznej, fcgi im akurat wyszło i działa dobrze. 
Fakt, że na monstrach z 8 CPU i 32GB pamięci, ale organizacyjnie jakoś sobie z 
tym poradzili.
 
> ja do przyspieszenia dzialania serwer mam reverse proxy (squid) z przodu
> serwera wwww. Sprawdza sie. Czy te accelratory dzialaj dobrze z
> srodowisku multiuserowym fastcgi? trzeba je osobno dla kazdego vhosta
> odpalac? czy wystarczy jakis jedna wspolna konfiguracja?

Akceleratory PHP, po załadowaniu modułu w konfiguracji, działają całkowicie 
automatycznie jako element parsera i, w uproszczeniu mówiąc, przechowują 
skrypty w pamięci procesu, w postaci wygenerowanej przez parser i wykonywalnej 
bezpośrednio w maszynie wirtualnej Zend Engine oraz wykonują mniejszą lub 
większą optymalizację kodu i czasami oferują jakieś API do shm (IMHO memcache 
lepszy). W środowisku multiuserowym/multiprocesowym działa to dobrze, jeśli 
przyjąć chyba dość sensowne założenie, że userzy nie korzystają z tych samych 
plików PHP. Wyjątkiem może być jakaś tam systemowa instalacja ZF, ale jakoś mi 
się nie chce wierzyć, że takie globalne kopie frameworków i bibliotek PHP są 
powszechnie i konsekwentnie używane, więc problem wielki raczej nie jest. A 
shm dzielone między userami w ogóle nie powinno mieć miejsca.

Generalnie, można powiedzieć że akceleratory przerzucają część obciążenia z 
I/O dysków i CPU na pamięć, więc jeśli serwer ma dużo wolnej pamięci a zatyka 
się na procesorach podczas wykonywania skryptów, jakiś akcelerator może 
znacząco poprawić sytuację. Jaki? Tego w sumie nie powie żaden benchmark poza 
tym zrobionym we własnym zakresie, bo różny kod może się różnie optymalizować 
konkretnymi algorytmami.

-- 
Remigiusz "Enleth" Marcinkiewicz, enleth w enleth.com
WWW http://enleth.com http://heroes.net.pl
JID enleth w jabster.pl
-------------- następna część ---------
Załącznik, który nie był tekstem został usunięty...
Name: nie znany
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : /mailman/pipermail/pld-users-pl/attachments/20100127/1398aabe/attachment.sig