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

Merb 0.9.7

Jarosław Zabiełło — Mon, 15 Sep 2008 01:07:00 +0200

Ostatni wpis o Merbie 0.9.6 wywołał trochę nerwowych reakcji w komentarzach. Niektórzy mieli problemy z instalacją gemów. M.in. zaplątała się literówka w pluginie generującym modele Sequela. Wysłałem patch, który został już wciągnięty do repozytorium.

Aktualnie oficjalnym gemem Merba dostępnym już w RubyForge jest wersja 0.9.7. Wersja rozwojowa nosi numer 0.9.8. Skrócono czas wydań kolejnych gemów do 5 dni. Gemy z Merbem 0.9.8 mają wyjść ok. 20 września. Pięć dni później, 27 września ma pojawić się wersja 0.9.9. Ta wersja będzie miała zamrożone całe API i do wersji 1.0 będą już tylko poprawiane ewentualne błędy. Wersja 1.0 ma wyjść 11-12 października.

Warto zwrócić uwagę na gem Thor będący ulepszoną kombinacją Rake i Sake. Począwszy od Merba 0.9.7 Thor jest oficjalnym narzędziem do instalacji Merba wraz z zależnościami. Merb 0.9.8 ma ulepszony cache oraz mechanizm routingu (uwaga: nie jest w pełni zgodny wstecz) To jedno z końcowych większych zmian nie zachowujących wstecznej kompatybilności. Od Merba 0.9.9 nie powinno już nic się zmienić w API.

Ci, co chcieliby instalować sobie wersję edge pod Ubuntu z włączoną opcją SECURE_PATH (vide: man sudo) mogą mieć małe problemy ze ścieżkami jeśli instalowali (tak jak ja) Ruby w jakiejś nietypowej ścieżce (ja używam Ruby Enterprise, który domyślnie instaluje się w /opt/ruby-wersja). Ubuntu starszą komendę “sudo su” uznaje też za przestarzałą i zamiast niej można użyć “sudo -i”.

Zanim postąpimy zgodnie z informacjami w artykule Getting Merb and DataMapper Edge: Step-by-step, proponuję aby przełączyć się na root’a i ustawić dwie zmienne środowiskowe wyłączające sudo ze skryptów instalacyjnych Merba i DataMappera:

sudo -i
export MERB_SUDO=" "
export SUDOLESS=" "

Merb 0.9.6

Jarosław Zabiełło — Thu, 11 Sep 2008 00:22:00 +0200

Ci, co instalowali sobie Merba i robią sobie czasem aktualizację gemów Rubiego, mogą zauważyć że, co dwa tygodnie pojawia się kolejna jego wersja (w tej chwili jest to 0.9.6). Tak ma być aż do październikowej wersji 1.0. Co ciekawe, synchronicznie z Merbem pojawia się zbliżona wersja DataMappera. Nie jest to przypadek, bo deweloperzy obu projektów ściśle ze sobą współpracują (DataMapper 1.0 ma wyjść razem z Merbem 1.0).

Wydaje się, też że DataMapper zaczyna stawać się preferowanym ORM’em dla Merba, mimo że Merb nie jest od niego uzależniony (tak jak Rails od Active Record) i równie dobrze współpracuje z innymi ORM’ami napisanymi w Ruby, jak (b. dobry) Sequel czy wspomniany Active Record.

Merb aktualnie jest intensywnie szlifowany. Publiczne API jeszcze może ulec zmianie, więc ci co używają wersji bieżących muszą śledzić to, co się zmienia. Po wyjściu wersji 1.0 publiczne API ma być zamrożone aż do kolejnej wersji 2.0.

Bardzo ciekawie wygląda dodany niedawno do Merba radykalnie nowy, modularny i 100% wielowątkowy cache. Dodano też inteligentniejszą regenerację cache’a. Aplikacja nie jest zwalniana procesem regeneracji cache’a. Jeśli czas odświeżenia przeglądarki zbiegnie się z czasem odświeżenia danych, Merb uruchamia taki proces dopiero po wcześniejszym odesłaniu starszych danych do klienta. Ulepszono też sposób generowania projektu. Np. stworzenie nowego projektu, gdzie system testowania będzie oparty na RSpec, silnikiem szablonów będzie Haml, a ORM’em – DataMapper można odpalić za pomocą opcji generatora:

