Witam:)
Chciałbym polecić milutkie rozwiązanie do serwowania railsów. Mianowicie chodzi mi o lighttpd jako front-end używający paru procesów mongrela jako back-endy. Cała konfiguracja jest bardzo szybka, może nawet szybsza niż fastcgi i dodatkowo bardzo stabilna. Aby mieć taki bajer należy odkomentować w lighttpd.conf mod_proxy i skonfigurować serwer w sposób następujący:server.document-root = "/ścieżka/do/aplikacji/public"
proxy.balance = "fair" #może też być "hash" i "round-robin" [ten ostatni ponoć ma jakieś błędy]
proxy.server = ( "/" => ( ( "host" => "127.0.0.1", "port" => 8001 ),
( "host" => "127.0.0.1", "port" => 8002 ) ) )
Potem uruchamiamy wymaganą ilość procesów mongrela, aby to zrobić wchodzimy do katalogu z naszą aplikacją i wykonując komendę mongrel_rails start z odpowiednimi parametrami. Ja zrobiłem to pętelką z shella:for i in `seq 5`
do
mongrel_rails start -d -p 800$i -a 127.0.0.1 -e production -P log/mongrel-$i.pid
done
Użytkownicy zsh mogą sobie to uprościć w sposób następujący:for i in {1..5} #'bash' napisałem żeby uzyskać kolorowanie składni ofcoz ;-)
mongrel_rails start -d -p 800$i -a 127.0.0.1 -e production -P log/mongrel-$i.pid
Tu oczywiście odpalam 5 procesów mongrela, ale pamiętajmy żeby uruchomić tyle procesów na ile mamy skonfigurowanego lighttpd Ważne jest też żeby odpalić bazę danych przed uruchomieniem back-endów [inaczej ich nie uruchomimy:)].
Jeśli chcesz wykorzystać jakieś inne tryby balansowania modułu mod_proxy odsyłam do jego dokumentacji. Dodatkowo mongrel domyślnie servuje w utf8, więc nie musimy używać filtrów dodających kodowanie do naglówka http.
Mam nadzieję ze ten post komuś pomoże. Pozdrawiam
EDIT: Zamiast bawić się shellowymi pętelkami do startowania wielu backendów można użyć plugina mongrel_cluster, rozszerza on polecenie mongrel_rails o dodatkowe komendy:
cluster::configure
cluster::restart
cluster::start
cluster::stop
Komenda „cluster::configure” zapisuje plik konfiguracyjny „config/mongrel_cluster.yml”, możemy ją wywolać z parametrami z jakimi wykonujemy zazwyczaj „mongrel_rails start” [plus jeszcze dodatkowo „-N <liczba-serverów-do-odpalenia>”, bez „-d”, to jest dodawane automatycznie przy starcie;-)], czyli np „mongrel_rails cluster::configure -p 8001 -a 127.0.0.1 -e production -P log/mongrel.pid -N 3”, zapisany plik będzie wyglądal mniej wiecej tak:---
port: "8001"
environment: production
address: 127.0.0.1
pid_file: log/mongrel.pid
servers: 3
Znaczenie pozostałych komend jest chyba oczywiste, przy czym „cluster::start” startuje servery nasluchujące na kolejnych portach [w tym przypadku 8001, 8002, 8003], więc nie musimy się bać o błędy o zajętych portach:P
[quote=maniel]Witam:)
Chciałbym polecić milutkie rozwiązanie do serwowania railsów. Mianowicie chodzi mi o lighttpd jako front-end używający paru procesów mongrela jako back-endy.[/quote]
Ok, kolejny sposob na odpalenie railsow (BTW: apache tez mozna w ten sposob odpalic). Robiles moze jakies benchmarki tego ?
“NOTE: On FreeBSD and Mac OSX I’ve found Mongrel performs really poorly.” - to poprostu dyskwalfikuje ten projekt w moich oczach. Apache i lighttpd wykazuja tendencje do lepszych wynikow (dzieki accf_http), wiec widze tu raczej problem natury programistycznej. Dobra, koncze juz z tym advocacy:)
Owszem, wiem ze apache też można z używac jako frontenda do mongrela. A co do benchmarków… to nie wiem, albo ja mam za słabą machine czy cuś, bo praktycznie nie widać różnicy [5.5 req/s, z kompresją stronek + caches_action, ~40 req/s (albo ~70, nie pamiętam:P) z caches_page] A to że mongrel dziala kijowo na *BSD i pochodnych to rzeczywiście wada, i to duża [ale to juz nie moja wina!!!:P].
Robilem pewne testy i musze przyznac, ze mongrel dziala wolniej niz konfiguracja oparta o FCGI (w moim przypadku testowalem mod_fcgid + apache 2). Kiedy mongrel osiaga okolo 22 rps, to analogiczna strona przy fcgi ma 55 rps. Roznica jest wiec dosc duza. Na razie nie testowalem jeszcze rozpraszania konfiguracji opartej o fcgi, za chwile dopiero zaczne szukac jak ja zrealizowac. W przypadku mongrela jest ona bardzo prosta… choc wada jest wlasnie zmniejszona wydajnosc.
BTW, maniel, masz dosc slaba wydajnosc z caches_page. Ja mam dla opisywanej powyzej strony okolo 550 rps przy caches_page. I teraz sie zastanawiam, czy ja mam cos nie tak, czy Ty (nie chodzi nawet o wartosci ale o dysproporcje).
Takie mało mówiące wyniki daje mi mój prawie siedmioletni sprzęt;-)
Swoja drogą, ostatnio bawiłem się z scgi, wyniki podobne jak wyżej [tylko nie wiem czy wiarygodne:P]. Co mnie zdziwiło to stosunkowo niskie obciążenie systemu w porównaniu do mongrela czy nawet fcgi Obsługa podobna jak w przypadku mongrela, uruchamia się parę wątków klastrowo, potem korzysta z nich serwer.
Musze sie troche zreflektowac i przyznac, ze Mongrel az tak bardzo nie odstaje w stosunku do FCGI. Dlaczego wiec predzej napisalem co innego? Duza roznica najprawdopodobniej wynikala z przeprowadzania obu testow na roznych systemach operacyjnych. Mongrela testowalem na Windows XP + Apache 2.2 i mial predkosc dwa razy mniejsza od Apache 2.0 + mod_fcgid pod Linuksem. Przed chwila uruchomilem Mongrela na linuksie (przez lighttpd tym razem; wiem ze bardzo duzo roznych opcji) i sie okazalo, ze tylko troszke jest gorszy od FCGI. Troszke, czyli ~5 rps roznicy.
Wynika z tego najprawdopodniej, ze winna jest implementacja mongrela/rails/rubyego pod Windows xp… ale pozostaje tez mozliwosc, ze tak zle dziala mod_proxy_balancer z apache 2.2 w stosunku do proxy.balance z lighttpd. Ciezko teraz mi to oceniac, nie bede tego testowal, bo nie mam rpm’a z apache 2.2 (a tam jest proxy balancer). Sadze mimo wszystko, ze roznica jest spowodowana systemem operacyjnym a nie serwerem www odpowiedzialnym za przekazywanie requestow.
SCGI sie nie bawilem, nie wiem w zasadzie czy warto, malo o tym ludziki pisali na necie. Ostatnio strona domowa ror przeszla na apache+mongrel. Ja zostane tymczasem przy lighttpd (1.4.11) i jego fcgi. Spisuje sie, przynajmniej w moim wypadku najszybciej.
Dodam jeszcze, ze analogiczna strona, ktora podlegala testowania (stosunkowo prosta, nie korzysta z polaczenia z baza danych) zrealizowana w JSP na Tomcacie dziala dwa razy szybciej (okolo 120 rps). Chyba taka cena korzystania z urokow Ruby’ego.
Ważne jest też żeby odpalić bazę danych przed uruchomieniem back-endów [inaczej ich nie uruchomimy:)].