Ruby Application Server WebROaR Review

Für den Betrieb von Rails bzw. Ruby Web-Applications bieten sich derzeit schon zahlreiche Möglichkeiten. Neben den Balancer-Setups mit Nginx oder Apache, Rack-Servern wie Mongrel, Thin oder Unicorn und den JRuby Setups mit Tomcat oder Glasfish hat Taktsoft im Rahmen von Kundenprojekten mit dem Phusion Passenger gute Erfahrungen gemacht.

Nun wurde mit WebROaR der erste Server für das Ruby-Ökosystem veröffentlicht, der den Anspruch hat ein vollwertiger Application Server zu sein. Die Ziele des Projekts hören sich interessant an:

  • Maximum performance.
  • Simplified deployment.
  • Runs Ruby on Rails(TM) as well as other Rack compliant applications.
  • Run multiple applications simultaneously.
  • Implements HTTP/1.1 grammar as per RFC 2616 including support for persistent, and chunked requests.
  • Intelligent load balancing and dynamic reaping of stuck ruby processing instances.
  • Provides run time performance data for the deployed applications.
  • Generates notifications in case any exceptions occur in any of the deployed applications.
  • SSL support.

Das Ziel der "Maximum Performance" wird vom Projekt auch gleich mit recht eindrucksvollen Benchmarks belegt. Obwohl WebROaR aktuell die Versionsnummer 0.2.4 trägt, also noch im Beta-Stadium steckt, sind die oben genannten Projekt-Ziele Grund genug sich WebROaR etwas genauer anzuschauen.

Installation (auf Ubuntu 9.10)

Die Installation erfolgt entweder mittels Rubygems oder via git. Beide Varianten sind mehr oder minder ausführlich im User-Guide beschrieben. Ich habe mich für die Installation aus den Quellen entschieden, daher wird als erstes das Projekt von Github ausgecheckt:

git clone git://github.com/webroar/webroar.git

Anschließend wird sichergestellt dass alle nötigen Dependencies, sowohl auf OS- als auch auf Ruby-Ebene installiert sind:

sudo apt-get install libopenssl-ruby1.8 libzlib-ruby1.8 libsqlite3-dev libsqlite3-0 \
gnutls gnutls-dev build-essential ruby1.8 ruby1.8-dev
sudo gem install gem install -v=2.3.2 rails
sudo gem install calendar_date_select, rack, rake, rspec, sqlite3-ruby, \
starling-starling

Leider ist es mir nicht gelungen die Testsuite erfolgreich durchzuführen. Daher wird WebROaR ungetestet installiert:

sudo rake install

Der Installationstask erfragt dann die Zugangsdaten für das Admin-Panel und den Port unter dem der Server erreicht werden soll. Wird der vorgeschlagene Port 3000 verwendet ist der Server unter http://localhost:3000/ zu erreichen.

Zudem stehen auf dem Kommandozeile das webroar-Kommando zur Verfügung. Dies erlaubt das Starten, Stoppen und Restarten des Application Servers sowie einzelner Web-Applikationen. Eine komplette Übersicht über die möglichen Kommandos liefert webroar help commands.

Konfiguration

Die Konfiguration und das Deployment von Anwendungen wird über das Admin-Panel erledigt, das unter http://localhost:3000/admin-panel erreichbar ist.

Nach dem Login wird das Home-Tab des Servers angezeigt. Dort sind einerseits Kennzahlen wie CPU-Auslastung und Speicherverbrauch des Application Servers zu finden, anderseits finden sich hier die Kennzahlen für die deployten Web Apps.

Um neue Web Apps zu deployen öffnet man das Configuration-Tab wählt "Add Application":

Webroar Configuration

Für die neue Web App müssen verschiedene Werte wie beispielsweise Name der Web App und das Environment konfiguriert werden. Besondere Aufmerksamkeit genießen hierbei der Resolver und Analytics.
Der Resolver konfiguriert, welche URL-Patterns dieser Anwendung zugeordnet sind und ermöglicht somit die Verwendung bestimmter Domains, Subdomains oder Sub-Uris für die Anwendung.