merb-gen app projekt --testing-framework=rspec \
                     --template-engine=haml \
                     --orm=datamapper

Jednak to, co stawia Merba wyrażnie wyżej od Rails to jego modularna budowa. Nie tylko można zamienić cały projekt w gema. Dzięki slices można całą aplikację dosłownie poskładać z gemów. Moim zdaniem, jest to nawet lepiej zrobione niż w Django.

Django 1.0

Jarosław Zabiełło — Thu, 04 Sep 2008 14:16:00 +0200

“Nie, to nie halucynacje, naprawdę już jest.” Tak rozpoczyna się ogłoszenie odnośnie wydania finalnej wersji Django 1.0. Trochę za długo to trwało. Prawdę mówiąc, nie wiem czy znajdę jeszcze dość sił aby wgłębiać się ponownie w Django. Pylons 1.0 jest planowany na koniec roku. Rails 2.2 ma podobno wyjść gdzieś koło października. Ale najbardziej oczekuję na Merba 1.0 który (wg planów) ma być się pojawić 11 października (termin łączy się z konferencją Merbcamp 11-12 X 2008 w San Diego gdzie pewnie Ezra Zygmuntowicz będzie chciał zaprezentować jego wersję finalną)

Zen of Python - uwagi

Jarosław Zabiełło — Mon, 01 Sep 2008 13:42:00 +0200

Filozofię języka Python najlepiej oddaje tzw. Zen of Python. Jest ono dostępne w jęz. angielskim z poziomu interpretera.

>>> import this

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one—and preferably only one—obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea—let’s do more of those!

W języku polskim brzmiałoby to mniej więcej tak:

Piękny jest lepszy niż brzydki.
Jawny jest lepszy niż domyślny.
Prosty jest lepszy niż złożony.
Złożony jest lepszy niż skomplikowany.
Płaski jest lepszy niż zagnieżdżony.
Rzadki jest lepszy niż zagęszczony.
Czytelność ma znaczenie.
Sytuacje wyjątkowe nie są na tyle wyjątkowe, aby łamać reguły.
Aczkolwiek pragmatyzm wygrywa z puryzmem sztywnego trzymania się reguł.
Błędy zawsze powinny być sygnalizowane.
No chyba, że zostaną celowo ukryte.
W obliczu dwuznaczności odrzuć pokusę aby zgadywać.
Powinien istnieć jeden, i najlepiej tylko jeden, oczywisty sposób do zrobienia danej rzeczy.
Chociaż sposób ten nie musi być początkowo oczywisty jeśli nie jesteś Holendrem.
Teraz jest lepsze niż nigdy.
Chociaż nigdy jest często lepsze niż właśnie teraz.
Źle, jeśli implementację jest trudno wyjaśnić.
Dobrze, jeśli implementację jest łatwo wyjaśnić.
Przestrzenie nazw są świetnym pomysłem – stwórzmy ich więcej!

Explicite vs. implicite

W przeciwieństwie do Rubiego, Python podkreśla wyższość kodu explicite nad implicite (jawnego nad domyślnym). W wypadku Pythona, wszelka informacja odnośnie symboli obecnych w kodzie źródłowym jest (zwykle) jednoznacznie określona i nie trzeba otwierać dziesiątków innych plików, aby się domyślić skąd się dana funkcja, czy zmienna, wzięła. Ilość symboli dostępnych globalnie w Pythonie (w przestrzeni __builtins__) jest relatywnie mała i łatwa do zapamiętania. Reszta zaś może być wydedukowana z deklaracji importu.

