Passenger bliżej - Rails, Rack i WSGI

Opublikowane przez Jarosław Zabiełło Sat, 07 Jun 2008 13:24:00 GMT

Stworzony pierwotnie na użytek Rails, aktualnie mod_passenger już obsługuje nie tylko Rails ale także masę innych frameworków używających Rack’a. W nowej dokumentacji wymienione są frameworki: Camping, Halcyon, Mack, Merb, Ramaze i Sinatra. W dokumentacji nie wymieniono jeszcze “drugiej listy”, zawierającej frameworki korzystające z WSGI i Pythona (np. Pylons, Django, TurboGears itp.). Chcąc sprawdzić plotki wokół tej sprawy, sprawdziłem, czy faktycznie mod_passenger pracuje nie tylko z Ruby, ale także z Pythonem. Sprawdziłem także jak to jest faktycznie z obługą Rails i frameworków na Rack’u (tu sprawdziłem tylko Merba). Sprawdziłem też JRuby dla Rails i Merba.

Czytaj dalej...

Tagi , , , , , , ,  | 6 comments

Sprzątanie po PHP czyli Passenger 2.0 i Ruby Enterprise 1.0

Opublikowane przez Jarosław Zabiełło Tue, 03 Jun 2008 23:40:00 GMT

Stało się! Twórcy świetnego modułu Apache’a – mod_rails – zmieniają jego nazwę na mod_passenger, bo mod_rails nie jest już więcej modułem tylko dla Rails. W nowej wersji 2.0 (ktora ma wyjść na dniach) dodano pełne wsparcie dla Rack i tym samym mod_passenger 2.0 obsługuje wszystkie pozostałe frameworki używające Rack’a (ze świetnym Merbem włącznie).

Czytaj dalej...

Tagi , , , , , , , ,  | 34 comments

Passenger mod_rails

Opublikowane przez Jarosław Zabiełło Sat, 19 Apr 2008 03:31:00 GMT

Choć sam Rails jest intuicyjny i prosty w użyciu, to już sposób użycia go na serwerze produkcyjnym (gdzie liczy się głównie szybkość i stabilność) nie jest takie oczywiste z powodu istnienia wielu, alternatywnych rozwiązań. Powstały niedawno moduł dla Apache – mod_rails – może wszystko zmienić. Dzięki niemu uruchomienie Rails na serwerze staje się praktycznie tak samo trywialne jak w przypadku PHP i modułu mod_php!

Czytaj dalej...

Tagi , , ,  | 5 comments

Railsy: Lighttpd czy Apache 2.2.x?

Opublikowane przez Jarosław Zabiełło Sun, 29 Oct 2006 14:53:00 GMT

Odnośnie użycia Railsów w celu produkcyjnym, dużo się zmieniło od czasu pojawienia się Mongrela – małego, ale dosyć szybkiego serwera napisanego w Ruby i C. Następuje generalne odejście od podpinania kilku procesów FastCGI do Rubiego z różnych powodów. W drugim wydaniu Agile Web Development in Rails autorzy przyznali, że próbowali różnych opcji użycia modułu FastCGI. Zawsze ostatecznie były jakieś problemy.

Aktualnie zalecanym podejściem jest użycie szybkiego serwera HTTP (Lighttpd, Apache lub LiteSpeed) na froncie do obsługi statycznych plików (głównie obrazki, style kaskadowe i pliki Javascript). Aplikację RoR należy uruchomić za pomocą kilku procesów Mongrela (nie jak wcześniej: kilka procesów FastCGI). A tym, co zepnie je z serwerem HTTP jest moduł rozkładający ruch (load balancing).

Niestety, okazało się że w wypadku Lighttpd ten moduł zawiera błędy. Z kolei nowy Apache 2.2 posiada dobrze działający moduł load balancingu. Spowodowało to zrezygnowanie przez wielu z Lighttpd na rzecz nowego Apache 2.2.x.

Z racji tego, że mam trochę swobody w doborze technologii w pracy, postawiłem serwer na nowym Apache’u. Aplikacje Railsów podpinamy za pomocą mongrela i wbudowanego w Apache modułu load_balancer. Działa faktycznie sprawnie.

Czy to znaczy, że Lighttpd nie ma sensu używać? Skąd! W wersji 1.5 mają już mieć naprawiony moduł load balancingu. Ale nawet i bez tego, istnieje bardzo dobry, mały i szybki load balancer – Pound. Skuszony jednak potrzebą eksperymentowania oraz nabytym niedawno serwerem dedykowanym (w miejsce wcześniejszego VPS’a) postanowiłem przenieść wszystkie swoje prywatne serwisy (a jest tego sporo) z Lighttpd do Apache 2.2.3. Musiałem przenieść dwie aplikacje Rails, dwie aplikacje Django, dwie aplikacje PHP 5.1 oraz jedną duża aplikację Zope/Plone. I jak wrażenia?

Otóż, po 2 tygodniach używania, stwierdziłem, że to nie ma sensu. Apache pożera za dużo pamięci. Dzieje się dokładnie tak, jak pisałem wcześniej. Nie mogłem użyć trybu wielowątkowego, nie tyle ze względu na PHP ale ze względy na Django! Napisali bowiem, że nie należy tego trybu używać w wypadku ich frameworka. Django nie jest wielowątkowy. Musiałem więc przełączyć Apache z trybu worker na prefork. Zgodnie z obawami, każdy fork musiał marnować pamięć na moduł mod_php i mod_python nawet jak to nie ma sensu (np. podczas obsługi obrazków). Na dodatek nie mogłem coś uruchomić jednej aplikacji Django. Kompletnie nie wiem dlaczego. Druga była prawie identycznie skonfigurowana i działała.

Wróciłem zatem z powrotem do Lighttpd , Pounda i Mongrela (dla RoR) i FastCGI (dla Django i PHP). Efekty były bardzo widoczne: zwolniło mi się ponad 200 MB pamięci. Może to nie ma znaczenia w pracy, gdzie mamy 2GB ale ja mam tylko 1GB i muszę jeszcze uruchomić zasobożerny Plone.

Dokładniej wszystkie sprawdzone i działające konfiguracje opiszę w powstającej książce o Railach. Moja ostateczna konlkluzja jest taka: jeśli zależy ci na oszczędzeniu pamięci – wybieraj Lighttpd. Jeśli nie jest to kluczowa sprawa, a potrzebujesz jakieś specjalne, dodatkowe moduły (których Apache ma pełno) nowy Apache 2.2 spełni twe oczekiwania.

Posted in  | Tagi , , , ,  | 9 comments

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

Opublikowane przez Jarosław Zabiełło Mon, 24 Apr 2006 17:40:00 GMT

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.

Posted in , ,  | Tagi , , ,  | 11 comments

Migracja z Apache2 do Lighttpd

Opublikowane przez Jarosław Zabiełło Sat, 04 Feb 2006 19:39:00 GMT

W końcu udało mi się pozbyć Apache2 na rzecz lżejszego i szybszego Lighttpd. Największą trudność sprawiło mi przemapowanie proxy do Plone. Przeczesałem cały serwis Zope’a i Plone ale nie mogłem znaleźć nic na ten temat. Dopiero dzięki pomocy na forum lighttpd, cała operacja została zakończona sukcesem. Aktualnie dwie instancje Plone chodzą za Lighttpd zamiast Apache’a. PHP 5.1.2 działa mi w trybie FASTCGI, no i RoR (ten blog jest napisany w Railsach) również pod lighttpd.

Tagi ,  | 1 comment