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
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
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?
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.
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.
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
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.
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.
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