(Istnieje co prawda możliwość zaciemnienia tej przejrzystości za pomocą konstrukcji from moj_modul import * ale generalnie nie zaleca się jej stosowania. W Ruby, a w Rails w szczególności, próba zlokalizowania kodu źródłowego jest dosyć mozolnym zajęciem. Z samej deklaracji require 'jakis_plik' (podobnie jak w PHP) nie wynika nic na temat dostępnych symboli w bieżącej przestrzeni nazw. Trzeba otworzyć plik i zobaczyć co zostało zadeklarowane. W wypadku wielokrotnych zagnieżdżeń konstrukcji require trzeba bawić się w Sherlocka Holmesa aby dojść co się tam dzieje (swoją drogą nadmiar zagnieżdżeń jest sprzeczny z punktem “Płaski jest lepszy niż zagnieżdżony”). Konkurencyjny do Rails framework – Merb – postanowił zm zminimalizować ilość magii (tj. domyślnych deklaracji) w kodzie do minimum. Więc, jak widać, da się. Osobiście Merb jest moim faworytem jeśli chodzi o webowe frameworki. Jest szybki, prosty i czytelny. Zbudowany na solidnych, pragmatycznych, inżynierskich zasadach. Na 11 października 2008 zapowiadana jest wersja końcowa 1.0.)

Jak większość rzeczy, istnieje też druga strona medalu. “Magiczne” podejście przyjęte w Rubim może nie wpływa dodatnio na kwestię oczywistości (pkt. 1 Zen of Python) ale daje za to możliwość uzyskania piękniejszego kodu (pkt.1 Zen of Python) Uzyskanie tak ładnego DSL’a jak RSPec jest w Pythonie (i większości języków) po prostu niemożliwe. Zobacz też Business Natural Languages (oraz prezentację) Programiści Rubiego podkreślają walory estetyczne składni Rubiego i tu mają rację.

Jedna droga do celu

Pythonowcy mocno podkreślają zasadę “Powinien istnieć jeden, i najlepiej tylko jeden, oczywisty sposób do zrobienia danej rzeczy.” Niestety, zasada ta nie zawsze jest stosowana. Najlepszym przykładem jest SQLAlchemy, który wydaje się kompletnie ignorować tą zasadę. Nie ujmując jego możliwości, sposób jego użycia jest tak nieoczywisty, że powstały nawet nakładki na warstwę API SQLAlchemy (Elixir). Także sposób użycia wątków w Jythonie niespecjalnie pasuje do jednego, oczywistego rozwiązania. Ale pomijając takie przypadki, ogólnie zasada “jednego sposobu” wydaje się dobra.

Osoby poznające Rubiego na początku mogą być zdezorientowania setkami dostępnych metod w prawie każdym obiekcie. Początkowo także i mi wydawało się oczywiste, że powyższa zasada Zen Pythona jest lepsza niż, dziedziczone po Perlu, nastawienie na możliwość wielu rozwiązań tego samego zagadnienia. Jednakże, w miarę “otrzaskania” się ze składnią i metodami Rubiego, zasada “jednej drogi” przestała być aż tak ważna. Faktem jest że Ruby dysponuje większym arsenałem metod i konstrukcji niż Python (i przez to trudniej się go opanować niż Pythona), ale dzięki nim można pisać znacznie bardziej zwarty kod i to bez większej utraty czytelności tak charakterystycznej dla Perla. Ruby świetnie się nadaje na jednolinijkowe skrypty zamiast Basha czy Pythona.

Programowanie jest sztuką

Nawet najlepsze zasady na jakich z budowany byłby język nie zagwarantują że kod w tym języku automatycznie będzie czytelny i ładny. Nawet w Pythonie można stworzyć “potworki” składniowe. Programista może być wyrobnikiem albo artystą. Na pewno tym drugim nie zostanie ten, kto programowania po prostu nie lubi. Tak nawiasem mówiąc, w obecnych czasach, kiedy trudno jest znaleźć dobrych programistów, dobrym wskaźnikiem może być to, na ile programowanie jest czyjąś pasją. Pasjonaci bardzo szybko się uczą i prześcigają tych, co traktują programowanie tylko jako zajęcie do zarabiania pieniędzy.

