Jarosław Zabiełło - BLOG: Lightpd & FastCGI vs. Apache & mod_php,mod_python...

Lightpd & FastCGI vs. Apache & mod_php,mod_python...

Jarosław Zabiełło — Mon, 24 Apr 2006 19:40:00 +0200

Serwer Apache jest bardzo popularnym i solidnym serwerem www. Nie dziwi więc powszechne używanie jego modułow do obsługi Perla, PHP czy Pythona. Uzywanie mod_php jest wręcz nagminne (cały serwis sourceforge.net stoi na mod_php). Podobnie twórcy pythonowego frameworku Django zalecają używanie mod_pythona. W dokumentacji piszą, że:

“jeśli chcesz używać Django na serwerze produkcyjnym, uzywaj Apache’a z mod_pythonem (...) Django wymaga Apache 2.x oraz mod_python 3.x.”

Zupełnie inne podejście zalecają twórcy frameworka Ruby on Rails. Nie dość, że zalecają użycie modułu FastCGI to na dodatek, zalecają (o grozo:) używanie innego serwera www: Ligttpd. Które podejście jest lepsze?

Problem z uniwersalnością

Korzystanie z modułów Apache’a wiąże nas na dobre i złe z tym serwerem. korzystanie z fastcgi daje nam większe pole manewru. Możemy korzystać z Apache, Lighttpd, IIS i innych serwerów www.

Problem stabilności serwera

Jakikolwiek błąd w skryptach pracujących w trybie mod_php czy mod_python odbija się bardzo niebezpiecznie na stabilności całego serwera. Jeden błędnie działający skrypt może zawiesić cały serwer! Dotyczy to nie tylko Apache, ale także windowsowego IIS i modułów ISAPI. Co ciekawe, moduł ISAPI dla języka PHP jest wiecznie w fazie niestabilnej i testowej. Co z tego, że jest szybszy niż klasyczny CGI, skoro jeden drobny błąd w skrypcie PHP potrafi zawiesić cały serwer i unieruchomić cała sieć intranetową na nim opartą? To jeden z powodów dla których PHP nie nadaje się najlepiej do pracy pod Windowsami (wiem, że istnieje Apache/win32 ale z różnych powodów, których tu nie będę rozwijał, korporacyjne sieci intranetowe oparte na Windows Server wolą używać IIS)

Procesy FastCGI są izolowane od serwera. Jak któryś się zawiesi, to serwerowi nic się nie stanie. Proces można ubić, zrestartowac. Daje to znacznie większą stabilność pracy serwera.

Problem bezpieczeństwa

Każdy skrypt odpalany w trybie mod_php na Apache’u jest odpalany w kontekście tego samego uzytkownika. Tworzy to dosyć poważną dziurę bezpieczeństwa na serwerach hostingowych. Każdy użytkownik na serwerze za pomocą prostego kodu PHP może przeglądać źródła dowolnego pliku innych użytkowników. Wszyscy mają dostęp do wszystkich! Napisałem nawet swego czasu prosty skrypt wedrujący po całym sourceforge.net i przeglądający źródła wszystkich dostępnych tam projektów. :) Każdy, średnio zaawansowany programista z łatwością napisze sobie taki kod. Nie ma znaczenia, czy to będzie Perl (mod_perl), Python (mod_python) czy PHP (mod_php).

W FastCGI tego problemu nie ma. Każdy użytkownik może pracować na swoich prawach w pełnej izolacji. Wystarczy każdemu przydzielić po procesie FastCGI na prawach danego użytkownika.

Marnowanie możliwości Apache’a 2.x

To może nie jest najważniejszy problem. Apache 2.x potrafi pracować w trybie wielowątkowym (worker) lub wieloprocesowym (prefork) który jest zgodny ze starym Apache 1.x . Ten pierwszy jest nowocześniejszy, szybszy i pożera mniej pamięci. Problem jednak w tym, że najbardziej popularny język skryptowy nie posiada poprawnie zaimplementowanej wielowątkowości. Jeśli więc chcesz używać PHP, to zapomnij o trybie workera. Musisz pracować w starym trybie prefork. Zajmuje to więcej pamięci, ale za to nie będzie problemów z różnymi bibliotekami PHP.

Problem zasobożerności

Gdy uruchamiamy Apache 1.x lub Apache 2.x w trybie prefork, uruchamiamy szereg podprocesów. Każdy z nich zajmuje określoną ilość pamięci. Każdy z zainstalowanych modułów… również. A to przecież nie ma sensu! W praktyce nie chcemy wykorzystywać wszystkich procesów do przetwarzania mod_pythona. Większość procesów jest zajęta podawaniem statycznej wartości (obrazki, pliki ze stylami kaskadowymi, skryptami JavaScript itp).

FastCGI pozwala na ograniczenie ustalenie ilości swoich procesów w sposób niezależny od wszystkich procesów serwera www. Np. możemy sobie zadecydować, aby 100 procesów zajmowało się wartością statyczną, a tylko 10 wartością dynamiczną. Takie coś jest niemożliwe wypadku korzystania z mod_php czy mod_pythona. A oszczędności na zużyciu pamięci będą kolosalne!

