Szalejące frameworki Rubiego i Rack/WSGI

Jarosław Zabiełło — Tue, 04 Mar 2008 22:56:00 +0100

Merb w wersji 0.9 poszedł na całość i oparli swój midleware na Rack’u. Jej twórcy nie kryją się że wzorowali się na pythonowej bibliotece WSGI. Biblioteka ta robi niezłą furorę w kręgach Rubiego. Powstaje sporo różnych mikroframeworków lub szybkich serwerów HTTP pracujących asynchronicznie i wykorzystujących Rack. Niedawno powstał świetny Thin, a już można przeczytać o 2x szybszy Ebb. Co ciekawe, Ebb chce docelowo obsługiwać zarówno frameworki Rubiego jak i Pythona! Jestem ciekaw czy będzie w stanie zdetronizować serwer Paste... Rack doczekał się już swojej implementacji w JRuby! Umożliwia to tym samym odpalanie w JRuby wszystkich frameworków które korzystają z Rack’a.

Frameworki

Rails – najważniejszy framework Rubiego, może być odpalany za pomocą Thina który używa Rack. Rails można odpalić na JRuby nawet prosto z Netbeans 6 :)
Merb – pretendent do detronizacji Rails, _używa Rack_i tym samym można go odpalić na JRuby.
Ramaze – podobnie do Merba, stara się promować bardziek elastyczne podejście, używa Rack, raczej nie zagrozi Merbowi
Fuzed – Rails z YAWS (szybkim serwerem HTTP napisanym w Erlangu)
Nitro – typu MVC z własnym ORM – Ogg i naciskiem na AJAX
IOWA – komponentowy,
Wee wzorowany na smalltalkowym Seaside używającym kontynuacji
Sinatra – mikroframework wzorowany na minimalistycznym, pythonowym Web.py
Camping – kolejny mikroframework w Ruby
Wave – wzorowany na Camping, też używa Rack i Rubiego wszędzie gdzie się da.
Invisible mikroframework używający Rack napisany w 35 linijkach kodu Rubiego (bardziej ciekawostka)

Mongrel i spółka

Webrick – serwer http dostępny razem ze standardową biblioteką Rubiego
Highperformance Webrick – szybsza wersja Webricka (używająca uniksowych forków)
Mongrel – klasyka, napisany częściowo w C, to od niego zaczęła się rewolucja i odejście od FastCGI jako metody odpalania Railsów.
Swiftyply i evented_mongrel asychroniczne, szybsze wersje Mongrela
Thin – asynchroniczny web server używający Mongrela i Rack
Ebb – używa Rack, większość kodu jest w C, dlatego jest taki szybki, na razie mało dokumentacji, być może następca Thin

Thin, unix sockets, Rails i Merb

Jarosław Zabiełło — Mon, 03 Mar 2008 03:36:00 +0100

Thin to szybki serwer HTTP służący do uruchamiania webowych frameworków napisanych w języku Ruby. Najbardziej z nich popularny jest oczywiście Rails. Choć istnieje wiele sposobów uruchomienia Railsów na serwerze produkcyjnym, użycie Thin wydaje się aktualnie najlepszym rozwiązaniem z przynajmniej dwóch powodów: zajmuje mniej pamięci i jest szybszy od popularnego Mongrela. Thin wykorzystuje dwa bardzo szybkie moduły: Mongel parser, Event Machine oraz (wzorowaną na pythonowym WSGI) bibliotekę Rack.

Od jakiegoś czasu Thin udostępnia uruchamianie klastra procesów wykorzystujący szybsze od TCP, sockety uniksowe. Zaletą jest nie tylko większa szybkość pracy, ale także odpada problem rezerwacji odpowiedniej liczby portów TCP.

Wygenerowanie pliku konfiguracyjnego polega na uruchomieniu w katalogu z projektem Rails (lub Merb) komendy:

thin config -C config/thin.yml -s4 -e production \
  --socket /tmp/thin_myapp.sock

Zostanie wygenerowany plik konfiguracyjny o mniej więcej takiej treści:

--- 
pid: tmp/pids/thin.pid
socket: /tmp/thin_myapp.sock
log: log/thin.log
max_conns: 1024
timeout: 30
chdir: /home/app/rails/myapp
environment: production
max_persistent_conns: 512
servers: 4
daemonize: true