Znajomość języka to nie tylko nauczenie się na pamięć jego składni i bibliotek. Każdy język ma swój “sposób myślenia”. Np. sposób optymalnego użycia Pythona/Rubiego bardzo się różni od sposobu pracy w językach takich jak Java/C++. Bywa też, że to, co tam jest tak gloryfikowane, w języku dynamicznym staje się śmiesznie łatwe albo zbędne. Ruby nie potrzebuje “dependency injection” bo to samo można uzyskać znacznie prościej na bazie samej swej składni. Python z kolei nie potrzebuje specjalnych konstrukcji dla stworzenia “singletona”, bo wystarczy mu do tego zwykły moduł. Itp. itd. Z praktyki widzę, że trzeba mniej więcej około roku aby javowiec pozbył się starych nawyków i “poczuł” Ruby Way.

Ruby, Python i natywne wątki systemu operacyjnego

Jarosław Zabiełło — Sat, 26 Jul 2008 13:22:00 +0200

Wiele się mówi o tym, że Ruby jak i Python nie posiadają obsługi natywnych wątków systemu operacyjnego. Wbudowane, tzw. green threads, nie są w stanie wykorzystać zalet maszyn wyposażonych w procesory wielordzeniowe. Istnieją jednak implementacje obu języków w czystej Javie. Czy ich użycie daje jakieś znaczące przyśpieszenie?

Wszystkie testy były wykonywane na MacBook Pro Core2 Duo 2.16GHZ, 4GB RAM i systemie Mac OS X 10.5.4 Leopard + zainstalowana Java 1.6.0_05.

Python

from time import time
from random import Random
from threading import Thread
rand = Random().randint # alias

class Test(Thread):
   def __init__ (self): 
      Thread.__init__(self)
      print "Starting %s" % self.getName()
   def run(self): 
      a = [rand(0,SIZE) for x in xrange(SIZE)]
      a.sort()
      print "%s finished" % self.getName()      

print "Start"
start = time()
THREADS, SIZE = 20, 100000
threads = []             
for i in xrange(THREADS):
    t = Test()
    threads.append(t)
    t.start()     
while True in [t.isAlive() for t in threads]:
    pass
print "Time: %s s" % (time() - start)

Dla powyższego kodu Python i Jython uzyskały wyniki:

Jython 2.2.1 = 12.15 s.
Python 2.5.2 = 14.24 s.

Rożnica jakoś podejrzanie mała wskazująca na wciąż jeszcze niedojrzałą implementację Jythona. Dla pewności, zmodyfikowałem kod tak, aby korzystał z natywnych bibliotek Javy.

from time import time
from random import Random
rand = Random().randint # alias
from java.lang import Thread, Runnable

class Test(Runnable):
   def __init__ (self): 
      print "Starting %s" % self
   def run(self):         
      a = [rand(0,SIZE) for x in xrange(SIZE)]
      a.sort()  
      print "%s finished" % self

print "Start"
start = time()
THREADS, SIZE = 20, 100000    
threads = []             
for i in xrange(THREADS):
    t = Thread(Test())              
    threads.append(t)
    t.start()     
while True in [t.isAlive() for t in threads]:
    pass
print "Time: %s s" % (time() - start)

Tym razem

Jython 2.2.1 = 11.96 s.

Różnica jest minimalna. Na dodatek panuje trochę zamieszania co do sposobu odpalania wątków w Jythonie – mętna składnia i za dużo możliwych sposobów uzyskania tego samego efektu. Po SQLAlchemy, Jython jest kolejnym przykładam całkowitej ignorancji założeń języka Python (o istnieniu jednej, oczywistej drogi do tego samego celu). Na domiar złego, mój pierwotny test zakładał testowanie miliona liczb do sortowania. Jython nie był w stanie tego testu wykonać z powodu braku pamięci dla Javy. Ruszył dopiero jak mu zaalokowałem 1GB (słownie: jeden gigabajt pamięci) za pomocą opcji (-Xmx1024M), co jest po prostu chore! Po wymianie pierwotnego range() na generatorowy xrange() zapotrzebowanie na pamięć wyraźnie zmalało i wystarczyła już opcja -Xmx256M. Jednakże kod się wykonywał tak koszmarnie wolno, że nie starczyło mi cierpliwości i zmniejszyłem ilość iteracji do 100 tys.