Np. można załozyć, że pojedyńczy proces Apache podczas serwowania statycznych stron zajmie nie więcej niż ok 5 MB pamięci. Natomiast w wypadku użycia mod_ruby może wzrosnąć nawet do ok. 20-30MB na proces. Użycie zatem 100 procesów Apache’a z tylko 10 procesami FastCGI zużyje ok. 800MB pamięci. Zaś użycie mod_ruby bez problemu pożre nawet i 3GB!

Dlaczego Lighttpd a nie Apache?

Na końcu chciałbym jeszcze zastanowić się czy twórcy Railsów nie mają racji i czy w ogóle nie warto zrezygnować z Apache na rzecz Lighttpd? Są generalnie 3 powody za i jeden przeciw.

Za: lepiej dopracowany moduł FastCGI

Moduł FastCGI do Apache’a ma opinię nie do końca stabilnego i dopracowanego. To powoduje obawę większości użytkowników od używania go dla serwera Apache. Z kolei serwer Lighttpd od samego początku kładł nacisk na dobrą implementację swego modułu FastCGI. Jest on stabilniejszy i lepiej dopracowany niż pod Apachem.

Za: Wbudowana możliwość rozkładania obciążenia

Lighttpd ma wbudowany mechanizm rozkładania ruchu na wiele serwerów. Jeśli więc nawet ktoś upiera się przy Apache’u, to w wypadku kiedy jeden serwer nie jest wystarczający do obsługi ruchu, może warto rozważyć aby postawić na froncie jeden serwer Lighttpd który by rozkładał ruch pomiędzy kilka serwerów?

(Najnowszy Apache 2.2 ma posiadać podobny mechanizm. Jednak jest to jeszcze bardzo świeża wersja, która (w momencie pisania tego tekstu) nie ma nawet prekompilowanej instalacji dostępnej dla Windowsów oraz nie wiadomo jak jest ze stabilnością wszystkich modułów.)

Za: Lighttpd jest szybszy

O ile najnowszy Apache 2.2 nie zmieni sytuacji, to wszystko wskazuje na to, ze Lighttpd jest po prostu szybszy. Nie tylko zdecydowanie szybciej podaje statyczne dane ale także szybciej działa PHP pod Lighttpd niż mod_php pod Apachem. To nie są drobne różnice. To są różnice rzędu 2-3 razy!

Przeciw: Apache ma więcej modułów

Właściwie jedynym powodem aby używać Apache zamiast Lighttpd jest to, że do Apache napisano znacznie więcej różnych modułów. Ale szczerze mówiąc, w praktyce to rzadko ma znaczenie. Większość osób uzywa głównie kilku modułów. Zaś Lighttpd posiada praktycznie wszystko, co potrzeba: mod_fastcgi, mod_cgi, mod_redirect, mod_access, mod_auth, mod_compress, mod_webdav, mod_ssl, mod_alias, mod_proxy, mod_rewrite, itp. itd.

Lighttpd + FastCGI. To działa!

Na szczęście, dzięki standardowi WSGI, użytkownicy Pythona nie muszą słuchać zaleceń developerów Django. Teraz praktycznie wszystkie frameworki Pythona pozwalają dzięki WSGI korzystać z dobrodziejstw FastCGI. Ja również na swoim serwerze wyrzuciłem Apache’a i zastapiłem go Lighttpd. Podaje zarówno strony statyczne jak i obsługuje ten blog, a nawet PHP 5.1. Nawet Plone mi udało mi się uruchomić z Lighttpd na przodzie.

"Lightpd & FastCGI vs. Apache & mod_php,mod_python..." by cinkowskiw

Sun, 25 Feb 2007 20:08:13 +0100

Zapowiada się, aby lighttpd kiedykolwiek obsługiwał .htaccess? Jeżeli tak, to kiedy i czy pliki będą podobne do tych z Apache?

"Lightpd & FastCGI vs. Apache & mod_php,mod_python..." by Jarosław Zabiełło

Wed, 22 Nov 2006 23:11:41 +0100

Lepszy jest nginx. Z Lighttpd miałem sporo problemów pod dużym obciążeniem.

"Lightpd & FastCGI vs. Apache & mod_php,mod_python..." by eRiZ

Wed, 22 Nov 2006 22:30:44 +0100

Przesiadłbym sie na LightTPD, ale na razie powstrzymuje mnie przed tym brak czegokolwiek na pozór .htaccess bez restartowania serwera…

"Lightpd & FastCGI vs. Apache & mod_php,mod_python..." by to własnie ja

Mon, 13 Nov 2006 14:16:11 +0100

napisałeś że dzięki fastcgi można uruchomić php z uprawnieniami usera nie serwera www. prawda, jednak fastcgi polega na tym że procesy php pozostają otwarte nawet gdy nie są używane, więc jesli uruchomisz minimalną ilośc 2 childów dla 100 userów otrzymasz użycie pamięci sięgające 2GB nawet jeśli php nie jest używane przez nikogo!