Opcja -s4 oznacza że chcemy użyć 4 procesy. (W wypadku Nginksa, trzeba uważać na opcję max_persistent_conns, bo Nginx zdaje się nie ma jeszcze zaimplementowanej obsługi persistent connections. Najlepiej ją wyłączyć, tzn. przypisać jej wartość równą zeru. Apache powinien to obsługiwać. Z persistent connections wszystko powinno działać trochę szybciej.)

Aby to uruchomić, warto stworzyć plik startowy. Dla Debiana/Ubuntu należy stworzyć plik /etc/init.d/thin.rb (dla wygody napisalem to w Ruby zamiast Bashu):

#!/usr/bin/env ruby

require 'fileutils'
include FileUtils

def pids
  Dir.glob('tmp/pids/thin*.pid').map do |entry| 
    File.open(entry).read
  end
end

def start
  if pids.empty?
    rm_f "tmp/pids/thin*.pid"
    if File.exists? "config/init.rb" # start Merb
      system "thin start -r config.ru -C config/thin.yml"
    else # start Rails
      system "thin start -C config/thin.yml"
    end
  else
    puts "Thin cluster is already working"
  end
end

def stop
  if pids.empty?
    puts "Thin cluster is not working"
  else
    puts "Stopping thin cluster" unless pids.empty?
    pids.each {|pid| system "kill -TERM #{pid}" }
    rm_f "tmp/pids/thin*.pid"
  end
end

def restart
  stop
  sleep 1
  start
end

def status
  if pids.empty?
    puts "Thin cluster is not working"
  else
    puts "Thin cluster is working (pids: #{pids.join ', '})"
  end
end

if __FILE__ == $0
  opts = %w(start stop restart status)
  if opts.include?(ARGV[0]) and File.exists?(ARGV[1])
    Dir.chdir ARGV[1]
    eval ARGV[0]
  else
    print "Syntax: ruby {#{File.basename($0)} <#{opts.join '|'}}"
    puts  " /path/to/rails_or_merb/project"
  end
end

Należy dodać uprawnienia (sudo chmod a+x thin.rb) i ustawić aby domyślnie, podczas uruchomienia całego serwera był uruchamiany następujący skrypt (thin_myapp.rb) dla konkretnego projektu Rails lub Merb (komenda sudo update-rc.d -f thin_myapp.rb defaults).

#!/usr/bin/env ruby
path = '/path/to/rails-or-merb/project'

opts = %w(start stop restart status)
if opts.include? ARGV[0]
  system "/etc/init.d/thin.rb #{ARGV[0]} #{path}"
else
  puts "Syntax: #{File.basename(__FILE__)} {#{opts.join '|'}}"
end

W wypadku Merba trzeba pamiętać aby stworzyć dodatkowy plik konfiguracyjny config.ru (oczywiście dotyczy to Merba 0.9 lub nowszego):

# config.ru
Merb::BootLoader.run
run Merb::Rack::Application.new

Wyżej podany plik startowy rozpoznaje czy projekt to Rails czy Merb na podstawie odnalezienia pliku config/init.rb. Ale jak ktoś chce odpalać to ręcznie to Merba korzystającego z Thina i jego plikiu konfiguracyjnego (config/thin.yml) odpala się w taki sposób:

thin start -r config.ru -C config/thin.yml

Teraz wystarczy tylko ustawić load balancing do tak uruchomionego serwera. Dla serwera Nginx będzie to

upstream thin_myapp {
  server unix:/tmp/thin_myapp.0.sock;
  server unix:/tmp/thin_myapp.1.sock;
  server unix:/tmp/thin_myapp.2.sock;
  server unix:/tmp/thin_myapp.3.sock;
}

I w definicji serwera wirtualnego:

if (!-f $request_filename) {
  proxy_pass http://thin_myapp;
  break;
}

Zobacz też:

Update 2008-03-04:

Poprawiłem skrypt startowy tak aby był bardziej uniwersalny w wypadku używania wielu projektów Rails (lub Merb). Dodałem też informacje o możliwym problemie ze zmienną max_persistent_conns w wypadku Nginksa.

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

Szalejące frameworki Rubiego i Rack/WSGI

Frameworki

Mongrel i spółka

Thin, unix sockets, Rails i Merb