Jarosław Szmańda 42 Zgłoś post Napisano Listopad 3, 2008 Cześć, Czy ktoś już testował ten wynalazek? http://www.cherokee-project.com/ Ogólnie VPSik śmiga mi dobrze, ale nosi mnie żeby jeszcze bardziej poprawić mu wydajność i tak szukam co by tu można było... Pzdr! Udostępnij ten post Link to postu Udostępnij na innych stronach
Gość normanos Zgłoś post Napisano Listopad 3, 2008 nginx Udostępnij ten post Link to postu Udostępnij na innych stronach
megi 358 Zgłoś post Napisano Listopad 3, 2008 nginx + ten menadżer procesów FastCGI do PHP http://php-fpm.anight.org/ To jest patch na PHP, który dodaje wbudowanego menadżera i nie potrzeba już zewnętrznych typu spawn-fcgi z lighttpd. Mocno polecany na liście Nginksa. Większość strony co prawda po rosyjsku, ale dokumentacja po angielsku. Udostępnij ten post Link to postu Udostępnij na innych stronach
Jarosław Szmańda 42 Zgłoś post Napisano Listopad 3, 2008 Czyli zamieniając Apache2 i php5 na Nginx + fastcgi dostane widoczny przyrost wydajności? Udostępnij ten post Link to postu Udostępnij na innych stronach
megi 358 Zgłoś post Napisano Listopad 3, 2008 Czyli zamieniając Apache2 i php5 na Nginx + fastcgi dostane widoczny przyrost wydajności? Możesz zauważyć mniejsze zużycie pamięci - u nas Nginx zajmuje jakieś 7 MB i to wynika z własnych rozszerzeń, vanilla Nginx zajmuje jeszcze mniej. Czy masz taki ruch żeby zobaczyć wzrost wydajności po zastąpieniu Apache to wątpię Jak chcesz się tylko pobawić to postaw i sam się przekonaj Udostępnij ten post Link to postu Udostępnij na innych stronach
Gość normanos Zgłoś post Napisano Listopad 4, 2008 Nginx and Memcached, a 400% boost! http://www.igvita.com/2008/02/11/nginx-and...ed-a-400-boost/ Udostępnij ten post Link to postu Udostępnij na innych stronach
exa 0 Zgłoś post Napisano Listopad 4, 2008 Nginx and Memcached, a 400% boost!http://www.igvita.com/2008/02/11/nginx-and...ed-a-400-boost/ Tylko, że nginx wyłącznie odczytuje z memcached. Dane wynikowa musi zapisać aplikacja, więc byle jakiego skryptu w ten sposób nie uruchomimy. Osobiście uważam, że pomysł na serwowanie treści z cache z pominięciem aplikacji webowej jest genialny i uwzględniam to już projektując strony, które mają obsługiwać potencjalnie większy ruch. Do do wzrostu wydajności osobiście polecam instalację apache z mod_php jako backend przez reverse proxy do nginxa zamiast php po fast_cgi. Chociaż zaintrygował mnie ten projetk: http://php-fpm.anight.org/ . Dopisałem sobie to na listę todo do przetestowania w przyszłości. Udostępnij ten post Link to postu Udostępnij na innych stronach
megi 358 Zgłoś post Napisano Listopad 4, 2008 Do do wzrostu wydajności osobiście polecam instalację apache z mod_php jako backend przez reverse proxy do nginxa zamiast php po fast_cgi. To jeszcze zależy za czym to PHP po FastCGI stoi Jeżeli potrzebujesz Apache np. do .htaccessów to taka konfiguracja jak napisałeś jest najbardziej wydajna. Nie jest jednak bardziej wydajna niż Nginx z PHP po FastCGI. Udostępnij ten post Link to postu Udostępnij na innych stronach
exa 0 Zgłoś post Napisano Listopad 4, 2008 Może coś przeoczyłem, ale od kiedy FastCGI jest szybsze od mod_php? Nawet jeżeli uruchomimy fastcgi przez nginxa. Sam narzut czasowy na reverse proxy jest porównywalny z przekazaniem statycznego pliku + otworzeniu socketa do serwera. Mógłbym uwierzyć że osiągają porównywalną wydajność. Z resztą ważne jest też zużycie pamięci, zwłaszcza na VPSach. Dzisiaj nie mam czasu na przeszukiwanie google (a "na szybko" nic konkretnego nie znalazłem), jutro poszukam z ciekawości nowych testów porównawczych. [edit] http://buytaert.net/album/drupal/drupal-4....tcgi-vs-mod_php , tylko że to jakiś stary test i procesy fast_cgi odpalane są z apache. Udostępnij ten post Link to postu Udostępnij na innych stronach
megi 358 Zgłoś post Napisano Listopad 4, 2008 Może coś przeoczyłem, ale od kiedy FastCGI jest szybsze od mod_php? Nawet jeżeli uruchomimy fastcgi przez nginxa. Mam wrażenie, że wiesz, że Apache + mod_php jest szybsze niż Apache + PHP jako FastCGI, ale nie wiesz dlaczego i uogólniasz oraz wyciągasz zbyt daleko idące wnioski. Osadzenie PHP w Apache zmniejsza narzut na komunikację miedzyprocesową - serwer WWW nie musi łączyć się z zewnętrznym procesem. Dlaczego PHP opakowane Apachem miałoby być szybsze niż PHP opakowane FastCGI? Mowa oczywiście o konfiguracji z Nginksem z przodu. W przypadku PHP jako FastCGI za Nginksem nie ma całej "apaczowej" maszynerii do kompresji, parsowania .htaccessów, komunikacji między workerami Apache'a i tak dalej. Jest tylko i wyłącznie interpreter PHP. Sam narzut czasowy na reverse proxy jest porównywalny z przekazaniem statycznego pliku + otworzeniu socketa do serwera. Ke? Kto komu przekazuje plik i jaki socket jest otwierany? Z resztą ważne jest też zużycie pamięci, zwłaszcza na VPSach. Nginx + PHP jako FastCGI zużywa mniej pamięci niż Nginx + Apache z mod_php [edit]http://buytaert.net/album/drupal/drupal-4....tcgi-vs-mod_php , tylko że to jakiś stary test i procesy fast_cgi odpalane są z apache. No właśnie, z Apache O tym już pisałam wyżej. Udostępnij ten post Link to postu Udostępnij na innych stronach
exa 0 Zgłoś post Napisano Listopad 4, 2008 Dlaczego PHP opakowane Apachem miałoby być szybsze niż PHP opakowane FastCGI? Mam wrażenie, że wiesz, że opakowane FastCGI jest... Mowa oczywiście o konfiguracji z Nginksem z przodu. Dobrze wiem na jakiej zasadzie działa mod_php w apache, także dobrze wiem, że fast_cgi na apache jest mnie wydajne od mod_php. Nie wiedziałem, że fast_cgi na nginxie jest znacząco szybsze i o to pytałem. Przy czym zacytowane wyżej wypowiedzi nie jest odpowiedzią na moje pytanie. Ke? Kto komu przekazuje plik i jaki socket jest otwierany? W przypadku reverse proxy nginx otwiera połączenie (socket) do apache po czym odbiera i przekazuje wygenerowaną stronę jako zwykłą statyczną treść. Nginx + PHP jako FastCGI zużywa mniej pamięci niż Nginx + Apache z mod_php Jeżeli procesy fastcgi są niezależne od siebie oznacza to, że mając uruchomionych 15 procesów fastcgi każdy z nich ma niezależnie od innych załadowany interpreter PHP. Czy może znowu coś przeoczyłem? W przypadku mod_php interpreter ładowany jest do pamięci tylko raz. Możesz mi wyjaśnić w jaki sposób PHP jako fastcgi zużywa mniej pamięci RAM jeżeli w danym momencie mamy 15 albo 50 równoległych połączeń? No właśnie, z Apache O tym już pisałam wyżej. Wiem, dlatego specjalnie zaznaczyłem, że wykres dotyczy apache Udostępnij ten post Link to postu Udostępnij na innych stronach
megi 358 Zgłoś post Napisano Listopad 4, 2008 Nie wiedziałem, że fast_cgi na nginxie jest znacząco szybsze i o to pytałem. Ok, zinterpretowałam to bardziej jako zaczepkę niż pytanie Przy czym zacytowane wyżej wypowiedzi nie jest odpowiedzią na moje pytanie. To zacytuj wypowiedzi, które są odpowiedzią na Twoje pytanie Np. tę: W przypadku PHP jako FastCGI za Nginksem nie ma całej "apaczowej" maszynerii* do kompresji, parsowania .htaccessów, komunikacji między workerami Apache'a i tak dalej. Jest tylko i wyłącznie interpreter PHP. *Maszynerii, która jest w proponowanej przez Ciebie konfiguracji. W przypadku reverse proxy nginx otwiera połączenie (socket) do apache po czym odbiera i przekazuje wygenerowaną stronę jako zwykłą statyczną treść. W przypadku FastCGI robi to samo - inny jest tylko mechanizm komunikacji. Można byłoby prowadzić akademicką dyskusję czy Nginx jako reverse proxy jest szybszy niż Nginx z mod_fastcgi, czy narzut związany z protokołem HTTP jest większy czy mniejszy niż narzut FastCGI, ale już sama obecność Apache po drugiej stronie zamiast czystego interpretera PHP skreśla IMHO to rozwiązanie jako bardziej wydajne. Przy czym, jak to wcześniej ustaliliśmy, jest to najbardziej wydajne jeżeli jednak potrzebujesz tego Apache Jeżeli procesy fastcgi są niezależne od siebie oznacza to, że mając uruchomionych 15 procesów fastcgi każdy z nich ma niezależnie od innych załadowany interpreter PHP. Czy może znowu coś przeoczyłem? W przypadku mod_php interpreter ładowany jest do pamięci tylko raz. Możesz mi wyjaśnić w jaki sposób PHP jako fastcgi zużywa mniej pamięci RAM jeżeli w danym momencie mamy 15 albo 50 równoległych połączeń? Jeżeli jest jeden parent php-fcgi i ma ileś tam dzieciaków to interpreter jest w pamięci dokładnie raz Te procesy współdzielą ze sobą większość pamięci. Sytuacja jest więc taka sama jak z mod_php. Zajęta pamięć związana z obsługą requestów też będzie taka sama, bo to jest zewnętrzny kod w PHP. Jedyne czym te rozwiązania pod względem zajętej pamięci się różnią to pamięcią potrzebna na SAPI FastCGI i na samego Apache. SAPI to groszowe sprawy, pamięć zajęta przez Apache już niekoniecznie. I znów: Twoje rozwiązanie jest najbardziej wydajne jeżeli jednak potrzebujesz tego Apache. Udostępnij ten post Link to postu Udostępnij na innych stronach
exa 0 Zgłoś post Napisano Listopad 4, 2008 Dzięki Megi za odpowiedź. Ani przez moment nie chciałem prowokować zaczepki . O fastcgi miałem błędne pojęcie. Pprzyznam, że nie wgłębiałem się szczegółową analizę tego rozwiązania wiedząc o jego słabszych wynikach na apache. Umówmy się jeszcze, że jak któreś z nas znajdzie w sieci benchmarki to dołączy do tego tematu. Jeżeli wzrost wydajności będzie znaczny to chętnie przerzucę się dla własnych potrzeb na wyłącznie nginxa z fastcgi (bo dla osób trzecich tak czy inaczej muszę instalować apache w taki sposób, żeby nginx był dla nich niewidoczny). Ucząc się i poznając Nginxa w pewnym momencie uderzyła mnie elastyczność, logiczność i ogólna genialność w jaki sposób twórcy zaprojektowali konfigurację. Przed nginxem poznawałem lighttpd i bylem mocno zirytowany ubóstwem możliwości rewrite oraz tylko pozorną prostotą pliku konfiguracyjnego. Nginx ma sposób konfiguracji jak dla mnie przyjemniejszy od apache, świetnie powiązany z możliwościami jakie daje rewrite i chyba jest to serwer HTTP przyszłości, przynajmniej w kręgach wolnego oprogramowania. Generalnie możliwość porzucenia apache na rzecz samego nginxa bardzo mnie cieszy. [edycja] Dla php-fpm wspomnianego wcześniej: http://www.yawn.it/2008/04/30/nginx-php-ph...debian-etch-40/ Benchmark on a 256mb xen vps: apache2+mod_php+xcache = 42 req/sec nginx+xcache+php-fpm = 150 req/sec Aż nie chce się wierzyć . Szkoda, że nie podał metodologii testu. Udostępnij ten post Link to postu Udostępnij na innych stronach
Jarosław Szmańda 42 Zgłoś post Napisano Listopad 4, 2008 Czyli co mam wywalić apache i zastąpić go nigsem? Udostępnij ten post Link to postu Udostępnij na innych stronach
exa 0 Zgłoś post Napisano Listopad 4, 2008 Czyli co mam wywalić apache i zastąpić go nigsem? Jeżeli Twój VPS daje radę, to po co? Jeżeli chcesz się pobrawić/nauczyć obsługi nginxa możesz go postawić równolegle do apache, tylko że zbindowanego na innym porcie. Udostępnij ten post Link to postu Udostępnij na innych stronach
malu 460 Zgłoś post Napisano Listopad 4, 2008 Według mnie te wszystkie benchmarki i tym podobne udziwnienia są nie potrzebne. Bo nie zauważa się istotnych rzeczy. Apache wyróżnia się na mpm-prefork i mpm-worker. Jak pewnie wam wiadomo, jeden jest wydajniejszy (mpm-worker). Nie obsługuje on jednak wszystkich modułów, np. mod_php. A więc po co porównywać mało wydajnego mpm-prefork + mod_php z nginxem na fcgi. Niech ktoś porówna sobie mpm-worker + php (mod_fastcgi, mod_fcgi) z przykładowym nginxem. W ogóle, wydaje mi się że powinno się używać to co komu odpowiada. A sam apache po odpowiedniej konfiguracji, wyłączeniu dużej ilości modułów. Według mnie powinien spisywać się podobnie jak te inne "super wynalazki". Udostępnij ten post Link to postu Udostępnij na innych stronach
megi 358 Zgłoś post Napisano Listopad 5, 2008 W ogóle, wydaje mi się że powinno się używać to co komu odpowiada. No jasne, że tak. Potrzebujesz dużej funkcjonalności to używasz Apache, potrzebujesz szybkiego, lekkiego serwera używasz Nginksa. A sam apache po odpowiedniej konfiguracji, wyłączeniu dużej ilości modułów. Według mnie powinien spisywać się podobnie jak te inne "super wynalazki". Zależy przy jakim ruchu. Jak wyłączysz wszystko co czyni Apache'a Apachem (np. obsługę .htaccessów) to może będzie tak samo szybki jak Nginx. Gdyby Nginx miał taką rozbudowaną funkcjonalność też nie byłby taki szybki. Jest jednak pewna zasadnicza różnica między tymi serwerami - Apache to model współbieżny a Nginx asynchroniczny. W przypadku Apache każdy request to jeden wątek/proces, w przypadku Nginksa jeden proces jest w stanie obsłużyć ileś tam tysięcy jednoczesnych połączeń, a każde połączenie to tylko nowy otwarty deskryptor. Apache skonfigurowany do obsługi takiego ruchu jaki potrafi wziąć na klate Nginx mógłby się stać forkbombą, Nginx przy dużym ruchu najwyżej urośnie o parę MB. Udostępnij ten post Link to postu Udostępnij na innych stronach
Gość normanos Zgłoś post Napisano Listopad 5, 2008 Tylko, że nginx wyłącznie odczytuje z memcached. Dane wynikowa musi zapisać aplikacja, więc byle jakiego skryptu w ten sposób nie uruchomimy. Nie zajmuje się "byle jakimi skryptami" więc ten argument zupełnie mnie nie dotyczy W końcu nie jest to rozwiązanie dla mas i ten kto się tym interesuje już pewnie dobrze wie po co i dlaczego Udostępnij ten post Link to postu Udostępnij na innych stronach
kafi 2425 Zgłoś post Napisano Listopad 5, 2008 Ewentualnie jeśli .htaccessy itp. są potrzebne, to jeszcze pozostaje litespeed. Całkiem przyjaźnie się toto konfiguruje, wydajnościowo porównywalne do lighta i nginxa... ale głównym plusem jest kompatybilność z apaczowymi pseudostandardami. Tylko ta licencja... Udostępnij ten post Link to postu Udostępnij na innych stronach
kafi 2425 Zgłoś post Napisano Listopad 10, 2008 jeżeli patrick nie masz nic mądrego do powiedzenia to nie mów nic. Raczej to ty nie piszesz nic mądrego... Mówiąc o licencji nie mówiłem o jej cenie, tylko o dosyć rygorystycznej (w warunkach hostingowych) EULA. Udostępnij ten post Link to postu Udostępnij na innych stronach