"Lightpd & FastCGI vs. Apache & mod_php,mod_python..." by cml

Fri, 27 Oct 2006 08:18:31 +0200

http://www.php.net/manual/en/faq.installation.php#faq.installation.apache2

tutaj napisali ze “third party modules” moga zle dzialac z mpm-worker

nic nie napisali ze ICH moduly nie obsluguja tego..

"Lightpd & FastCGI vs. Apache & mod_php,mod_python..." by Jarosław Zabiełło

Wed, 06 Sep 2006 18:47:33 +0200

Po pierwsze wątki (threads) to nie to samo co procesy (forks) Apache’a. Po drugie, wszystko masz wytłumaczone na stronach PHP. Np. w manualu do PHP ostrzegają aby nie używać go z Apachem 2 w trybie wielowątkowym: “We do not recommend using a threaded MPM in production with Apache2. Use the prefork MPM instead, or use Apache1.”

A to, że nic ci się nie sypnęło wynikać może z (1) fartu, (2) faktu, że PHP nie posiada mechanizmu globalnego wyłapania wyjątków i zwracania ich mailem do usera, więc wiele błędów po prostu nie da się łatwo zauważyć. (Nawet PHP5 ma większość bibliotek które sypią warningiem czy errorem bez wyzwalania wyjątku, który można by przechwycić i wykorzystać) Stąd tak wiele aplikacji pehapowych pełnych błędów o których nic nie wiedzą ich twórcy.

"Lightpd & FastCGI vs. Apache & mod_php,mod_python..." by Rafi

Thu, 15 Jun 2006 06:26:19 +0200

Zastanawia mnie tylko jedno stwierdzenie z tego tekstu:

“Problem jednak w tym, że najbardziej popularny język skryptowy nie posiada poprawnie zaimplementowanej wielowątkowości. Jeśli więc chcesz używać PHP, to zapomnij o trybie workera.”

Używam trybu workera na wszystkich 9 serwerach jakie posiadam ;) i na żadnym z nich nie wystąpiły żadne problemy z tym trybem i PHP oraz innymi modułami. Używając mod_php każdy skrypt jest indywidualnie kompilowany i wykonywany przez procesy/wątki apache’a, więc nie widzę tutaj za bardzo przyczyn do problemów… Chętnie przeczytałbym jakieś głębsze wyjaśnienie :)

"Lightpd & FastCGI vs. Apache & mod_php,mod_python..." by Jarosław Zabiełło

Wed, 26 Apr 2006 22:41:37 +0200

Te przykładowe wyliczenia wziąłem z ksiązki Agile…. Przed chwilą sprawdziłem (poleceniem top), że na moim Debianie 3.1 każdy proces fastcgi dla Rubiego zajmuje 23MB. (Inna sprawa że pojedyńczy proces dla PHP 5.1.2 zajmuje mi ok 6MB). W każdym razie istota sprawy polega na tym, że Lighttpd nie musi na każdym z forków mieć podpięty interpreter (tu Rubiego) i to znacznie oszczędza pamięć.

Co do podpinania Pythona do FastCGI to najlepiej to zrobić poprzez WSGI. Prawie wszystkie frameworki udostępniają handler do WSGI (używanie Pythona do webu bez żadnego frameworka to raczej mało dobry pomysł, burdel się tylko zrobi tak jak w php). Biblioteka flup pozwala uruchomić Pythona na wiele sposobów (w wypadku fastcgi można sobie nawet wybrać czy serwer będzie forkowy, czy wielowątkowy). Pylons/Myghty, Django czy TurboGears/CherryPy mają gotowe handlery fastcgi.

"Lightpd & FastCGI vs. Apache & mod_php,mod_python..." by Paweł Rutkowski

Wed, 26 Apr 2006 11:55:45 +0200

Z tym że każdy z procesów apache zajmuje 20-30MB to troche przesadziłeś. Fakt że top czy ps pokażą takie wartości, jednak w przypadku modelu prefork nie są one do końca prawdziwe. Nie wiem jak Linux ale we FreeBSD fork działa na zasadzie mechanizmu copy-on-write przezco nie alokuje za każdym razem całej przestrzeni adresowej procesu tylko strony które zostały poddane modyfikacji (a tych w przypadku załadowanych modułów raczej nie bedzie ich dużo).

"Lightpd & FastCGI vs. Apache & mod_php,mod_python..." by FREQUENTER

Wed, 26 Apr 2006 06:22:25 +0200

Ja również byłbym chętny zobaczyć taki TUTORIAL: “LIGHTTPD z PYTHONem i FastCGI” na przodzie :)
Pozdrawiam

"Lightpd & FastCGI vs. Apache & mod_php,mod_python..." by Michał Kwiatkowski

Mon, 24 Apr 2006 20:13:04 +0200

A podzieliłbyś się kawałkami plików konfiguracyjnych? Takie krótkie HOWTO jak postawić Pythona na Lighttpd z FastCGI z informacjami gdzie skąd ściągnąć i gdzie co wpisać to byłoby coś. :)