Ruby on Rails hosting

18 mei 2007, 15:34

In dit artikel beschrijf ik de verschillende manieren om een Ruby on Rails project te hosten: de verschillende servers (Webrick, Apache, Lighttpd, Mongrel, Nginx, …), maar vooral de verschillende manieren van het omgaan met requests (CGI, FastCGI, HTTP, …).

Webrick is de meest voor de hand liggende keuze als je aan een project begint. Doordat deze server sinds versie 1.8.0 standaard bij Ruby geleverd wordt, hoef je niets extras te installeren. Bovendien is Webrick enorm makkelijk te gebruiken. Nadelen van Webrick zijn de tragere snelheid en de beperkte schaalbaarheid. Webrick is dus aan te raden tijdens het ontwikkelen, maar af te raden wanneer je een project voor het grote publiek toegankelijk wil maken.

Na Webrick is Apache een logische keuze. Sinds April 1996 is dit de populairste webserver op het internet, dus waarom zou je hem niet gebruiken om je Rails project te hosten? CGI is het antwoord op deze vraag. Apache werkt standaard in CGI mode, waardoor Rails projecten er erg traag op draaien.

Om dit te begrijpen moet ik kort de manier van werken van CGI uitleggen. Deze is gebaseerd op korte processen (VERGETEN). Telkens de server een request ontvangt, start hij de Ruby interpreter (dit is nodig omdat de server anders geen Ruby ‘begrijpt’), vervolgens moet hij het volledige Rails framework laden. Dit alles is nodig om één enkele request te kunnen behandelen. Wanneer dit gebeurd is, stopt het (korte) proces. Dit betekent dat bij een volgende request een nieuw proces gestart moet worden, en alle stappen opnieuw doorlopen moeten worden. We spreken telkens over enkele seconden wachttijd, wat onaanvaardbaar is.

Dit is echter geen reden om Apache meteen af te schrijven. Er bestaan namelijk Apache modules. Deze maken het mogelijk om Apache met extra functionaliteiten uit te breiden. In ons geval zijn we geïnteresseerd in FastCGI (verkrijgbaar voor Apache 1.3.x als mod_fastcgi en voor Apache2.x als mod_fcgid).
FastCGI versnelt Rails enorm. Het staat ongeveer loodrecht op CGI. Het is gebaseerd op lange processen (ONTHOUDEN). Dat betekent concreet dat de Ruby interpreter en het Rails framework slechts één keer (bij het opstarten) geladen worden. Zelfs database verbindingen moeten maar één keer (bij de eerste query) gelegd worden, en worden daarna gedurende het hele (langlopende) proces in stand gehouden. Bij een request moet dus uitsluitend het hoogstnodige werk geleverd worden om hem te verwerken.

Klinkt goed, niet? Het nadeel zit hem in de extra complexiteit die bij het aan de praat krijgen van FastCGI komt kijken. Bovendien, maar dat zag je al aankomen, vereist dit “onthouden” extra processor en RAM kracht, waardoor gedeelde hosting omgevingen (shared hosting) minder interessant worden (omdat je de processor en het RAM geheugen met een groot aantal andere gebruikers moet delen).

Een eenvoudigere manier om gelijkaardige prestaties te bekomen is Mongrel. Mongrel is ongeveer even snel (een fractie trager om precies te zijn) als FastCGI, maar veel makkelijker in gebruik (vergelijkbaar met Webrick) en stabieler. Mongrel is dan ook dé manier om een Ruby on Rails project te hosten.
Mongrel is een Webserver die (in plaats van CGI of FastCGI) HTTP gebruikt. Bij deze manier van werken wordt Rails, net als bij FastCGI, enkel bij het opstarten geladen.

