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

MagLev - wirtualna maszyna Smalltalka dla Rubiego

Jarosław Zabiełło — Sat, 14 Jun 2008 19:11:00 +0200

Gemstone to komercyjna, rozwijana od ponad 20 lat, bardzo szybka maszyna wirtualna dla języka Smalltalk. Jest używana od lat w zastosowaniach biznesowych, m.in. w instytucjach finansowych. W odróżnieniu od innych Gemstone to coś więcej niż tylko maszyna wirtualna. Gemstone posiada wbudowany mechanizm bardzo wydajnego, transakcyjnego zapisu obiektów, chodzi to obsługę obiektów rzędu setek i tysięcy miliardów (lub informacji o wielkości 17 petabajtów). MagLev to smalltalkowy GemStone S64 VM z dodanym bytecodem pozwalającym na uruchamianie Rubiego. W różnych benchmarkach MagLev jest szybszy od Rubiego MRI od 7 do ponad 100 razy i osiąga szybkość zbliżoną do czystego C. Dodatkowo daje przezroczysty, wydajny zapis obiektów Rubiego w sposób znacznie wygodniejszy od tego co oferują relacyjne bazy danych. Czyżby wkrótce można było pokusić się o napisanie odpowiednika Zope w Rubim pracującym pod wydajną, wirtualną maszyną Smalltalka?

Na razie projekt jest młody. Maszyna wirtualna pewnie będzie zamkniętym kodem, ale reszta powinna być wolna. Pierwsza prezentacja możliwości Rubiego na MagLev odbyla się na niedawnej konferencji RailsConf 2008. Dostępne jest już pierwsze wideo z prezentacji MagLev’a (pozostałe dwie części są w trakcie przygotowywania).

MagLev presentation at RailsConf 2008 – part 1 from Monty Williams on Vimeo.

Zobacz też:

MagLev: Gemstone builds Ruby runtime based on Smalltalk VM

Avi Bryant on MagLev and GemStone – b. ciekawy wywiad (video + transkrypcja)

GemStone Reveals Plans for MagLev Ruby VM at RailsConf 2008

MagLev handles trees like a monkey

Avi Bryant – MagLev recap

MagLev rocks and the planning of the next Ruby shootout

MagLev and language implementation

RailsConf 2007 – Avi Bryant – ciekawe wystąpienie Avi Branta przekonanego że zasadniczo Ruby prawie nie różni się od Smalltalka, w zasadzie to ten sam język i nie ma żadnego powodu dla którego Ruby nie mógłby być tak szybki jak Smalltalk (a Smalltalk jest 10x szybszy od Pythona…)

Chad Fowler – MagLev

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.

JRuby Rack

Jarosław Zabiełło — Wed, 04 Jun 2008 03:56:00 +0200

JRuby Rack pozwala na wygodne uruchamianie pod JRuby zarówno Rails, Merb jak i każdy inny framework korzystający z Rack. JRuby Rack został właczony do gemu Warbler 0.9.9 używanego do budowania pliku WAR dla Rails 2.x. Vide Introducing JRuby-Rack

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?

Rails 2.1

Jarosław Zabiełło — Sun, 01 Jun 2008 12:20:00 +0200

No to mamy w końcu oficjalne wydanie Rails 2.1! Instalacja jest już też dostępna przez RubyGems.

Ruby on Rails w Irlandii

Jarosław Zabiełło — Thu, 29 May 2008 21:21:00 +0200

Tak pomyślałem, że może wrzucę info tutaj, bo trochę osób z branży czyta ten blog. Otóż w mojej firmie szukamy jakiegoś railsowca do zespołu.

Agile 3 - jednak wyjdzie

Jarosław Zabiełło — Thu, 01 May 2008 20:15:00 +0200

Mimo, że wcześniej DHH niezbyt entuzjastycznie wypowiadał się na temat pisania kolejnej edycji bestseleru Agile Web Development in Rails, to jednak ugiął się pod ciężarem oczekiwań i trzecie wydanie będzie! Ci, co nie chcą czekać, mogą już teraz kupić PDF z wersją beta książki.

Jeśli autorzy będą jak zwykle opisywać wersję edge, to książka powinna opisywać mający wkrótce wyjść Rails 2.1.

Dobrą wieścią jest też to, że Ezra Zygmuntowicz, twórca konkurencyjnego Merba) postanowił ostatnio poświęcić trochę czasu aby ulepszyć kod Railsów. Najwyraźniej oba developerzy obu frameworków się nie zwalczają ale chcą ze sobą współpracować. Ezra dodał ostatnio ciekawy mechanizm do obsługi asynchronicznych adapterów Thin i Ebb, pozwalający na tworzenie oddzielnego wątku w wypadku gdy zapytanie jest długie (aby nie blokowała się asynchroniczna pętla).

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.

GitHub oficjalnie

Jarosław Zabiełło — Fri, 11 Apr 2008 01:38:00 +0200

Po okresie pilotażowym, GitHub wystartował oficjalnie. GitHub udostępnia wygodne zarządzanie projektami korzystającymi z Git’a – rozproszonego systemu wersjonowania kodu. Poza opcjami komercyjnymi jest dostępne darmowe konto dla projektów open source (tzn. nie można w nim trzymać prywatnych, zamkniętych repozytoriów, ale poza tym jest w wystarczająco funkcjonalne). Na Git’a migruje coraz więcej projektów. Poza Merbem i (wkrótce) Railsami, na GitHuba przeniosły się już: Haml, Ebb, JSpec, Capistrano, DataMapper itd.

