Forum: Italian Ruby user group applicazione rails con tre database

Ciao a tutti, sono nuovo a rails ed ho bisogno del vostro aiuto. Finora
con rails ho sviluppato una sola applicazione che si interfacciava ad un
unico database. Adesso però dovrei farne una che si interfaccia a tre
database. Mi spiego meglio. Gli utenti dell'applicazione sono gli stessi
ed a seconda dei casi devono potersi interfacciare ora ad uno dei
database ora ad un altro (pensavo ad una home page con tre link, uno per
database). Non so come impostare il tutto con rails. Posso fare un'unica
applicazione o devo farne tre? Sarei tentato per la prima soluzione, ma
mi chiedo: è una soluzione pulita? in questo modo avrei infatti nella
stessa applicazione modelli che non c'azzeccano niente (ma proprio
niente) l'un con l'altro. La seconda sembrerebbe invece più pulita, ma
come si gestisce?
Si devono avere più istanze di rails attive? Non ho la minima idea di
come possano essere organizzate (architetturalmente) su un unico server
più applicazioni rails. In poche parole ... sono confuso assai, se
qualcuno potesse illuminarmi ... gliene sarei grato parecchio ;-)

Ciao a tutti e ... grazie!!!

Ti suggerisco di aggiungere le altre configurazioni al file
config/database.yml, poi tramite un inizializer (config/initializers)
leggi le configurazioni e le aggiungi a 
ActiveRecord::Base.configurations

Nei modelli in cui è richiesta una connessione differente da quella
principale fai 
così:
class Model < ActiveRecord::Base
   establish_connection "my_connection_name"
end


Luca

Luca Guidi wrote:
> Ti suggerisco di aggiungere le altre configurazioni al file
> config/database.yml, poi tramite un inizializer (config/initializers)
> leggi le configurazioni e le aggiungi a 
> ActiveRecord::Base.configurations
> 
> Nei modelli in cui � richiesta una connessione differente da quella
> principale fai 
> cos�:
class Model < ActiveRecord::Base
>    establish_connection "my_connection_name"
> end
> 
> 
> Luca

Ti ringrazio per la risposta. Stavo però pensando che potrei fare anche 
in un altro modo: creo separatamente le 3 applicazioni che si 
interfacciano ai 3 database (con WEBrick). Poi per metterle in 
produzione metto un front-end server (Apache? lighttpd?) e uno o più 
back-end server (mongrel?). Sul front-end metto una pagina statica 
contenente i link alle 3 applicazioni. Ma per la parte back-end non ho 
idea di come fare. Devo avere almeno un back-end per ogni applicazione o 
potrei anche averne uno per tutte e 3 le applicazioni. Chiarisco subito 
che per il numero di utenti degli applicativi uno sarebbe più che 
sufficiente (gli applicativi stanno in una Intranet, ci potranno essere 
in media 10-20 accessi concorrenti, non di più ... al limite si potrebbe 
arrivare a un max di 50). Ma può un solo back-end essere configurato per 
servire 3 applicazioni distinte? Potete aiutarmi?

Ciao e grazie

Cosa intendi per back-end?
Averne uno, significa seguire la strada che ti ho suggerito, cioè una
sola applicazione Rails, magari messa in cluster con più mongrel o con
passenger e come front-end apache o nginx.

Avere tre back-end, significa moltiplicare per tre quanto appena detto,
con l'unica eccezione del web server, di cui dovresti avere una sola
istanza.

Ci sarebbe anche una terza soluzione, utilizzare Rack, montando le altre
due piccole applicazioni in quella principale costruita con Rails.

PS: ti sconsiglio l'utilizzo di WEBrick in produzione.

Luca

Luca Guidi wrote:
> Cosa intendi per back-end?
> Averne uno, significa seguire la strada che ti ho suggerito, cio� una
> sola applicazione Rails, magari messa in cluster con pi� mongrel o con
> passenger e come front-end apache o nginx.
> 
> Avere tre back-end, significa moltiplicare per tre quanto appena detto,
> con l'unica eccezione del web server, di cui dovresti avere una sola
> istanza.
> 
> Ci sarebbe anche una terza soluzione, utilizzare Rack, montando le altre
> due piccole applicazioni in quella principale costruita con Rails.
> 
> PS: ti sconsiglio l'utilizzo di WEBrick in produzione.
> 
> Luca