Im Vergleich zu obskuren Mod-Rewrite-Regeln oder der RailsBaseUri-Direktive von Passenger wird einem die Verwendung von Sub-Uris hier wirklich einfach gemacht.
Analytics legt fest, ob die in WebROaR integrierten Performanz-Analysen für die Anwendung aktiviert werden sollen. Das reduziert wahrscheinlich die Performanz der Anwendung etwas, liefert dafür aber hilfreiche Informationen. Dazu aber später mehr.
Die restlichen Optionen sind eigentlich selbsterklärend:

Webroar Configuration Optionen

Im Anschluss sieht man die neue Applikation im Configuration-Tab:

Webroar Configuration neue Applikation

Damit ist die erste Web App deployt und kann genutzt werden.

Logging und Analyse

Ein wirkliches Highlight von WebROaR sind die eingebauten Logging- und Analyse-Funktionen welche die Beurteilung der Application Health und der Application Performance bzw. der Identifikation von Performance-Bottlenecks deutlich zugänglicher gestalten.

Die Logging-Funktion beschränkt sich derzeit auf die Protokollierung von Exceptions - was für sich genommen, schon einen echten Fortschritt darstellt im Vergleich zur Nutzung von Plugins wie Exception-Notification. WebROaR zeigt im Home-Tab für jede Anwendung, ob neue Exceptions registriert wurden.

Webroar Logging Funktion

Diese Exceptions können dann als Liste angezeigt werden. Über die Liste können für jede Exception zusätzliche Informationen wie z.B. einen ausführlichen Stack-Trace im Detail betrachtet werden oder in den Zustand "closed" bzw. "ignore" versetzt werden.

Webroar Exceptions

Für die Zukunft interessant wären hier wohl automatische Filter für bestimmte Exceptions, so dass bestimmte Exceptions direkt in den Zustand ignore versetzt werden können. Das wäre beispielsweise für RoutingsErrors von Vorteil, da diese auch durch Web-Crawler o.ä. erzeugt werden und nicht zwangsläufig auf ein Problem in der Anwendung hinweisen.

Die Analyse-Funktion ermöglicht für jede Anwendung bei der diese Funktion aktiviert ist die Auswertung Performance-relevanter Kennzahlen. Dazu gehört beispielsweise CPU- und Speichernutzung über einen bestimmten Zeitraum oder die Identifikation der langsamsten Actions.

Webroar Analytics CPU Auslastung Webroar Analytics Time Consuming

Auf Ebene einer Action lässt sich dann beispielsweise analysieren worauf die meiste Zeit verwendet wurde.

Webroar Analytics

Deployment

Wer bisher mit Capistrano deployt kann dies auch weiterhin tun, auch wenn beim intialen Deployment wahrscheinlich WebROaR über das Admin-Panel konfiguriert werden muss. Alle weiteren Deployments können dann wie gewohnt mit Capistrano erfolgen, nur dass im Anschluss nicht Passenger neu gestartet werden sondern eben die deployte Web-App im WebROaR-Server. Dazu könnte beispielsweise folgendes (ungetestete) Recipe verwendet werden:

#############################################################
#	WebROaR
#############################################################
namespace :webroar do
  desc "Restart Application"
  task :restart do
    sudo "webroar restart #{application}"
  end
end

after :deploy, "webroar:restart"

Performanz

Erste Performanz-Tests die ich durchgeführt habe bestätigen die Benchmark-Ergebnisse der WebROaR-Entwickler. Da mein verwendetes Test-Setup allerdings nicht ganz optimal war (Test-Client httperf und Server liefen auf dem gleichen System), möchte ich an dieser Stelle keine definitive Aussage zur Performanz treffen.

Fazit

Insgesamt hinterlässt WebROaR einen wirklich viel versprechenden Eindruck. Puristen mögen bemängeln dass es bereits sehr schlanke und ausgereifte Server für Ruby bzw. Rails gibt und auch die Logging- und Analyse-Funktion besser über 3rd-Party Tools wie beispielsweise New Relic realisiert werden sollten. Doch gerade da der Server ersten Tests zufolge wirklich sehr schnell ist und die Zusatzfunktionen quasi umsonst mitbringt könnte, er sich zur ernstzunehmenden Alternative zu Passenger und Konsorten entwickeln.

 

Feedback oder Fragen? Über Kommentare oder E-Mails zum Thema würde ich mich freuen.


Zur Blog-Übersicht