Jarosław Zabiełło - BLOG: Tag apache

Passenger bliżej - Rails, Rack i WSGI

Jarosław Zabiełło — Sat, 07 Jun 2008 15:24:00 +0200

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.

Wszystkie testy były wykonywane na laptopie MacBook Pro Core 2 Duo, 2.16GHZ, 4GB RAM (OSX 10.5.3 dla tego modelu widzi tylko 3GB) i dyskiem 200GB kręcącym się z szybkością 7200 rpm. Ruby 1.8.6, Python 2.5.2, Apache 2.2.8 (mpm-prefork) były instalowane z MacPortów. Passenger, mimo że instalowany ze źródeł w Apache’u był wyświetlany jako “Phusion_Passenger/1.1.0” (być może więc to nie jest jeszcze ta nowa wersja 2.0 o której pisałem wcześniej) Nie sprawdzałem Linuksa, być może wyniki i wnioski będą wtedy inne.

Dla tych co chcieliby sami popróbować podaję wpierw konfigurację serwerów wirtualnych dla Apache’a potrafiącą unieść razem: PHP (2.5.6), Rails (2.1), Merb (0.9.4 edge), i Django (edge).

Konfiguracja Apache’a 2.2.8


# Ruby (Rails):
<VirtualHost *:80>     
  DocumentRoot "/opt/local/apache2/vhosts/rails_app/public"  
  ServerName rails_app
</VirtualHost>

# Ruby (Merb):        
<VirtualHost *:80>  
  RailsAutoDetect off  
  DocumentRoot "/opt/local/apache2/vhosts/merb_app/public"    
  ServerName merb_app       
</VirtualHost>

# Python (WSGI):
<VirtualHost *:80>          
  DocumentRoot "/opt/local/apache2/vhosts/wsgi_app/public"    
  ServerName wsgi_app
</VirtualHost>      

# Django (mod_python)
<VirtualHost *:80>         
  DocumentRoot "/opt/local/apache2/vhosts/djangus/public"    
  ServerName django_modpython 
  <Location "/">
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE djangus.settings
    PythonDebug On        
    PythonPath "['/opt/local/apache2/vhosts'] + sys.path"    
  </Location>       
</VirtualHost>   

# PHP:
<VirtualHost *:80>  
  RailsAutoDetect off  
  DocumentRoot "/opt/local/apache2/vhosts/php_app/public"        
  ServerName php_app   
</VirtualHost>

Wszystkie aplikacje korzystające z mod_passengera muszą posiadać folder public i tmp. Gdy do katalogu tmp dorzucimy jakikolwiek (może być pusty) plik o nazwie restart.txt, to przy następnym przeładowaniu przeglądarki nastąpi restart aplikacji.

We wszystkich przypadkach użyłem dosyć banalnego kodu polegającego na wyświetleniu “Hello World!”. Z wyników programu ab wyciąłem nieistotne informacje.

Rails (2.1)

Rails 2.1 + mod_passenger 1.1.0

Rails obsługiwane są w Passengerze praktycznie bezobsługowo. Wystarczy wkopiować pliki na serwer i to wszystko.