Nadchodzi Rails 2.1

Jarosław Zabiełło — Thu, 03 Apr 2008 04:58:00 +0200

Jest bardzo bardzo niewiele książek opisujących aktualny stan Railsów 2.0.2 a już szykuje się kolejna wersja – 2.1 (nawet The Rails Way nie opisuje 2.0.2, ale tylko trochę z wersji edge, sprzed wydania 2.0) Jaką książkę nie zaczęto by pisać, staje się szybko nieaktualna. Co za czasy…

Zmian jest całkiem sporo, do ważniejszych należą różne poprawki w Active Record. Np. w końcu ma być możliwa selektywna aktualizacja wybranych kolumn (do tej pory AR, podczas zmiany jedneego atrybutu aktualizował je wszyskie w bazie) Co prawda tą funkcjonalność od dawna mają DataMapper i Sequel, ale dobrze że AR się wkońcu tu obudził.

article = Article.find(:first)
article.changed?  #=> false

# Zmiany poszczególnych atrybutów możliwe jest za 
# pomocą akcesora attr_name_changed?
article.title  #=> "Title"
article.title = "New Title"
article.title_changed? #=> true

# Jest też dostęp do poprzedniej wartości atrybutu 
# zapomocą akcesora attr_name_was
article.title_was  #=> "Title"

# Zobacz wcześniejszą i późniejszą wartość za pomocą
# akcesora attr_name_change
article.title_change  #=> ["Title", "New Title"]

# Zapis atrybutu wykonuje zapytanie dotyczące tylko jednej, 
# odpowiadającej mu kolumny w tabeli:
article.save
  #=>  "UPDATE articles SET title = 'New Title' WHERE id = 1"

Dodano też coś, co funkcjonalnie “od zawsze” było obecne w Sequel’u, SQLAlchemy czy Django ORM, mianowicie tu nazywa się to named scope (Rails wchłonęło popularny plugin has_finder pozwalając w końcu na łatwiejsze budowanie bardziej skomplikowanych warunków odpytywania bazy).

class User < ActiveRecord::Base
  named_scope :active, :conditions => {:active => true}
  named_scope :inactive, :conditions => {:active => false}
  named_scope :recent, lambda { { :conditions => ['created_at > ?', 1.week.ago] } }
end

# Typowe użycie:
User.active    # to samo co User.find(:all, :conditions => {:active => true})
User.inactive # to samo co User.find(:all, :conditions => {:active => false})
User.recent   # to samo co User.find(:all, :conditions => ['created_at > ?', 1.week.ago])

# Możliwe są w końcu kolejne zagnieżdżenia warunków:
User.active.recent
  # to samo co:
  # User.with_scope(:conditions => {:active => true}) do
  #   User.find(:all, :conditions => ['created_at > ?', 1.week.ago])
  # end

Autorzy Rails pozazdrościli Merbowi i dodali też możliwość ładowania gemów o konkretnej wersji (być może będzie to też początek końca pluginów w obecnej postaci i Rails pójdzie i tu ścieżką Merba?)

Rails::Initializer.run do |config| 

  # Załaduj najnowszą wersję haml
  config.gem "haml"

  # Załaduj konkretną wersję chronic
  config.gem "chronic", :version => '0.2.3'

  # Załaduj gem z repozytorium innego niż RubyForge
  config.gem "hpricot", :source => "http://code.whytheluckystiff.net"

  # Załaduj gem którego nazwa pliku jest inna niż nazwa gemu
  # Np. można załadować gem który potrzebuje require 'aws/s3' zamiast 
  # require 'aws-s3'
  config.gem "aws-s3", :lib => "aws/s3" 
end

Cieszy też, że poprawiono sposób działania buforowania oraz wbudowano lepszą obsługę dat i stref czasowych.

Ale z tego wszystkiego najbardziej mnie cieszy informacja inna informacja. Wspominałem o tym trzy dni temu, teraz zostało to oficjalnie ogłoszone: Rails migruje z Subversion na Gita. W końcu będzie można liczyć na poważniejsze przyśpieszenie prac i szybsze nanoszenie zgłaszanych poprawek (do tej pory to było tragicznie wolne, np. zgłoszony przeze mnie patch uwzględniono po 8 miesiącach). Rails, identycznie jak Merb, będzie używał tego samego serwera GitHub dla kodu i LightHouse. Więc ci, co nie mają tam kont, mogą już teraz o to zadbać. Praca z Git różni się też bardzo do SVN. Trochę przydatnych linków:

W komentarzach do newsu na stronie Railsów można znaleźć głosy rozczarowania tych, co używają system Windows. Woleli by aby wybrano bardziej multiplatformowy Mercurial, ale DHH uciął dyskusję mówiąc, że decyzja została już podjęta a kolejne wersje Rails będą i tak dostępne standardowo w gemach. Poza tym na razie Git może być od biedy używany pod Cygwinem i jest też projekt msysgit. No cóż, mnie to mało interesuje. Każdy wie, że windows i tak sucks i najlepiej pracuje tylko ze samym sobą. Rails ma zaś silniejsze związki z światem POSIX, dlatego najlepiej używać Ubuntu, Mac OS X czy innych systemów uniksowych. BTW, nowy Kubuntu 8.0.4 beta nawet nieźle śmiga na VMWare pod Win32. :)