Ruby

require "time"
require "thread"

THREADS, SIZE = 20, 100_000

start = Time.now
puts "Start"
threads = (1..THREADS).map do |i|
  puts "Starting Thread-#{i}\n"
  Thread.new(i) do |t|
    a = (1..SIZE).map {|e| rand(SIZE)}
    a.sort!
    puts "Thread-#{t} ended\n"
  end
end
while t = threads.find {|lt| lt.alive?}
  t.join
end 
puts "Time: #{Time.now - start} s."

Pierwsze, co mi się od razu rzuca w oczy, to o wiele czytelniejsza, zgrzebniejsza składnia Rubiego, który tu korzysta z bloków kodu. Po drugie, wyniki są dosyć ciekawe:

Ruby 1.9.0 = 1.11 s
Ruby Enterprise = 2.77 s
JRuby 1.1.2 = 3.53 s
Ruby 1.8.7 = 21.82 s.

Ruby okazał się najwolniejszy w tym zestawieniu. Python był tylko trochę szybszy. JRuby, korzystający z javowych wątków systemowych, zdeklasował Rubiego, Pythona i niedojrzałego Jythona. Jednakże to nie JRuby okazał się tu zwycięzcą. Nie trzeba czekać na Ruby 2.0, wersja 1.9 posiada już natywną obsługę wątków POSIX i jest dodatkowo nieźle zoptymalizowana. Ruby 1.9 pokazał, że jest tu prawie 4x szybszy od JRuby. Nie sądzę, że tą szybkość uzyskał na lepszej implementacji wątków od Javy. Raczej ma mocno zoptymalizowany kod który był wykonywany w każdym z wątków.

Bardzo dobrze poradził sobie też Ruby Enterprise, zoptymalizowana wersja Ruby 1.8.6 przez twórców Passengera! Nie wiem jakim cudem Ruby Enterprise pobił JRubiego… no chyba, że jego twórcy dodali mu obsługę natywnych wątków systemu operacyjnego. Inaczej nie mogę sobie wytłumaczyć tak dobrego wyniku.

Updated

Dla pełniejszego obrazu uruchomiłem testy dla 1 wątku. Poprawiłem też błąd z ilością list do sortowania faworyzującą Rubiego. Ostateczne podsumowanie wygląda tak:

1 thread, 2,000,000 iterations

Ruby 1.9 = 1.69 s.
Ruby Enterprise = 3.38 s.
JRuby 1.1.2 = 7.06 s.
Jython 2.2.1 = 17.29 s.
Python 2.5.2 = 18.06 s.
Ruby 1.8.7 = 22.37 s.

20 threads * 100,000 iterations

Ruby 1.9 = 1.54 s.
Ruby Enterprise = 3.01 s.
JRuby 1.1.2 = 5.82 s.
Jython 2.2.1 = 11.86 s.
Python 2.5.2 = 12.32 s.
Ruby 1.8.7 = 22.68 s.

Czasy, kiedy Python był zawsze szybszy od Rubiego, to już przeszłość. Z wyników wynika, że to nie obsługa wątków zadecydowała o wynikach. Ruby 1.9 pobił wszystkich zarówno w teście 1 jak i wielu wątków.

Updated 2008-07-30

Poprawiłem trochę test, aby nie zużywał tyle pamięci. Wyrzuciłem więc generowanie list i sortownie. Zostało samo generowanie losowych liczb. Dodałem też kod dla Javy dla porównania.

Java

import java.util.Random;

public class Main {

  static Integer SIZE,  ITERATIONS;

  public static void main(String[] args) throws Exception {
    Integer[] threads_nr = {1, 10, 50, 100};
    SIZE = Integer.parseInt(args[1]);
    System.out.println(args[0]);
    for(Integer nr: threads_nr) {
      ITERATIONS = SIZE / nr;
      System.out.printf(" %3d thread(s) x %9s = ", nr, ITERATIONS);
      long start = System.currentTimeMillis();
      Thread[] threads = new Thread[nr];
      for(int i = 0; i < threads.length; i++) {
        threads[i] = new ThreadTest();
        threads[i].start();
      }
      while(threadsAlive(threads)) {}
      System.out.printf("%s s.\n", (System.currentTimeMillis() - start) / 1000.0);
    }
  }