Per back-end intendo proprio quello che hai capito, credo. E' ovvio che 
sto navigando al buio. Il fatto è che non mi piace l'idea di mischiare 
modelli che non hanno niente a che fare l'un con l'altro, perciò pensavo 
di evitare di sviluppare un'unica applicazione. D'accordo sul non usare 
WEBrick in produzione, non ho mai pensato di farlo (mi ero evidentemente 
spiegato male). D'accordo su una sola istanza per il web server. Ma 
ancora non riesco a capire se una sola istanza (ad es. di mongrel) può 
gestire più di una applicazione (in questo caso tre). Voglio dire: un 
ISP che offre un servizio di hosting per rails, come fa a gestire tutte 
le diverse applicazioni che gli utenti gli sottopongono? Ha tante 
istanze di mongrel (per esempio) quante sono le applicazioni oppure 
potrebbe anche avere (per assurdo ... senza pensare alle prestazioni) 
una sola istanza di mongrel per tutte? Abbi pazienza, ma devo cercare di 
capire questo che considero la base indispensabile per andare avanti.

Ciao e grazie

Il rapporto applicazione -> mongrel è 1-n.

Quindi si parte da un'istanza di mongrel per un'applicazione, se questa
dovesse rivelarsi insufficiente si aggiungono altre istanze.

Di default un'applicazione Rails è single-threaded, il che significa
che, nel suo contesto (un mongrel) riesce a soddisfare una richiesta per
volta. Dalla versione 2.2 è possibile cambiare questa configurazione.

Quindi se hai 10 utenti che fanno simultaneamente una richiesta ad una
risorsa, che ha una latenza di un secondo ed un solo mongrel, l'ultimo
utente servito vedrà la risposta dopo 10 secondi.

Ovviamente, all'aumentare dei nodi, aumentano le request al secondo che
riesce a soddisfare il tuo servizio, cioè l'insieme di istanze di mongrel.

Se nell'esempio di prima il throughput era 1 req/s, aggiungendo un nodo,
diventa di 2 req/s e così via.. Ovviamente questo è un esempio
semplificato e non vale all'infinito (cerca i tradeoffs della
scalabilità orizzontale).

Tutta questa configurazione deve essere trasparente agli occhi
dell'utente finale, il quale vuole solo digitare www.example.com sul suo
browser ed utilizzare il tuo servizio.

Per questo si utilizza un web server che faccia da balancer verso il tuo
cluster di nodi. Il suo compito è di ascoltare sulla porta 80 e di
forwardare le richieste all'applicazione e al path giusto.

Questo ci permette anche di avere più applicazioni (quindi più cluster)
su una sola macchina, il web server sarà incaricato di decidere non solo
quale applicazione è responsabile per una determinata request, ma anche
nodo dovrà soddisfarla.

Quando compri un servizio di hosting, generalmente si inizia con un VPS,
hai a disposizione una macchina virtuale, che ti permette di agire solo
sui tuoi clusters e web server.

Quindi un server fisico ha tante macchine virtuali, le quali hanno un
web server ed una o più applicazioni, ciascuna delle quali ha un cluster
di application servers.

Per un'applicazione che ha un carico medio di 20 persone un cluster di
tre nodi dovrebbe andare bene.

Consigli:
- application server: passenger, mongrel o thin
- web server: apache o nginx

Passenger, a differenza degli ultimi due, ha una sola istanza e provvede
di creare più processi per soddisfare un carico di richieste maggiore.

Ti consiglio di leggere Deploying Rails Applications
http://www.pragprog.com/titles/fr_deploy/deploying-rails-applications

Luca

Luca Guidi wrote:
> Il rapporto applicazione -> mongrel è 1-n.

Ok, questo lo avevo capito. Ma allora, ragionando in questi termini, 
possiamo dire che il rapporto mongrel -> applicazione è 1-1?

> Quindi si parte da un'istanza di mongrel per un'applicazione, se questa
> dovesse rivelarsi insufficiente si aggiungono altre istanze.
> Di default un'applicazione Rails è single-threaded, il che significa
> che, nel suo contesto (un mongrel) riesce a soddisfare una richiesta per
> volta. Dalla versione 2.2 è possibile cambiare questa configurazione.
>    .
>    .
>    .
> Per questo si utilizza un web server che faccia da balancer verso il tuo
> cluster di nodi. Il suo compito è di ascoltare sulla porta 80 e di
> forwardare le richieste all'applicazione e al path giusto.

Ok