ab -n 1000 -c 1 http://rails/ 
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Total transferred:      582000 bytes
HTML transferred:       12000 bytes
Requests per second:    430.20 [#/sec] (mean)
Transfer rate:          244.35 [Kbytes/sec] received

ab -n 1000 -c 4 http://rails/
...
Concurrency Level:      4
Failed requests:        239
   (Connect: 0, Length: 239, Exceptions: 0)
Write errors:           0
Total transferred:      488073 bytes
HTML transferred:       9132 bytes
Requests per second:    520.75 [#/sec] (mean)
Transfer rate:          247.88 [Kbytes/sec] received

Szybkość nie jest najgorsza, ale niepokojąca jest duża lista błędnych requestów w wypadku zapytań równoległych. Jak się dalej okazuje, ten problem dotyczy także obługi Rack jak i WSGI. Albo to jakaś specyfika OSX, albo wcale nie jest tak dobrze ze stabilnością mod_passengera dla równoległych zapytań. Trzeba by było też zbadać, czy ten efekt występuje także dla Linuksa. Zdziwiłbym się gdyby tam było podobnie skoro Dreamhost już oferuje hosting z mod_rails…

Dla porównania Rails używający Mongrela, Thin oraz Ebb. Można by pokusić aby odpalić Ebb i Thina na uniksowych socketach (Ebb też to już potrafi!), ale wtedy musiałbym zestawiać klaster i uruchamiać to przez proxy. Jak ktoś chce to niech się sam pobawi. Dla prostoty użyłem portów TCP. Sprawdziłem też JRuby.

Rails 2.1 + Ebb 0.2.0

ebb_rails -e production start

ab -n 1000 -c 1 http://127.0.0.1:3000/
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    488.95 [#/sec] (mean)

ab -n 1000 -c 4 http://127.0.0.1:3000/
..
Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    533.22 [#/sec] (mean)

Szybkość większa od mod_passengera i co ważniejsze, zero jakichkolwiek błędów przy pracy równoległej.

Rails 2.1 + Thin 0.8.1

thin start -e production              

ab -n 1000 -c 1 http://127.0.0.1:3000/
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    485.95 [#/sec] (mean)

ab -n 1000 -c 4 http://127.0.0.1:3000/
...              
Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    506.21 [#/sec] (mean)

Szybkość trochę mniejsza od Ebb, ale stabilność b. dobra.

Rails 2.1 + Mongrel 1.1.5

script/server -e production

ab -n 1000 -c 1 http://127.0.0.1:3000/
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    373.74 [#/sec] (mean)

ab -n 1000 -c 4 http://127.0.0.1:3000/
...
Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    360.46 [#/sec] (mean)

Stabilność bez zarzutu, wydajność jednak mniejsza od serwerów pracujących asynchronicznie.

Rails 2.1 + JRuby 1.1.2

W wypadku JRuby trzeba go trochę “rozgrzać”. Pełna wydajność Javy pojawia się po jakimś czasie pracy. Wynika to ze specyfiki i możliwośći JVM która dokonuje dynamicznych optymalizacji kodu w trakcie jego działania (z tego powodu Java potrafi przewyższyć wydajnością C++). “Dla rozgrzewki” przepuściłem Rails przez 30 tys. requestów co spowodowało że początkowych 137 req/s zrobiło się 257 req/s.

jruby script/server -e production    

ab -n 1000 -c 1 http://127.0.0.1:3000/
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    200.48 [#/sec] (mean)

ab -n 1000 -c 4 http://127.0.0.1:3000/
...
Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    257.05 [#/sec] (mean)

JRuby jest stabilny ale z wydajnością dla Rails jeszcze jest trochę do poprawienia. Dorzucenie opcji optymalizacyjnych, czyli odpalenie Rails przez

  
jruby -J-server -J-Djruby.compile.frameless=true script/server -e production

trochę poprawiło wynik: 273 req/s, ale generalnie nie jest to wielka różnica. JRuby 1.1.x już ma domyślnie powłączane optymalizacje.

Rails – wnioski

mod_passenger dla Rails faktycznie jest wydajny, choć trzeba jeszcze by zbadać dlaczego zwraca tyle błędnych requestów dla równoległych zapytań i czy ten problem występuje też na Linuksie. Dlatego na razie najwydajniejszym i najstabilniejszym rozwiązaniem dla Rails wciąż pozostaje kombinacja nginx + proxy do ebb lub thin. mod_passenger kusi głównie prostotą konfiguracji (właściwie brakiem konfiguracji). No i chyba ja to testowałem dla mod_passengera w wersji 1.1, a nie 2.0 (przynajmniej taka się wyświetla w Apache).

Merb 0.9.4 edge

Merb 0.9.4 edge + mod_passenger 1.1.0

Aby użyć frameworka Rack z Passengerem trzeba w katalogu projektu tworzyć plik config.ru zawierający konfigurację Rack’a. W wypadku Merba będzie to

require 'rubygems'
require 'merb-core'

Merb::Config.setup(:merb_root   => ".",
                   :environment => ENV['RACK_ENV'])
Merb.environment = Merb::Config[:environment]
Merb.root = Merb::Config[:merb_root]
Merb::BootLoader.run

run Merb::Rack::Application.new

Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    762.62 [#/sec] (mean)

Concurrency Level:      4
Failed requests:        247
   (Connect: 0, Length: 247, Exceptions: 0)
Write errors:           0
Requests per second:    985.15 [#/sec] (mean)

Merb jest wciąż dużo szybszy od Rails. Podobnie jak dla Rails, wiele równoległych zapytań nie zostało poprawnie wykonanych. Na produkcyjne użycie Passengera dla Merba jest jeszcze trochę za wcześnie.

Merb 0.9.4 edge + ebb 0.2.0

merb -e production -a ebb  
...                              
Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    1463.69 [#/sec] (mean)

Concurrency Level:      10
Failed requests:        0
Write errors:           0
Requests per second:    1560.60 [#/sec] (mean)

Merb na Ebb deklasuje wydajnością wszystkie inne rozwiązania. Tylko czysty PHP jest w stanie mu dorównać, ale porównywanie PHP z całym, złożonym frameworkiem Rubiego jest trochę bez sensu. Z tego co mówił ostatnio (na kanale IRC) Ezra Zygmuntowicz, podpięcie Ebb na czystym Rack’u, daje nawet 7 tys req/s i deklasuje (rzekomo) szybkiego PHP. Gadanie o wyższej wydajności PHP jest po prostu głupie. Można się założyć, że jakiekolwiek porównanie frameworka naprzeciw frameworka, tj. Merba z Symfony czy Cake PHP, obnaży bezlitośnie słabości PHP tak, jak to zrobił Django w jednym ze starszych testów.

Merb 0.9.4 edge + thin 0.8.1

merb -e production -a thin 
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    1147.78 [#/sec] (mean)

Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    1234.82 [#/sec] (mean)

Wydajność równie dobra, choć trochę słabsza od Ebb. Sporo więcej od Rails i zero problemów ze stabilnością.

Merb 0.9.4 edge + mongrel 1.1.5

merb -e production -a mongrel
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    868.10 [#/sec] (mean)

Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    837.01 [#/sec] (mean)

Mongrel jest wolniejszy od serwerów asynchronicznych ale i tak wyraźnie szybszy od Rails.

Merb 0.9.4 edge + JRuby 1.1.2

 
jruby -S merb -e production 
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    449.52 [#/sec] (mean)

Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    505.52 [#/sec] (mean)

Merb na “rozgrzanym” (30 tys. req) JRuby osiąga wydajność taką jak najszybsze rozwiązania dla Rails z użyciem asynchronicznego Ebb! To znaczy, że użycie produkcyjne Merba w systemach Javy ma jak najbardziej sens.

Passenger & WSGI

Pora na przyjrzenie się temu jak mod_passenger daje sobie radę z Pythonem. W katalogu ze źródłami Passengera leży gotowa, prosta aplikacja WSGI. Dzieki dobrej dokumentacji Django, udało mi się uruchomić ten framework pod Passengerem. Gorzej było z Pylons. Nie udało mi się stworzyć poprawnego pliku passenger_wsgi.py, niezbędnego do tego aby Passenger uruchomił aplikację WSGI.

Django edge

Django, mimo swych zalet, stosuje bardzo głupią politykę nie wypuszczania kolejnych wersji kodu. Dostępna na stronie wersa 0.96 jest stara i generalnie zaleca się aby używać nowszą wersję, która istnieje tylko w repozytorium Subversion. Oparcie kodu produkcyjnego o wersję edge jest trochę ryzykowne i szybko sprowadza się do złej praktyki ciągłego łatania kodu.

W wypadku Django plik passenger_wsgi.py zawiera kod:

import os, sys
sys.path.append('/bezwl/sciezka/do/nazwaprojektu') 
os.environ['DJANGO_SETTINGS_MODULE'] = 'nazwaprojektu.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

  ab -n 10000 -c 10            
  ...   
  apr_poll: The timeout specified has expired (70007)

Test padł po 9tys requestach. Dalej nie można było uruchomić Django. Dopiero restart calego Apache’a pomógł. Dla niższej ilości równoległych zapytań (ab -n 1000 -c 4) Django nie padło, ale było dużo błędnych requestów. Okazało się, że problem wynikał z równoczesnej obecności modułu mod_python i mod_passenger. Nie można ich razem włączać.

Usunięcie mod_passengera i zostawienie samego mod_pythona pomogło. (Albo jest jakiś konflikt między nimi, albo (co bardziej jest prawdopodobne) trzeba poczekać na opcję wyłączającą passengera dla serwera wirtualnego używającego mod_pythona. Dla Rails i Rack są takie opcje (RailsAutoDetect, RackAutoDetect), dla WSGI nie mogłem nic takiego znaleźć w kodzie źródłowym. Modułu mod_wsgi nie sprawdzałem, bo nie było go dostępnego w portach OSX.)

Po zablokowaniu mod_passenger’a tym razem mod_python nie zwracał żadnego błędnego requestu.

Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    934.87 [#/sec] (mean)

Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    1240.26 [#/sec] (mean)

Nie jest źle. Django jest tu wyraźnie szybsze od Rails (co nikogo nie dziwi), ale jest wolniejsze od Merba, co dla miłośników Pythona może być przykrą niespodzianką. Większość krytyki Rubiego oparta jest na krytyce (słabszej) wydajności Railsów. Okazuje się, że winny nie jest Ruby, ale słabo zoptymalizowany Rails. Merb jest dowodem na to, że można napisać w Rubim framework, który nie tylko będzie partnerem dla rozwiązan Pythona, ale nawet potrafi je przewyższać wydajnościowo.

Zobaczmy jak wypadnie mod_passenger.

Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    904.60 [#/sec] (mean)

Concurrency Level:      4
Failed requests:        240
   (Connect: 0, Length: 240, Exceptions: 0)
Write errors:           0
Requests per second:    497.51 [#/sec] (mean)

W pracy jednoprocesowej nie można mieć zastrzeżeń. Szybkość jest niezła. Niestety praca równoległa to porażka. Dużo requestów nie zostało obsłużonych. Gorzej, za drugim razem (tylko dla 4 rownoległych zapytań) Django kompletnie się załamało i zwróciło wyjątek “apr_poll: The timeout specified has expired (70007)”. Nie można było go dłużej używać. Wymagany był restart Apache’a.

Aby sprawdzić czy to tylko problem Django czy ogólnie implementacji WSGI dla mod_passengera, uruchomiłem test na prostej aplikacji WSGI. Niestety sytuacja jest ta sama.

Wniosek: mod_passenger dla Pythona wymaga dopracowania pracy równoległej. Jeszcze za wcześnie aby go używać z Pythonem. Ale z drugiej strony uruchomiłem mod_passengera z WSGI trochę przedwcześnie. Nie ma przecież w manualu ani jednego zdania o tym, że Passenger działa z WSGI. Oparłem się tylko na pogłoskach i wygrzebałem tą opcję ze źródeł. Więc jeszcze wszystko może się tu zmienić. To samo dotyczy Rack’a. Twórcy muszą przyjrzeć się problemom związanym z obsługą równoległych zapytań.

Update

Jednak dobrze się domyślałem, Apache nie oszukiwał. W tekście testowałem starszego Passengera 1.1. Także nie był to Ruby Enterprise. NOWY Passenger 2.0RC1 oraz Ruby Enterprise został dopiero niedawno opublikowany. Co ciekawe, dodano obsługę Apache MPM Worker a nie MPM Prefork, co dodatkowo zmniejsza zużycie pamięci. Niestety Passenger 2.0RC1 jest na razie dostępny tylko w wersji na Linuksa.

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

Jarosław Zabiełło — Wed, 04 Jun 2008 01:40:00 +0200

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).

Drugim, ciekawym projektem firmy Phusion jest Ruby Enterprise (wersja 1.0 ma być dostępna lada dzień razem z Passenger 2.0). Jest to podrasowana wersja interpretera Rubiego (MRI) powodująca nie tylko przyśpieszenie ale także znaczne zmniejszenie zużycia pamięci RAM (dodano technikę copy-on-write do garbage collectora interpretera MRI, dokładniej opisano to na slajdach). Wg tego co twierdzą ludzie z Phusion, uzyskano zmniejszenie o 33% zużycia pamięci przez Rails. To bardzo dobra wiadomość, bo pamięć mimo, że jest generalnie tania, nie jest tania w ofertach hostingowych VPS.

Passenger wprowadza nową jakość dla frameworków Rubiego. Coraz więcej firm hostingowych to docenia i przechodzi na Passenger’a (z tych bardziej znanych, Dreamhost już tego używa). Sam moduł mod_passenger jest nie tylko trywialny w użyciu, jest też bardzo szybki i stabilny. Chyba nadchodzą ciężkie chwile dla tych, co trzymali się PHP głównie z powodu jego taniego hostingu i prostoty uruchomiania serwerze. Rails i Merb mogą wkrótce trochę pozamiatać po PHP. :)

Szybkość mod_passenger’a robi wrażenie. Bije wydajnością kombinację Nginx + asynchroniczny Thin używający szybkich, uniksowych socketów. Jest też szybszy od komercyjnego Litespeed’a.

Co ciekawe, mod_passenger obsługuje interfejs WSGI do Pythona! Jeden moduł pozwoli więc na odpalanie Rails, Merb’a i Django równocześnie. Mało tego, jeśli mod_passenger dla Pythona będzie działał tak sprawnie jak dla Rails, to będziemy mieć trywialne przeładowywanie aplikacji Django bez konieczności restartu całego Apache’a.

Vide:

The Holy Grail for Rails Deployment

28 mod_rails / Passenger Resources To Help You Deploy Rails Applications Faster

Passenger 2.0 na GitHub.com dla tych, co chcą już teraz zainstalować mod_passenger 2.0 (ja już to zainstalowałem)

Update

2008-06-25

Phusion Passenger 2.0 and Ruby Enterprise Edition from Carl Youngblood on Vimeo

Ruby Enterprise Edition 32bit na debianie etch 64bit?

Passenger mod_rails

Jarosław Zabiełło — Sat, 19 Apr 2008 05:31:00 +0200

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!

Muszę przyznać, że początkowo byłem dosyć sceptycznie nastawiony do pomysłu mod_rails. Przede wszystkim, dziwnym wydawało się tworzyć moduł do Apache’a dla frameworka, czyli w sumie aplikacji, a nie dla samego języka Ruby. Niestety, istniejący od jakiegoś czasu mod_ruby był niedopracowany i krytykowany do tego stopnia że użycie go do Rails jest po prostu niezalecane. Dlatego od samego początku, gdy pojawił się Rails, promowano inne rozwiązanie (oparte na FastCGI). Pierwsze wydanie “Agile Web Development with Rails” jeszcze to promowało. W drugim wydaniu (wydanym również po polsku) autorzy przyznali że to rozwiązanie nie było wolne od szerego problemów. Na szczęście pojawił się Mongrel i bardzo szybko kombinacja szybkiego serwera HTTP z przodu + load balancing do klastera z mongreli stała się główną metodą używania Rails na serwerze produkcyjnym. I choć później pojawiły się jeszcze rozwiązania asynchroniczne (Swiftiply i evented_mongrel, Thin, Ebb), to zasadniczo niewiele wnosiły do rozwiązania standardowego poza trochę większą szybkością i innym (właśnie asynchronicznym) typem pracy.

Do tej pory sympatycy Ruby on Rails trochę smętnie poglądali na prostotę uruchamiania aplikacji “tego paskudnego pehapa” za pomocą modułu mod_php. To dzięki niemu PHP zdobył swoją popularność. Stworzenie prostej strony webowej stało się banalnie proste i nie wymagało dodatkowej wiedzy o load balancingu, ustawianiu buforowania, sposobie restartu klastera mongreli itp. Po prostu wrzucam plik i działa. Nawet sam DHH zaczął ostatnio wzdychać za taką prostotą uruchamiania aplikacji.

Stworzony mod_rails ma ambicję aby uruchomienie Railsów było tak proste jak to tylko możliwe. Z tego co mogłem sprawdzić, faktycznie działa to świetnie. Praktycznie nie jest wymagana żadna konfiguracja. Wystarczy raz ustawić Apache’a i można skupić się na budowaniu aplikacji. Domyślnie mod_rails uruchamia Rails w trybie produkcyjnym więc zmiana kodu wymaga przeładowanie aplikacji. Jednakże cała taka operacja sprowadza się do stworzenia pustego pliku restart.txt w podkatalogu tmp. Gdy Apache znajdzie taki plik, błyskawicznie przeładowuje pliki Rubiego i usuwa plik. Nie trzeba też zastanawiać się jak wyklucząć przetwarzanie plików statycznych i tworzonych przez mechanizm cache w RoR, mod_rails robi to automatycznie. Do tego zapewniona jest także ładna obsługa błędów. Po prostu wygląda to rewelacyjnie.

Jak z wydajnością? Jest całkiem nieźle. Autorzy twierdzą, że mod_rails jest trochę szybszy od thin’a. Mnie wyszło trochę odwrotnie, ale też nie robiłem zbyt drobiazgowych porównań. Nawet jeśli klaster serwerów thin czy ebb pracuje trochę wydajniej, to pokusa prostoty i wygody użycia mod_rails jest trudna do odparcia. Szkoda tylko, że mod_rails, jak sama nazwa wskazuje, pracuje tylko z Ruby on Rails. Dobrze by było, żeby później powstała podobna obsługa dla Merb’a (Choć Rails się także rozwija, Merb wciąż go mocno wyprzedza wydajnościowo. Tak z prostych testów mi wyszło, że potrafi być szybszy nawet 2-3 razy). Nie można jednak autorom mod_rails mieć przecież za złe, że poświęcili się najpopularniejszemu frameworkowi.

Passenger mod_rails to nie ostatnie słowo w sprawie deployingu Railsów. Podobną prostotą charakteryzuje się JRuby on Rails, ale o tym następnym razem.

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.

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.

Migracja z Apache2 do Lighttpd

Jarosław Zabiełło — Sat, 04 Feb 2006 20:39:00 +0100

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.