  public static boolean threadsAlive(Thread[] threads) {
    for(Thread t: threads)
      if(t.isAlive())
        return true;
    return false;
  }

  static class ThreadTest extends Thread {

    @Override
    public void run() {
      Random rnd = new Random();
      for(int i = 0; i < ITERATIONS; i++)
        rnd.nextInt(SIZE);
    }
  }
}

Test:

$ java Main "`java -version`" 10000000
java version "1.6.0_05"
Java(TM) SE Runtime Environment (build 1.6.0_05-b13-120)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_05-b13-52, mixed mode)
  1 thread(s) x  10000000 = 0.361 s.
 10 thread(s) x   1000000 = 0.18 s.
 50 thread(s) x    200000 = 0.186 s.
100 thread(s) x    100000 = 0.189 s.

Java, co nie dziwi, jest najszybsza. Nie ma znaczącej różnicy między 10 czy 10 wątkami, bo mój procesor posiada tylko dwa rdzenie.

Ruby/JRuby

require "time"
require "thread"

SIZE = ARGV[1].to_i  
puts ARGV[0]   
[1, 10, 50, 100].each do |nr|
  iterations = SIZE / nr
  print " %3d thread(s) x %9s = " % [nr, iterations]
  start = Time.now
  (1..nr).map do |i|
    Thread.new(i) do |t|
      iterations.times {rand(SIZE)}
    end
  end.each {|t| t.join}
  puts Time.now - start
end

Ten sam kod w Ruby/JRuby wygląda znacznie krócej (i ładniej) ale kosztem wydajności. To też nie dziwi. Ruby jest bardzo produktywnym językiem, lecz oczywiście nie tak szybkim jak Java.

Wyniki testów:

Ruby 1.9:

$ ruby1.9 main.rb "`ruby1.9 -v`" 10_000_000
ruby 1.9.0 (2008-06-20 revision 17482) [i686-darwin9.4.0]
  1 thread(s) x  10000000 = 2.858588
 10 thread(s) x   1000000 = 2.832928
 50 thread(s) x    200000 = 2.845377
100 thread(s) x    100000 = 2.852745

JRuby:

$ jruby main.rb "`jruby -v`" 10_000_000
jruby 1.1.3 (ruby 1.8.6 patchlevel 114) (2008-07-28 rev 6586) [x86_64-java]
   1 thread(s) x  10000000 = 3.58
  10 thread(s) x   1000000 = 3.4290000000000003
  50 thread(s) x    200000 = 3.442
 100 thread(s) x    100000 = 3.516

Ruby Enterprise:

$ ruby-enterprise main.rb "`ruby-enterprise -v`" 10_000_000
ruby 1.8.6 (2008-03-03 patchlevel 114) [i686-darwin9.4.0]
  1 thread(s) x  10000000 = 3.510694
 10 thread(s) x   1000000 = 3.552756
 50 thread(s) x    200000 = 3.586885
100 thread(s) x    100000 = 3.574564

Ruby 1.8.6 (installed with Leopard):

$ /usr/bin/ruby main.rb "`/usr/bin/ruby -v`" 10_000_000
ruby 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0]
   1 thread(s) x  10000000 = 6.586917
  10 thread(s) x   1000000 = 6.78801
  50 thread(s) x    200000 = 6.951003
 100 thread(s) x    100000 = 6.907087

Ruby 1.8.7 (installed from MacPorts):

$ ruby main.rb   "`ruby -v`" 10_000_000
ruby 1.8.7 (2008-06-20 patchlevel 22) [i686-darwin9.4.0]
   1 thread(s) x  10000000 = 36.329174
  10 thread(s) x   1000000 = 36.808753
  50 thread(s) x    200000 = 36.715717
 100 thread(s) x    100000 = 36.499772