> Questo ci permette anche di avere più applicazioni (quindi più cluster)
> su una sola macchina, il web server sarà incaricato di decidere non solo
> quale applicazione è responsabile per una determinata request, ma anche
> nodo dovrà soddisfarla.

Tornando al discorso di poc'anzi ogni nodo è comunque dedicato ad una sola 
applicazione (se è vero che il rapporto mongrel -> applicazione è 1-1), 
giusto?
Poi sullo stesso server potrò avere più applicazioni, delle quali una 
necessità di 3 mongrel, una di 10 mongrel, un'altra ancora di un solo 
mongrel ... e così via. Ho capito bene?

> Quando compri un servizio di hosting, generalmente si inizia con un VPS,
> hai a disposizione una macchina virtuale, che ti permette di agire solo
> sui tuoi clusters e web server.
> Quindi un server fisico ha tante macchine virtuali, le quali hanno un
> web server ed una o più applicazioni, ciascuna delle quali ha un cluster
> di application servers.

Mi pare che questo confermi quanto appena affermato, il rapporto mongrel 
-> applicazione è 1-1.

> Per un'applicazione che ha un carico medio di 20 persone un cluster di
> tre nodi dovrebbe andare bene.
> Consigli:
> - application server: passenger, mongrel o thin
> - web server: apache o nginx
> Passenger, a differenza degli ultimi due, ha una sola istanza e provvede
> di creare più processi per soddisfare un carico di richieste maggiore.

Grazie per i consigli. Ho visto in rete che anche lighttpd è molto 
gettonato.

> Ti consiglio di leggere Deploying Rails Applications
> http://www.pragprog.com/titles/fr_deploy/deploying-rails-applications

Lo farò sicuramente.

> Luca

Grazie infinite per la tua pazienza. Ciao.

Gillengam Gillengam wrote:
> Tornando al discorso di poc'anzi ogni nodo � comunque dedicato ad una sola
> applicazione (se � vero che il rapporto mongrel ->  applicazione � 1-1),
> giusto?
> Poi sullo stesso server potr� avere pi� applicazioni, delle quali una
> necessit� di 3 mongrel, una di 10 mongrel, un'altra ancora di un solo
> mongrel ... e cos� via. Ho capito bene?
Sisi è così.

> Grazie infinite per la tua pazienza. Ciao.
Nulla

Luca

Gillengam Gillengam wrote:
> Ok, questo lo avevo capito. Ma allora, ragionando in questi termini, 
> possiamo dire che il rapporto mongrel -> applicazione � 1-1?
> 

No, è come ha scritto Luca: 1-n. Ad ogni applicazione puoi associare n 
istanze di mongrel e metterle sotto un balancer ma non il contrario. Se 
hai tre applicazioni devi usare minimo 3 mongrel.

Anche io sviluppo in una intranet, non so te ma io su windows con server 
virtualizzati di ottime prestazioni e forse possiamo confrontarci. Sto 
rilasciando in questi giorni un applicazione di media complessità (15 
model principali più una decina secondari) da servire ad un totale di 
50-60 persone, ma nell'arco delle 8 ore lavorative presumo che il carico 
di lavoro medio sarà intorno le 10 persone.
Ho visto che una singola istanza di mongrel va più che bene, ed ora la 
uso senza nemmeno un web server mentre in produzione la userò sotto iis 
(niente apache, la mia azienda impone questo). Fra qualche settimana 
potrò essere più preciso.

Ti posso dire che basta non trascurare l'efficienza perchè è ovvio che 
se dove basterebbe una query ne fai 10 o stramazzi il povero interprete 
ottenendo 1 o più secondi di rendering... le cose cambiano e di molto. 
Io in più utilizzo ajax dove posso spezzettando così le richieste in 
tante piccoline e dove più che altro lavora il server db.

Se leggi il libro che ti ha consigliato luca capirai molte altre cose, 
c'è scritto per esempio che su linux una singola istanza mongrel 
dovrebbe riuscire a gestire fino 60 persone contemporaneamente, la 
stessa carrozza su windows calerebbe a 6-9

Per il discorso provider io per es. utilizzo unbit che credo utilizzi 
fastcgi ovviamente su linux ...magari avere qualcosa del genere nella 
mia azienda

Marco, ti consiglio di usare *sempre* un webserver davanti agli
application server. Anche se hai una sola istanza di Mongrel.

Innanzitutto per un fatto di sicurezza, poi perché i file statici
vengono serviti più velocemente da un webserver, e non sprechi cicli
inutili dell'application server.

Luca