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

Wściekły Zed i dyskusja wokół Rubiego i Railsów

Jarosław Zabiełło — Sun, 06 Jan 2008 23:49:00 +0100

Ostatnio jest trochę szumie w branży po bezpardonowym (i niewybrednym) ataku Zeda Shaw uderzającym w kilka znanych postaci z kręgów Rubiego i Rails. Pewnie nikt by na to nie zwrócił uwagi gdyby nie to, że Zed jest autorem znanego projektu Mongrel. Choć wpis się źle czyta (bo jest rozwlekły i niepotrzebnie przeplatany ciągłymi przekleństwami autora) to zwrócił uwagę na kilka istotnych problemów.

Autor zwraca uwagę, że core team Railsów dosyć opornie i wolno reaguje na podsyłane uwagi i poprawki. Fakt, jedną z poprawek jaką kiedyś podesłałem odnośnie źle działającej funkcji render_to_string uwzględniono po.. ośmiu miesiącach. Zed się wkurzył, że ignorowano jego uwagi a potem i tak wychodziło na jego. Tak z połowa core teamu to wg niego banda idiotów z wypłukanymi przez PHP mózgami. Ze swej strony bym mógł do tej listy niekompetencji owej “bandy” też coś dołożyć, ale to nie jest najważniejsze. Jest reszta, która dobrze robi swoją robotę. Ale może taka krytyka podziała jak kubeł zimnej wody i w końcu cały core team zacznie skupiać się na jakości i optymalizacji już istniejącego kodu. Bo jak nie, to programiści Rails zaczną sukcesywnie przesuwać się do konkurencyjnego projektu Merb. Ezra Zygmuntowicz udowodnił, że można napisać “lepsze Railsy” (szybsze, wielowątkowe i bardziej przejrzyste). Podoba mi się inżynieryjne podejście Ezry Zygmuntowicza. Jego Merb jest bardzo ładny, przejrzysty i szybki. Co ciekawe, Ezra zatrudnił kilku developerów Rubiniusa. Zapowiada się że Railsy w końcu spotkały bardzo trudną konkurencję (i bardzo dobrze). Sytuację Ralsów pogłębia to, że nowe ORM’y takie jak DataMapper i Sequel również stanowią zagrożenie dla dominacji Active Record nawet w kontekście Railsów.

PickAxe i inne książki

Zed przeprowadził bardzo ciekawą krytykę chwalonej PickAxe. Ostro rozjechał autora za używanie głupich przykładów, niezgodnego z konwencjami Rubiego nazewnictwem zmiennych, i co najważniejsze, ominięcie szerokim łukiem najważniejszej i najbardziej atrakcyjnej cechy Rubiego – łatwości metaprogramowania. PickAxe, zdaniem Zeda, odwołuje się do starych praktyk projektowania obiektowego z roku 2001. Zed idzie nawet dalej, uważa że ta książka promuje złe nawyki programistyczne i zachęca do pisania złego kodu. Twierdzi nawet, że ta książka zamiast pomóc, zaszkodziła Rubiemu aby wcześniej wypłynął na szeroką scenę.

Faktycznie, w latach 2001-2004 o Ruby praktycznie nikt nie słyszał. Jakieś nieliczne wyjątki uczyły się Rubiego na książce Dave’a Thomasa ale język jako taki był czymś bardzo malo znanym. Sytuację zmieniło dopiero pojawienie Ruby on Rails w 2005 roku, ktore spowodowały znaczący wzrost popularności Rubiego (ja sam też zainteresowałem się też Railsami, a dopiero później Rubim). Dopiero Railsy pokazały piękno i moc metaprogramowania w Ruby, coś co zachwyciło rzesze ludzi, coś czego nie mają inne języki. I nie wiem jak by się wysilano, nie da się uzyskać tak pięknego i eleganckiego metaproramowania w PHP, Javie, czy nawet Pythonie. Zed bezpardonowo stwierdził, że PickAxe tylko zaszkodził Rubiemu zamiast mu pomóc.

Wpierw mnie zaskoczyła ta opinia, ale później, jak się zastanowiłem, to muszę przyznać że dużo w tym racji. Nigdy do mnie nie przemawiały użyte w książce przykłady. Ceniłem ją głównie za to, że w ogóle jest cokolwiek na temat Rubiego, i że opisano bibliotekę standardową Rubiego. Jestem ciekaw, co Zed by powiedział na książkę Hala Fultona “The Ruby Way”. Jej drugie wydanie właśnie zostało wydane po polsku. Szkoda tylko, że ma w polskim wydaniu mylący tytuł sugerujący, że to tylko jakiś zestaw 400 przykładów. Książkę się dosyć dobrze czyta. Lepiej niż PickAxe. Tą pierwszą trochę traktuję jak podręcznik do bibliotek Rubiego.

