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, enl...@enleth.com WWW http://enleth.com http://heroes.net.pl JID enl...@jabster.pl
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl