Jarosław Zabiełło - BLOG: Railsy: Lighttpd czy Apache 2.2.x?

Railsy: Lighttpd czy Apache 2.2.x?

Jarosław Zabiełło — Sun, 29 Oct 2006 15:53:00 +0100

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.

"Railsy: Lighttpd czy Apache 2.2.x?" by Jarosław Zabiełło

Sat, 04 Nov 2006 19:21:19 +0100

Właśnie próbuję zmienić Lighty na Nginx’a. Problem w tym, że mam nie tylko RoR ale także PHP, Django i Zope i to wszystko musi dobrze działać. Nie tylko dlatego, że Nginx jest szybszy. Coś mi ostatnio Lighty dziwnie się zachowuje. Muszę go restartować, bo po jakimś czasie ma problemy z odpowiedzią.

"Railsy: Lighttpd czy Apache 2.2.x?" by hosiawak

Sat, 04 Nov 2006 19:17:24 +0100

Nginx staje się ostatnio bardzo popularny na zachodzie, głównie za sprawą bardzo małej zasobożerności i dużej liczby dostępnych modułów. Ponoć jest już w użyciu dosyć długi czas w Rosji skąd pochodzi na jakimś bardzo ruchliwym serwerze – uważany jest za bardzo stabilny. Statystyki mówią, że obsługuje już ponad 90,000 domen – wystarczająco dużo, żeby uznać go za stabilny. Poza tym ostatnio ulubiony serwer Ezry ;)

Co do tej małej zasobożerności to prawda. Zrobiłem prosty test na statycznej stronie, 100,000 requestów i load nawet nie osiągnął 100% tylko oscylował na poziomie 70-80%. Wygląda bardzo zachęcająco, świetnie nadaje się jako load balancer dla clustera mongrelów i do serwowania statycznych plików.

"Railsy: Lighttpd czy Apache 2.2.x?" by Jarosław Zabiełło

Wed, 01 Nov 2006 18:06:24 +0100

Jak znajdę czas, przyjrzę mu się dokładnie. Przed chwila na swoim dedyku (Athlon64 3000+ i Ubuntu x64) odpaliłem porównania. Użyłem skompilowanych ze źródeł Apache 2.2.3, Lighttpd 1.4 i Nginx 0.4.12.

Dla

ab -n 100000 http://localhost/

i prostej strony ze zdaniem “Hello World!”, wyniki mam następujące:

Apache: 4439 req/s
Lighttpd: 7150 req/s
Ngix: 8700 req/s.

"Railsy: Lighttpd czy Apache 2.2.x?" by lopex

Wed, 01 Nov 2006 17:17:56 +0100

pop prostu: rewrite ^/(.*)$ http://host:9876/VirtualHostBase/http/host:80/plone/VirtualHostRoot/$1

dokumentacja jest pod: http://wiki.codemongers.com/NginxHttpRewriteModule

Serwer ten jest raczej dobrze wytestowany i zachowuje się lepiej niż apache, zwłaszcza przy bardzo dużym ruchu. Dużym atutem apacha są oczywiście moduły ale dla nginx też ich nie brakuje: http://wiki.codemongers.com/Nginx

"Railsy: Lighttpd czy Apache 2.2.x?" by Jarosław Zabiełło

Mon, 30 Oct 2006 16:49:19 +0100

Być może to i dobry projekt. Lecz ja bym się trochę obawiał użycia takiego mało popularnego (i tym samym słabo wytestowanego produkcyjnie) rozwiązania. Jak byś w tym serwerze zrobił proxy tego typu?


RewriteRule "^/(.*)$" "http://host:9876/VirtualHostBase/http/host:80/plone/VirtualHostRoot/$1"

"Railsy: Lighttpd czy Apache 2.2.x?" by lopex

Mon, 30 Oct 2006 15:46:30 +0100

jeśli chodzi o wydajność i pamięć to nic nie może konkurować z http://nginx.net/

ma pełno wbudowanych modułów, rewelacyjną konfigurację, jest bardzo stabilny i się bardzo szybko rozwija

konfiguracja dla mongrela wygląda tak:

upstream mongrel {
    server 127.0.0.1:8000;
    server 127.0.0.1:8001;
    server 127.0.0.1:8002;
}

location / {
        proxy_pass  http://mongrel;
        proxy_redirect     on;
}