Co ciekawe, dostało się też trochę książce Agile :) Ale generalnie dużo nie ma co się przyczepić. Książka jest raczej dobrze napisana, szkoda tylko, że opisuje starsze Rails 1.2 a nie 2.0. No cóż, nie wiadomo czy wyjdzie trzecie wydanie, bo DHH jakoś się do niego nie pali.

Z ciekawości sprawdziłem inną książkę, polecaną przez Zeda, The Rails Way. Faktycznie wygląda na dobrze napisaną i uwzględnia nowsze cechy Railsów. Jest dostępna online (choć nie za darmo) przez O’Reilly Safari Books Online (tak w ogóle to świetny serwis, który warto sobie zaprenumerować).

Rubinius, JRuby i Jubinius

Zed się wkurzył, nabluzgał, ale zwrócił uwagę na kilka ważnych kwestii. Także odnośnie samego Rubiego to pochwała dostała się JRuby i Rubiniusowi. Szczególnie ten drugi może wkrótce kompletnie zagrozić dominacji MRI jaki jest używany w dzisiejszej, opartej na C, implemementacji Rubiego. Jeśli szybko nie powstanie kompletnie ukończony YARV (włączony do Ruby 1.9), to Rubinius zwycięży. Temat Rubiniusa jest on tematem naszych dyskusji na kanale IRC #rubyonrails.pl. Podejście jest tu trochę podobne do pythonowego PyPy, choć Rubinius nawiązuje bardziej do 30 lat doświadczeń Smalltalka. Celem jest stworzenie najszybszej wirtualnej maszyny Rubiego oraz łatwego i szybkiego rozwoju dla samego Rubiego. Dzięki temu, że mamy tu do czynienia z Ruby którego implementacja napisana jest w Ruby, znacznie łatwiej jest rozwijać język.

Co ciekawe, autorzy JRuby zastanawiają się czy nie zrobić podobnie. I już są dyskusję o tym aby stworzyć analogicznie Jubiniusa. Tak jak Rubinius w łatwy sposób wciąga biblioteki napisane w C, Jubinius wciągałby te napisane w Javie. Jubinius miałby dodatkowo o tyle wygodniejszą sytuację, że implementacja całej biblioteki standardowej Rubiego jest już przepisana do Rubiego. Jubinius mógłby z marszu wykorzystać ten kod.

Szybszy, asynchroniczny Mongrel z EventMachine lub Swiftiply

Jarosław Zabiełło — Mon, 24 Dec 2007 14:21:00 +0100

Dużo się zmieniło od czasu zalecania używania Railsów w trybie FastCGI. To się nie sprawdziło i miejsce zestawu Lighttpd + FastCGI zajął Apache2/Nginx + proxy do Mongrel clustera. Z Mongrel clusterem jest jednak problem, że nie działa poza systemami uniksowymi. Poza tym udało mi się zaobserwować kilka razy pewną niestabilność dla mongrel clustera: czasami pojedynczy Mongrel się zawiesi i trzeba restartować cały ich klaster. Większą stabilność i dużo większą wydajność (szczególnie przy wielu równoległych żądaniach) zapewniać Mongrel działający z Swiftiply lub z EventMachine.

Swiftiply

Swiftiply jest reklamowany jako klasterowy proxy dla aplikacji internetowych. Korzysta z trwałych połączeń z klientami i można go skalować bez zmian w konfiguracji i restartów. Po prostu podpina się kolejny Mongrel z kolejnego komputera do tego samego adresu IP i zostaje automatycznie włączony do pętli obsługi zdarzeń. Dzięki Ezrze Zygmuntowiczowi, gem Swiftiply udostępnia też gotowy, przerobiony Mongrel działający zarówno z Swiftiply jak i EventMachine. Sam serwer Swiftiply może działać w ogóle bez zewnętrznego serwera HTTP, ale ci co cenią sobie max. wydajność pewnie i tak będą chcieli na froncie postawić szybkiego Nginxa. Wystarczy spiąć go przez mod_proxy do jednego (sic!) Mongrela odpalonego w trybie Swiftiply.

EventMachine

EventMachine to biblioteka napisana w C dla programów Rubiego, Javy i C++. Służy do obsługi zdarzeń w sposób asynchroniczny zamiast wielowątkowy (podobnie jak to robi pythonowy Twisted). EventMachine jest biblioteką bardzo szybką. Serwer pracujący asynchronicznie nie wpada w blokady i jest często szybszy od serwerów pracujących wielowątkowo.