Je kan Mongrel als standalone server gebruiken (net als Webrick, handig tijdens het ontwikkelen), maar hier is één nadeel aan verbonden: Mongrel is traag in het omgaan met statische requests (het serveren van afbeeldingen, css, javascript, …).
Daarom gaat het productie gebruik als volgt: een ‘normale’ webserver (zoals Apache) wordt als proxy server (het gaat hier weer om een uitbreiding van Apache: mod_proxy) voor één of meerdere Mongrel servers geplaatst.
Dit proxy server zijn houdt in dat Apache zelf alle statische requests (het opvragen van afbeeldingen, css, javascript) beantwoord, maar dat het de dynamische requests (Ruby on Rails) doorstuurt naar de achterliggende Mongrel servers. Je krijgt dus het beste van twee werelden: Apache gaat snel om met de statische requests, Mongrel met de dynamische. Bovendien is deze opstelling makkelijk uit te breiden. Extra Mongrel servers kunnen steeds achter de Apache server geplaatst worden.

Apache + Mongrel

Nu de manier van werken duidelijk is, kan je dezelfde gedachtegang op verschillende servers toepassen:
Lighttpd is een server die enorm snel met statische requests omgaat, maar ook een actieve ontwikkeling op het gebied van FastCGI kent. Bovendien ken Lighttpd ingebouwde load balancing, waardoor één Lighttpd server de statische content kan leveren en de dynamische request kan doorsturen naar achtergelegen servers die enkel FastCGI processen draaien. Deze eerste processor delegeert de dynamische requests dus naar achtergelegen machines, maar houdt ze ook in het oog, ontlast ze bij problemen, … Ook bij Lighttpd zit het nadeel hem weer in stabiliteitsproblemen.

Een laatste mogelijkheid, die wel eens opduikt in het Rails wereldje, is het gebruik van Nginx. Deze HTTP server van Russische makelij, kan net als Apache voor één of meerdere Mongrel servers geplaatst worden. Ook hier: Nginx neemt dan de statische requests voor z’n rekening, Mongrel de dynamische. Bijkomend voordeel van Nginx is dat de ontwikkelaars zich bewust zijn van de aandacht vanuit de Ruby on Rails hoek, en de verdere ontwikkeling van hun product hier deels op afstemmen.

Besluit: Kies voor een webserver (Apache, Lighttpd of Nginx) die goed omkan met statische requests en plaats hierachter één of meerder Mongrel servers. Hoe meer processor kracht en RAM geheugen, hoe beter. Shared hosting is dus te vermijden. Er wordt wel eens gezegd dat shared hosting enkel nuttig is voor blogs.

Tenslotte kan deze screencast/video tutorial van de San Diego Ruby users Group de zaken eventueel nog wat verduidelijken…

Ook nog even vermelden dat ik op het Ruby forum heel wat hulp kreeg…

Update: Ik nam contact op met de mensen van rackhost.be, openminds.be, servernation.nl, cj2hosting.nl, jronline.nl, superior.nl, prioserve.net, byte.nl … Zij bieden allen Rails hosting aan in België/Nederland. Wie weet hebben ze opmerkingen op dit artikel, of kunnen ze meer vertellen over hun hostingpaketten… De commentaren staan open. Ik ben benieuwd naar de reacties. Als de reacties de moeite zijn, zal ik er eventueel een apart artikel aan wijden.