To co niepokoi, to koszmarnie wolna praca Ruby 1.8.7 w porównaniu do Ruby 1.8.6. To jest bardzo podejrzana sprawa. Cieszy za to dobra wydajność Ruby Enterprise.

Python/Jython

from random import Random
from sys import argv
from time import time
from threading import Thread
rand = Random().randint # alias

class ThreadTest(Thread):
   def __init__ (self, iterations): 
      Thread.__init__(self)              
      self.iterations = iterations
   def run(self): 
      [rand(0,SIZE) for x in xrange(self.iterations)]

SIZE = int(argv[2])
print argv[1]
for nr in [10, 50, 100]:
  iterations = SIZE / nr
  print " %3d thread(s) x %9s = " % (nr, iterations),
  start = time()
  threads = []
  for i in range(nr):
     t = ThreadTest(iterations)
     threads.append(t)
     t.start()
  for t in threads:
     t.join()
  print "%s s." % (time() - start)

Test:

$ python main.py "`python -V`" 10000000
Python 2.5.2
  1 thread(s) x  10000000 =  34.5188429356 s.
 10 thread(s) x   1000000 =  52.3496830463 s.
 50 thread(s) x    200000 =  53.9406650066 s.
100 thread(s) x    100000 =  58.3923280239 s.

Co ciekawe, Python 2.5.2 okazał się najwolniejszy. Im więcej wątków tym jeszcze wolniej działał. Był wolniejszy nawet od (dziwnie wolnego) Ruby 1.8.6. Ale, być może to jest wina bardzo wolnej biblioteki generowania losowych liczb. Ech, jak tu cokolwiek porównywać między językami jak takie odkrywa się takie babole w bibliotece standardowej Pythona.

Jython był jeszcze wolniejszy. Dla 10 mln. iteracji, mimo że nie były tworzone w pamięci żadne listy, wlókł się tak wolno, że przerwałem test. Po zmniejszeniu iteracji o rząd wielkości (do 1 miliona) uzyskał wyniki takie jak Ruby 1.8.6 dla 10 milionów iteracji. Jython jest najwyraźniej jeszcze bardzo słabo zoptymalizowany. Pomysły aby na nim odpalać frameworki takie jak Django, to na razie raczej przedwczesny pomysł.

Iterations: 1,000,000 instead of 10,000,000:

$ jython main.py "`jython --version`" 1000000
Jython 2.2.1 on java1.6.0_05

  10 thread(s) x    100000 =  6.391000032424927 s.
  50 thread(s) x     20000 =  4.368000030517578 s.
 100 thread(s) x     10000 =  4.352999925613403 s.

Aktualizacje bezpieczeństwa dla wszystkich wersji Ruby MRI

Jarosław Zabiełło — Sun, 22 Jun 2008 21:41:00 +0200

Jak o tym piszą na blogu RoR odkryto dosyć poważne dziury bezpieczeństwa w Ruby MRI we wszystkich wersjach od 1.8.5 do 1.9.0. Zalecana jest aktualizacja do nowszych wersji. Problem nie dotyczy JRuby, ktory nie musi się martwić o głupie problemy z przepełnieniem bufora typowe dla języka C.

Nie wiem jak jest z Ruby Enteprise używanym przez Passengera. Profilaktycznie przestawiłem aplikację do pracy z załatanym Ruby 1.8.7-p22 (tym bardziej, że bieżąca wersja Ruby Enterprise i tak nie pracuje szybciej w wypadku systemu 64-bitowego jaki używam na serwerze). Co ciekawe, stary Rails 1.2.3 też chodzi z nowym Ruby 1.8.7 (oficjalnie tylko Rails 2.1 jest z nim kompatybilny).

Update:

Ruby Enterprise (w skrócie REE) został dziś załatany i działa w końcu też na Mac OS-X!

Na razie lepiej uważać na tą najnowszą, załataną wersję REE, bo jest niestabilna. Na Mac OS-X oraz na Ubuntu 7.10×64 wywala “Segmentation fault” na niektórych stronach Rails. Wysłałem już informację do twórców aby to sprawdzili.

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.

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?

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.