Zamiast tworzyć wiele procesów Mongrela aby zapewnić równoległą pracę dla Rails, wystarczy odpalić jeden (sic!) proces Mongrela asynchronicznego. Asynchroniczny Mongrel działa zarówno z Railsami jaki Merbem. Nie muszę mówić, jakie są oszczędności na pamięci w porównaniu do klastra procesów Mongrela który zwykle zaleca się używać dla Railsów! Z prostych testów porównawczych wyszło mi że Mongrel asynchroniczny jest jakieś dwa razy szybszy od Mongrela wielowątkowego. (Zobacz też Mongrel vs Evented Mongrel)

Jak to skonfigurować?

Po zainstalowaniu gemu Swiftiply stary skrypt mongrel_rails zostaje zastąpiony nowszym (ale tak, że jest zgodny ze starym mongrelem wielowątkowym). Sterowanie trybem pracy dokonywane jest przez ustawienie stosownej zmiennej środowiskowej. Np. aby odpalić Mongrela w trybie asynchronicznym wystarczy napisać

EVENT=1 mongrel_rails start

Poniżej prosty skrypt startujący jaki napisałem dla Ubuntu (wszystkie opcje wyświetli polecenie mongrel_rails start -h@)

#!/usr/bin/ruby

ADDR='127.0.0.1' 
PORT=7100
# Ścieżka do projektu RoR:
ROOT='/home/app/rails/homepage/current'

PID="#{ROOT}/log/blog.pid"
USER='www-data'
GROUP='www-data'
APPL='/usr/bin/mongrel_rails'
cmd_start = "env EVENT=1 #{APPL} start -a #{ADDR} -p #{PORT} --user #{USER} --group #{GROUP} -P #{PID} -e production -d" 
cmd_stop = "#{APPL} stop -P #{PID}"

curdir = Dir.pwd
Dir.chdir ROOT

case ARGV.first
when 'start'
  system cmd_start
when 'stop'
  system cmd_stop if File.exists?(PID)
when 'restart'
  system cmd_stop if File.exists?(PID)
  system cmd_start
else
  puts "Usage: sudo #{__FILE__} {start|stop|restart}"
end
Dir.chdir curdir

Jeszcze tylko komenda

cd /etc/init.d
update-rc.d -f mogrel_home.rb defaults

i Ubuntu będzie automatycznie ten skrypt uruchamiał podczas restartu maszyny.

Odnośnie Nginxa to nie trzeba wiele zmieniać poza tym, aby skierować proxy na jeden port (w tym wypadku 7100)

upstream mongrel_blog {
  server 127.0.0.1:7100;
}

server {
  # ... inne opcje
  location / {
    proxy_set_header  X-Real-IP  $remote_addr;
    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_redirect false;
    # ... reszta opcji
    if (!-f $request_filename) {
      proxy_pass http://mongrel_blog;
      break;
    }
  }
}

Stary mongrel_cluster doczekał się konkurencji w postaci gema mongrel_cow_cluster który również powinien szybciej działać od mongrel_cluster’a. Nawet zwolennicy Webricka mogą sobie doinstalować coś szybszego od domyślnego Webricka – forkowy webrick-high-performance (tylko systemy uniksowe). Ale wydaje mi się, że najlepszym rozwiązaniem jest Mongrel asynchroniczny.

Zobacz też entuzjastyczną opinię Ezry Zygmuntowicza o event Mongrelu i o Swiftiply.

Uniksowy skrypt /etc/init.d w Ruby

Jarosław Zabiełło — Fri, 29 Sep 2006 14:04:00 +0200

Ruby całkiem dobrze nadaje się do pisania skryptów systemowych. W sumie nie wiem dlaczego do tej pory pisałem skrypty tego typu w uniksowym bash’u. :)

#!/usr/bin/env ruby

MONGREL = "/usr/bin/mongrel_rails"
PROJECT = "/home/httpd/somedomain.com/rails_project"

def execute(action, project)
  Dir.chdir(project)
  print "#{MONGREL} #{action}..."
  $defout.flush # unbuffered output
  `#{MONGREL} cluster::#{action}`
  puts 'done'
end

case ARGV.first
  when 'start': execute 'start', PROJECT
  when 'stop': execute 'stop', PROJECT
  when 'restart': execute 'restart', PROJECT
end

unless %w{start stop restart}.include? ARGV.first
  puts "Usage: sudo #{__FILE__} {start|stop|restart}"
  exit
end