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

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 Ruby on Rails | Tagi apache, fastcgi, lighttpd, mod_python, rails | 9 comments

Comments

Skomentuj

nuke edit
lopex powiedział about 24 hours later:

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;
}
```
nuke edit
Jarosław Zabiełło powiedział 1 day later:

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"
nuke edit
lopex powiedział 3 days later:

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
nuke edit
Jarosław Zabiełło powiedział 3 days later:

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. 
```
nuke edit
hosiawak powiedział 6 days later:

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.
nuke edit
Jarosław Zabiełło powiedział 6 days later:

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ą.
nuke edit
XANi powiedział over 2 years later:

Niestety Lightowi czasami brakuje troche na funkcjonalności ale pod wzgledem pamięciożerności bije apacha na łeb ;] No chyba że ktoś ma nadmiar RAMu ale taki nadmiar lepiej wykorzystać chociażby na memcached. btw. jak robisz testy przez ab, testuj dla różnej wartości -c (concurrency, ile żądań na raz), jak robilem testy (tyle że na statycznych plikach) to lighty wyprzedzal ngixa przy wyższych wartościach (zreszta mam ten test na stronce)
nuke edit
Jarosław Zabiełło powiedział over 2 years later:

A ja dla odmiany trochę ostatnio wróciłem z częścią aplikacji do Apache’a. Wszystkie aplikacje w Ruby chodzą mi pod Passengerem. Ostatnio PHP też (wcześniej był Nginx i fastcgi ale mi czasem się coś gubiły procesy – “odpadały” mi od mastera i zamieniały się w zombie) Pamięci trochę mam, więc ten argument nie jest najważniejszy.
nuke edit
XANi powiedział over 2 years later:

Jakby nie patrzeć pod względem możliwości konfiguracji i dokumentacji apache bije wszystkie inne serwy, tyle że pliki statyczne służy wolniej (bo przy trześci dynamiczniej praktycznie nie ma różnicy) ale jak ktoś naprawdę potrzebuje to zawsze może postawić reverse proxy albo oddzielny serwer do serwowania np. grafik. U siebie mam większość na apachu, tylko 2 chodzą na lightym (bo chciałem devovi dać “oddzielne środowisko” a nie chciało mi się zbytnio grzebac w apachu, no i jak coż będzie nie tak z jednym to drugi cały czas działa).