# \[ANNOUNCE\] Rails Ugly Dispatcher 0.1 **URL:** \ **Category:** IT\ **Created:** [May 20, 2008, 10:09pm UTC](https://www.ruby-forum.com/t/announce-rails-ugly-dispatcher-0-1/138186 "2008-05-20T22:09:26Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Roberto\_De\_Ioris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/50afbb/32.png) [@Roberto\_De\_Ioris](https://www.ruby-forum.com/u/Roberto_De_Ioris)\ **Post date:** [May 20, 2008, 10:09pm UTC](https://www.ruby-forum.com/t/announce-rails-ugly-dispatcher-0-1/138186/1 "2008-05-20T22:09:26Z")
RUgD (Rails Ugly Dispatcher) e’ un webserver ultra-leggero (completamente scritto in C) il cui unico scopo e’ quello di eseguire applicazioni Rails. E’ pensato per la fase di produzione e non per quella di sviluppo, principalmente perche’ non dispone (e mai disporra’) di funzioni per servire file statici. La differenza sostanziale con mongrel/thin (oltre ad essere completamente in c) e’ che usa il modello prefork, quindi N processi saranno in ascolto sulla medesima porta TCP rendendo inutile l’uso di proxy load balancer (se non, ovviamente in caso lanciate piu’ istanze di rugd su macchine diverse). Chi ha esperienza di deploy con mongrel\_cluster sa che rottura di \*@!# sia rimettere mano alla configurazione di apache ogni volta che si aggiungono processi a mongrel\_cluster. E’ ancora in una fase embrionale, ma applicazioni come typo e mephisto girano senza problemi e con performance di tutto rispetto (i primi benchmark blandi che ho fatto lo danno del 20% piu’ rapido di mongrel nel parsing delle richieste, ma e’ tutto relativo visto che il parser http di rugd non e’ ancora a prova di bomba). Il consumo di memoria (esterno al motore ruby) e’ ridottissimo e conto di diminuirlo ulteriormente migliorando i parser HTTP. Nelle prossime revisioni conto di aggiungere un watcher inotify che riavvii in automatico rails quando vengono fatte modifiche ai controller o ai modelli, e un limitatore di utilizzo di memoria per evitare che una app scritta male sdrai tutto il server (questo in realta’ e’ in cima alla lista delle cose da fare) I piu’ tecnici noteranno che l’ambiente ruby vive in un thread POSIX, non preoccupatevi non c’e’ mai passaggio di oggetti tra il thread e il webserver (altrimenti ruby si arrabierebbe di brutto), tutta la comunicazione avviene tramite pipe(). Qui potete scaricare il trunk svn: [http://rugd.unbit.it/](http://rugd.unbit.it/) Purtroppo non ho avuto il tempo di preparare un Makefile decente, quindi dovrete editarlo ed impostare la directory in cui avete gli header di ruby (il default e’ una ubuntu x86-64). Altra nota negativa e’ che per ora il tutto funziona solo sotto linux 2.6, ma conto di portarlo su BSD (incluso OSX) in breve tempo (magari gia’ funziona, non ho provato). Vi invito a testarlo ma non usarlo in ambienti di produzione poiche’ ci sono ancora un paio di bug noiosi e inviando una richiesta http ad hoc si potrebbe generare un deadlock. Buona serata P.S. Ovviamente se qualcuno ha voglia di fare un porting su windows, si faccia pure avanti – Roberto De Ioris [http://unbit.it](http://unbit.it) JID: removed\_email\_address@domain.invalid ---
**Author:** ![Roberto\_De\_Ioris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/50afbb/32.png) [@Roberto\_De\_Ioris](https://www.ruby-forum.com/u/Roberto_De_Ioris)\ **Post date:** [May 20, 2008, 10:24pm UTC](https://www.ruby-forum.com/t/announce-rails-ugly-dispatcher-0-1/138186/2 "2008-05-20T22:24:46Z")
Grande. Il giorno 20/mag/08, alle ore 22:10, Roberto De Ioris ha scritto: ---
**Author:** ![Roberto\_De\_Ioris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/50afbb/32.png) [@Roberto\_De\_Ioris](https://www.ruby-forum.com/u/Roberto_De_Ioris)\ **Post date:** [May 20, 2008, 11:22pm UTC](https://www.ruby-forum.com/t/announce-rails-ugly-dispatcher-0-1/138186/3 "2008-05-20T23:22:28Z")
On mar, 2008-05-20 at 22:59 +0200, David W. wrote: > subito? Un numero fisso di children? > Un numero fisso di children (si specificano con il flag -w) > E com’e` diverso da mod\_fcgid o mod\_rails, al livello pratico (benchmarking?🙂 i benchmark li faro’ quando il sistema sara’ piu’ robusto, in linea teorica non c’e’ speranza di battere fastcgi, ma vista la scarsa popolarita’ (diciamo anche odio) di cui godono i moduli fastcgi opensource per apache ho paura che per il pubblico di programmatori poco avvezzi alle configurazioni “da maschi” non faccia molto testo 🙂 – Roberto De Ioris [http://unbit.it](http://unbit.it) JID: removed\_email\_address@domain.invalid ---
**Author:** ![Roberto\_De\_Ioris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/50afbb/32.png) [@Roberto\_De\_Ioris](https://www.ruby-forum.com/u/Roberto_De_Ioris)\ **Post date:** [May 21, 2008, 9:19am UTC](https://www.ruby-forum.com/t/announce-rails-ugly-dispatcher-0-1/138186/4 "2008-05-21T09:19:28Z")
Molto interessante… complimenti per l’iniziativa! Il 20 maggio 2008 22.10, Roberto De Ioris [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ha scritto: ---
**Author:** ![Roberto\_De\_Ioris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/50afbb/32.png) [@Roberto\_De\_Ioris](https://www.ruby-forum.com/u/Roberto_De_Ioris)\ **Post date:** [May 20, 2008, 10:59pm UTC](https://www.ruby-forum.com/t/announce-rails-ugly-dispatcher-0-1/138186/5 "2008-05-20T22:59:30Z")
> La differenza sostanziale con mongrel/thin (oltre ad essere > completamente in c) e’ che usa il modello prefork, quindi N processi > saranno in ascolto sulla medesima porta TCP rendendo inutile l’uso di > proxy load balancer (se non, ovviamente in caso lanciate piu’ istanze di > rugd su macchine diverse). Complimenti per l’iniziativa! Curiousita` per quanto riguarda l'architettura: fa un fork per ogni connessione che arriva? Per ogni connessione che non puo` soddisfare subito? Un numero fisso di children? E com’e` diverso da mod\_fcgid o mod\_rails, al livello pratico (benchmarking?🙂 ## Grazie e complimenti ancora! David N. Welton [http://www.welton.it/davidw/](http://www.welton.it/davidw/) [http://www.dedasys.com/](http://www.dedasys.com/)