Reacties

  1. Ik deel je conclusies, we hebben bij Servernation (http://www.servernation.nl) een apache/cgi setup met suexec (waardoor processen onder de userid van de klant draaien voor wat extra security).

    Rails was hiermee niet vooruit te branden. Leuk voor kleine experimentjes, maar meer niet.

    Het combineren van fastcgi, suexec, Apache, Rails en PHP bleek nogal een gedrocht van een server op te leveren.

    Dus hebben we aparte servers ingericht voor Rails hosting. Hier draait Apache op met mod_proxy, en daar achter mongrel.

    We ontwikkelen onze eigen Rails software veelal onder Mac OS X met Locomotive, de snelheid die de Rails servers halen ‘voelt’ ongeveer hetzelfde als wat de development machines laten zien.

    Da’s een groot voordeel als je je applicaties aan klanten laat zien.

    Kosten zijn bij de meeste hostingproviders niet zo bijster interessant meer, zelden ben je meer dan een tientje per maand kwijt en dat is ook bij servernation het geval.

    Het voordeel is wel dat we zelf in Rails developen en daardoor goed begrijpen wat er komt kijken.

    Natuurlijk is het mooiste kwa performance een dedicated server die je inricht naar je eigen behoeften. Nadeel is weer dat je vaak je eigen systeembeheer moet doen, en je uiteindelijk 1 server hebt, daar waar de shared hosting platformen van de diverse webhosting providers vaak meer redundancy bevatten (hoewel je dan wel beter de providers met ‘een servertje in Amsterdam’ kunt vermijden).

    De afweging tussen performance, veiligheid en gemak is er dan ook een die je eigenlijk per gehost project moet afwegen.


    Roger Heykoop (servernation) 19 mei 2007, 23:18

  2. Met veel plezier hebben we uw artikel gelezen. Een zeer goed overzicht van alle populaire mogelijkheden, en grondig en goed uit de doeken gedaan, zonder teveel verloren te lopen in technische aspecten.

    Enkele opmerkingen; een eerste is het volgende: Mongrel vervangt niet (Fast)CGI, maar Apache. (Fast)CGI is enkel het doorgeven van de aanvraag naar het ruby-proces. Op zich is Mongrel een ruby container, net zoals bv. Tomcat/Catalina dit is voor Java.

    Zelf gebruiken we twee opstellingen voor het leveren van Ruby (on Rails). Eerst en vooral gebruiken we Lighttpd in combinatie met FastCGI. Deze opstelling is de populairste, aangezien we deze reeds vanaf dag één ondersteunen, en elke account de mogelijkheid geven dit snel en eenvoudig op te zetten, via scripts die deze omgeving klaarmaken en uitvoeren.

    Een tweede opstelling die we gebruiken is NGINX in combinatie met Mongrel. Deze combinatie testen we reeds enige tijd en gebruiken we reeds in eigen opstellingen. Deze zullen we binnenkort ook beschikbaar maken naar klanten toe, en we de nodige scripts en services voorzien hebben om een account eenvoudig en snel van deze opstelling te voorzien.

    Het verschil tussen beide opstellingen qua load en ramgebruik is minimaal; en het snelheidverschil is ook verwaarloosbaar. Verder onderzoeken we ook het gebruik van Pound, deze heeft echter het nadeel dat deze geen statische content kan serven.

    De conclusie dat je rails beter niet op een shared omgeving laat lopen is deel correct, maar je moet er een kleine nuance aan koppelen. Zo mag je niet langer denken in termen van kleine php/mysql accounts, die niet zoveel load en ram innemen. Je moet zwaardere systemen voorzien, en de kostprijs van een account gaat dus ietsjes de hoogte in, maar het is zeer zeker mogelijk om goed en veilig verschillende rails-accounts naast elkaar op één machine te laten lopen. We doen dit voor al onze railsopstellingen, en dit heeft nog geen enkel probleem gegeven (de servers zijn wel iets meer dan een eenvoudige P4 ;)). Verder is het zelfs mogelijk om de beide te gebruiken (php en ruby). Het grote verschil is natuurlijk wel dat de hoster goed op de hoogte moet zijn van de systemen die hij draait, en de in en outs van ruby, rails en de verschillende webservers moet kennen (niet enkel qua performantie, maar ook bv performantie, redundantie en de technologieën).

    Voor specifieke projecten zijn kleine virtuele dedicated servers, of echte dedicated servers dan weer een andere oplossing. Via de balancing van NGINX of Lighttpd kan deze zeer eenvoudig uitgebreid worden wanneer dit nodig is.

    Verder is het wel duidelijk dat de meerkost voor de hosting van een Rails-project zeer snel terugverdiend kan worden in de besparing op man-uren. Als een account een 100 EUR extra kost per jaar, dan kan je daar een programmeur 1 of 2 uur meer mee betalen. Er zal zeker een groter verschil op de ontwikkeltijd van een project zitten (initiëel of bij aanpassingen later) dan deze 2 uur.

    Zelf ontwikkelen we veel applicaties in Ruby on Rails, en hebben zeer veel kennis hieromtrend in huis. Daardoor kunnen we een heel degelijke Ruby on Rails hostingoplossing aanbieden, en krijgen we veel positieve reacties op de support die we leveren bij de pakketten.


    Bernard Grymonpon 21 mei 2007, 09:59

  3. Ik heb nog meer goed nieuws: wie bij Openminds (http://www.openminds.be) een Pro accountje bestelt met promocode “ONRAILS”, krijgt 1 maand gratis.


    Frank 21 mei 2007, 13:55

  4. Wij als Byte hebben al jarenlange ervaring met high performance hosting, waarbij elke klant op een load balancing cluster draait. Dit biedt naast natuurlijk hoge performance ook erg betrouwbare dienstverlening. Geen enkele klant is afhankelijk van 1 bepaalde server.

    Dit hebben we natuurlijk ook naar onze Rails hosting doorgetrokken. Door gebruik te maken van Apache 2.2 met mod_proxy_balancer heeft elke klant standaard 2 Mongrel instances beschikbaar op 2 fysiek verschillende machines.

    Mochten klant nu meer nodig hebben dan deze twee instances, dan worden er simpelweg weer 2 bij naast gezet. Dit transparante geheel maakt het dus voor de klant erg schaalbaar. Zo kun je alles van een simpele applicatie tot een groot en complex systeem op eenzelfde manier oplossen.

    Op dit moment is een grote klant al een pilot project aan het draaien met hun Rails applicatie. Zij hebben voor Byte gekozen vanwege de technische kennis en ervaring, waardoor Byte een betere oplossing kan aanbieden dat zij in eigen beheer zouden kunnen opzetten. Zo hoeven zij zich niet druk te maken over beheer, monitoring en dat soort zaken.

    Ow ja, en als promotie kun je bij ons gratis een half jaar proberen. Je krijgt dan twee Mongrel instances op twee machines, samen met Capistrano deployment recipes om je applicatie online te gooien! Zie ook de website voor meer informatie over hoe je jezelf kunt aanmelden.


    Byte 21 mei 2007, 16:24

  5. Op www.jronline.nl zwijgt men plots in alle talen over Ruby on Rails. Zouden ze een bad experience hebben opgelopen met RoR ?


    Keybern 9 juli 2007, 12:34

  6. Jullie bespreken hier niet een andere en naar mijn mening beste oplossing. Je kan Ruby draaien als Apache module.

    http://www.modruby.net


    Arnold Daniels 9 oktober 2007, 13:23

  7. Mod_ruby wordt erg slecht bijgehouden en is niet geschikt voor het draaien van meerdere Rails applicaties op een server. Dit komt omdat alle applicaties dezelfde namespace delen. Zie ook dit artikel op de Rails wiki:

    http://wiki.rubyonrails.org/rails/pages/mod_ruby

    Wij gebruiken zelf Apache + Mongrel::cluster.. naar onze mening is dit de snelste en meest stabiele oplossing.


    Martijn (Bluerail.nl) 14 november 2007, 11:03

  8. Ik gebruik zelf uitsluitend Litespeed. Voordeel: de makkelijkste setup van alle webservers, het is één pakket voor zowel statische als dynamische requests. Statische handelt litespeed zelf af, dynamische worden via lsapi aan Ruby doorgespeeld, onder water, je hebt nergens last van. www.litespeedtech.net


    joost baaij 10 juni 2008, 14:43

  9. Inmiddels is Phusion Passenger (mod_rails) de ideale oplossing voor shared Ruby on Rails hosting. We gebruiken het op RailsCluster, het snelste en meest betrouwbare Ruby on Rails hosting platform in Nederland. Het platform is volledig redundant uitgevoerd, twee keer zo snel als andere Ruby on Rails hosts en heeft een beschikbaarheid van 99,8%. Rack applicaties zoals Merb worden ook ondersteund. Last but not least is er een maand gratis proefperiode!


    Roderick van Domburg 1 november 2008, 17:41

Reageer

Naam
Email
Website
Reactie

© 2006-2010 - Johan Van Mol