RunRails-Blog

Passenger aka mod_rails

Letzten Donnerstag wurde das lang erwartete Apache-Modul für Rails-Anwendungen mit dem Namen Passenger erstmals veröffentlicht. Die Installation von Rails-Anwendungen unter Apache wird damit stark vereinfacht: mod_rails einbinden und das public-Verzeichnis einer Rails-Anwendung als DocumentRoot für Apache angeben, schon wird die Anwendung dort gestartet.

Umständliches Aufsetzen eines Mongrel-Clusters mit Proxy-Balancer ist nicht mehr nötig. Gleichzeitig kann Passenger die Zahl der Server-Instanzen je nach Auslastung dynamisch anpassen. Nett ist auch die automatische Zuweisung der Benutzerrechte für Shared-Hosting-Umgebungen: Der Server-Prozess läuft unter dem Besitzer der Datei config/environment.rb der entsprechenden Rails-Anwendung.

Performance

Dieser Vergleich zwischen Passenger und Mongrel zeigt, dass sich Passenger zumindest auf gleichem Niveau von Mongrel befindet (bei der typo-Anwendung ist es sogar erheblich schneller). In Sachen Speicherverbrauch gibt es aber auch eine Kehrseite, wie die Erfahrungen von HostingRails.com zeigen. Kurz gesagt verdreifacht sich der Speicherverbrauch im Vergleich zu einer Mongrel-Instanz.

Allerdings haben die Macher von Passenger noch die Ruby Enterprise Edition (eine modifizierte Ruby-VM mit verbesserter Garbage Collection) in Vorbereitung, die zufälligerweise den Speicherverbrauch um ein Drittel reduzieren soll, was also auf +/-0 rauslaufen würde :-).

Ähnlich wie beim Betrieb über FCGI beendet Passenger auch den Server-Prozess wenn innerhalb eines bestimmten Zeitraums keine HTTP-Anfragen mehr kommen (Voreinstellung sind 120s). Das spart einerseits eine Menge Speicher wenn auf dem Server viele kleine Anwendungen laufen, die wenig Traffic generieren. Andererseits benötigt der erste Seitenaufruf nach diesem Zeitintervall aber einige Sekunden da dann erst das Rails-Framework “gebootet” werden muss.

Ausblick

Bedeutet Passenger das Ende für spezielle Rails-Hosting-Angebote wie RunRails.de? Meiner Einschätzung nach wird Passenger auf jedenfall die Verbreitung von Rails-Hosting auch bei anderen Shared-Hostern fördern, da der Einsatz so einfach ist. So bald viele Kunden diese Möglichkeit auch Ausnutzen, könnte allerdings der immense Speicherverbrauch des Railsframeworks Probleme bereiten.

Trotzdem - RunRails.de wird nicht mit äußerst günstigen Shared-Hosting angeboten die Rails nur als Beigabe anbieten konkurrieren können. Daher wird es sich Rails-spezifischen Zusatzleistungen von der Masse abheben müssen. Neben den optionalen Subversion-Repositories habe ich noch ein paar weitere Features in Vorbereitung, die den Alltag beim Rails-Deployment erheblich vereinfachen werden (dazu später mehr).

RunRails.de läuft seit gestern bereits mit Passenger. Allerdings sind die oben beschriebenen “Boot”-Zeiten der Anwendung störend, und den Speicherverbrauch werde ich auch nochmal im Auge behalten müssen. Für Mongrel hat also noch nicht das letzte Stündlein geschlagen!