Ruby un linguaggio MERAVIGLIOSO… se fosse una bionda occhi azzurri…
l’avrei gi inivitata a cena
tuttavia… da un paio di mesi ho un tarlo che mi tormenta…
vorrei provare a ragionare con voi sulla questione scalabilit +
performance nell’ecosystem ruby
Un’architettura SOA in Ruby strutturata con RabbitMq e MondoDB, divisa
in 2 layer: web service da una parte (backend) e rails che usa tali web
service (frontend)… riuscirebbe a tenere in piedi linkedin ?
Me lo chiedo perch ultimamente progetti di dimensioni astrali (nati in
ruby AND rails) stanno passando a scala-lang+lift:
twitter
foursquare
linkedin
Non voglio sentire risposte del tipo “linkedin
linkedin”… --> chissenefrega !!
in 2 layer: web service da una parte (backend) e rails che usa tali web
service (frontend)… riuscirebbe a tenere in piedi linkedin ?
La domanda non ha molto senso, non che se butti pezzi di software in
giro una architettura scala di pi o di meno.
Me lo chiedo perch ultimamente progetti di dimensioni astrali (nati in
ruby AND rails) stanno passando a scala-lang+lift:
twitter
foursquare
linkedin
Non mi risulta che Linkedin e 4sq siano mai stati in Rails, ma siano
nati l’uno su .net e l’altro in Scala. Linkedin ha scritto una facebook
app in Rails, che ha usato come esempio di scalabilit.
In ogni caso, a meno che non esista una sorta di matrimonio tra te e
Rails, non detto che tu debba usare una sola tecnologia, e in effetti
non sono a conoscenza di un grosso network che fa di queste scelte di
campo.
Il problema pi grosso di Ruby la concorrenza su processori multicore,
se ti serve usa qualcosa di meglio, ovvero non usare Ruby, Python, PHP,
Java e fondamentalmente qualunque linguaggio imperativo sul mercato, ma
Clojure, Erlang, Scala, Haskell, o quello che pi ti aggrada.
Per quanto riguarda la domanda specifica, si, Rails tiene su Linkedin,
ma essendo la scalabilit una media tra benefici e prezzo, forse non
molto economicamente.
Ma di nuovo, basta usare la tecnologia e non sposarla, puoi
tranquillamente usare Rails ed eliminare i colli di bottiglia con dei
servizi ad hoc.
come ha detto Nicholas W., mi pare che solo twitter usi Rails
twitter ha milioni di utenti
fino a poco tempo fa riusciva a girare perfettamente usando solo
Ruby
Ruby è a tipizzazione dinamica ed ha un garbage collector che non è
perfetto
un linguaggio a tipizzazione statica richiede meno elaborazione e
meno memoria
un linguaggio a tipizzazione statica non è Ruby ed è, di solito,
meno produttivo
twitter non ha abbandonato Ruby, ma lo ha integrato con altri
linguaggi
Quindi, essenzialmente, ti dovresti preoccupare della scalabilità solo
arrivato ad un numero di utenti “spropositato”; fino ad allora, i soliti
metodi (chaching + loadbalancing + replica db) sono più che sufficienti.
Quando sarai arrivato ad avere un numero di utenti “spropositato”
penserai a come ottimizzare quelle parti di codice che occupano troppe
risorse, magari usando un linguaggio più performante ma meno
“divertente” di Ruby
La risposta : s, ma si pu fare di meglio.
7) twitter non ha abbandonato Ruby, ma lo ha integrato con altri
linguaggi
Per la precisione, ha mantenuto in Rails il frontend ma ha
progressivamente migrato da Ruby a Scala tutti i programmi di backend
che con i carichi che erano arrivati ad avere iniziavano ad essere un
collo di bottiglia. L’interprete Ruby e pure jruby non sono certo
veloci: la dinamicit ha un prezzo.
Temo non sia questione di dinamicit (per carit, Clojure ha le macro di
Lisp, c’ qualcosa di pi “dinamico” ?), ne di “velocit raw”.
La parte che stata riscritta il queue manager e basta, non mi risulta
che Twitter abbia sostituito altri pezzi.
La migrazione di Twitter tutt’ora abbastanza oscura, la notizia stata
data come “Ruby troppo lento quindi Twitter passa a Scala”, la realt
che Starling, il queue manager sviluppato in Ruby da Blaine C., era
una merda (e lo tutt’ora), che la gente di Twitter ha provato ad usare
anche RabbitMQ e ActiveMQ, e che alla fine hanno riscritto in Scala non
come progetto interno, ma come progetto sviluppato nel tempo libero da
uno dei suoi sviluppatori.
La notizia quindi stata decisamente manipolata:
La risposta è: sì, ma si può fare di meglio.
7) twitter non ha abbandonato Ruby, ma lo ha integrato con altri
linguaggi
Per la precisione, ha mantenuto in Rails il frontend ma ha
progressivamente migrato da Ruby a Scala tutti i programmi di backend
che con i carichi che erano arrivati ad avere iniziavano ad essere un
collo di bottiglia. L’interprete Ruby e pure jruby non sono certo
veloci: la dinamicità ha un prezzo.
Si è trattato quindi di un’ottimizzazione che per una volta ha
comportato un cambio di linguaggio. Loro sono stati molto saggi secondo
me: hanno iniziato con il linguaggio che gli permetteva di uscire più
rapidamente possibile, poi hanno avuto un successo tale da dover
ottimizzare ed hanno ottimizzato.
Nella stragrande maggioranza dei casi non si arriva mai al punto di aver
le macchine cariche e quindi non è il caso di preoccuparsi in anticipo.
Bisogna invece pensare al tempo e ai soldi risparmiati riuscendo a
rilasciare in fretta e a scoprire altrettanto in fretta quel che gli
utenti pensano del servizio. Poi quella volta su mille in cui si sfonda,
si sarà ben felici di investire nelle ottimizzazioni parte dei soldi
risparmiati nelle 999 volte precedenti.
Mi introduco in questa interessantissima discussione solo per
aggiungere una considerazone nata da un’esperienza sull’argomento che
e’ ben lontana da considerarsi anche semplicemente “sufficiente”.
Detto questo…
Uno dei problemi legati alle webapp basate su ruby che tentano di
coprire un’utenza di dimensioni “Armageddon” non e’ per caso legata
soprattutto all’assenza di una cultura di sviluppo basata su di uno
stack completamente asincrono come invece puo’ essere quello di NodeJS
(o analogamente di framework basati sui inguaggi puramente
funzionali)?
Mi sto avvicinando ancora da troppo poco tempo a EventMachine ma
approcci che comprendono EM, ruby 1.9, fibers e thin dovrebbero
risolvere una grossa fetta delle problematiche relative alla
scalabilita’ in Ruby, almeno per cio’ che concerne ambienti a singolo
processore (a causa del GIL).
Per ambienti a N processori penso si possa implementare un sistema di
N threads sotto jruby sfruttando le medesime librerie ma per questo
caso conosco ancora meno il supporto e le eventuali problematiche
dell’implementazione dei fibers sotto jruby.
C’e’ per caso qualcuno che conosce degli aspetti negativi di tali
approcci?
On Jan 30, 2011, at 3:50 PM, maurizio de magnis wrote:
funzionali)?
dell’implementazione dei fibers sotto jruby.
C’e’ per caso qualcuno che conosce degli aspetti negativi di tali approcci?
Non serve che tutto sia asincrono o che tutto giri su n processori, in
questi casi si dice “there’s no silver bullet”. E’ questione di valutare
di volta in volta diverse soluzioni in base al problema e implementarle
usando la tecnologia adatta.
Rails e Ruby sono un bel framework ed un bel linguaggio, se pero’ tenti
di scriverci un gestore di code usando i green thread stai evidentemente
usando la tecnologia sbagliata per il progetto sbagliato. D’altro canto,
anche avere un form con 5 campi e salvarli nel database usando callback
e errback non cos tanto furbo, a meno che tu non stia tentando di
implementare il form per il censimento cinese che avverr per tutta la
popolazione in un singolo giorno.
Tipicamente i colli di bottiglia per un’applicazione corrispondono a
meno del 10% del codice scritto, sostituire quel codice con servizi
basati su tecnologie differenti un problema almeno del 90% inferiore
che implementare il tutto usando Lift (che personalmente trovo orrendo,
gusti miei …).
Personalmente sia Ruby che Rails mi vanno benissimo sotto il punto di
vista della scalabilit, in parte perch a riguardo la piattaforma non
puo’ fare moltissimo (insomma, la tecnologia non scala out of the box),
in parte perch usato come framework per sviluppare il 90% di un software
nonch core su cui costruire servizi godibilissimo e produttivo, proprio
perch mi sono trovato nella situazione di usare “altro” e so che, anche
usando un linguaggio come Erlang che conosco bene, sono molto meno
produttivo e ho molta meno “infrastruttura”.
Pur amandolo molto, dovessi scrivere un sito web come Zooppa in erlang
credo mi sparerei in faccia
Come dicevo questione di costi per performance, si puo’ tentare un
async_rails, ma poi voglio vedere i vostri “lean controllers” come
diventano
Trovo il ragionamento molto sensato…
La questione ben rappresentata da una bilancia: produttivit/piacere
di sviluppo da una parte, efficienza e scalabilit dall’altra…
Se Rails mi aumenta l’efficienza di sviluppo del 200%… ma, nello stesso
tempo, il numero di server per tenerlo in piedi mi aumenta di 6
volte… cos’ peggio ?
Ragionando nel breve periodo e per progetti piccoli/medio/grandi la
scelta ovvia: Ruby+Rails
Ma nel lungo periodo con progetti “Armageddon”, quando ti vedi
arrivare invoices da capogiro dal fornitore cloud ?
Ed in pi ti accorgi che la tua architettura pi di cosi, non
riesce a crescere perch sei arrivato al limite superiore ?
A quel punto, quanto costa migrare i servizi “collo di
bottiglia” ad altra tecnologia ?
Probabilmente dovrei farmi meno problemi… perch in realt (forse)
sono finti problemi:
se un progetto diventa di dimensioni armageddon ci sono anche le
risorse per ricodificare i colli di bottiglia con altro o,
paradossalmente per riscrivere tutto
peccato mi abbiano sempre insegnato a non continuare a fare per
poi disfare
Ps. “Lift (che personalmente trovo orrendo)” -> lo trovo orrendo pure
io, come trovo orrendo Scala… ma questo non toglie che in bay area sta
passando l’idea che scala+lift siano il “nuovo” (ruby+rails)^2
mi auguro davvero che il ruby ecosystem si dia da fare per togliere
a tutti noi questa fastiosa spina nel fianco… quindi… DIAMOCI da
fare !
Ps. “Lift (che personalmente trovo orrendo)” → lo trovo orrendo pure
io, come trovo orrendo Scala… ma questo non toglie che in bay area sta
passando l’idea che scala+lift siano il “nuovo” (ruby+rails)^2
Nella bay area, tutti sognano di fare ‘the next big thing’, e c’e una probabilita piu alta che si tratti di un'azienda con VC alle spalle che spinge l'azienda a "shoot for the moon". Invece, se non stai mirando cosi tanto in alto, oppure stai facendo bootstrapping, e molto meglio la flessibilita per cambiare velocemente in base a
quello che trovi quando la gente inizia ad usare il tuo prodotto.
Come dici, giustamente, se riesci a fare una cosa che sta andando alla
grande, trovi anche le risorse per rescrivere il collo di bottiglia.
E un caso di 'survivorship bias': sono sotto gli occhi di tutti quelle aziende che, diventando grandi, hanno dovuto affrontare problemi di scalabilita. Invece, non vede nessuno le aziende che
sono fallite perche hanno optato per lavorare molto sulla scalabilita e meno sul prodotto stesso.
Come dici, giustamente, se riesci a fare una cosa che sta andando alla
grande, trovi anche le risorse per rescrivere il collo di bottiglia.
Eun caso di 'survivorship bias': sono sotto gli occhi di tutti quelle aziende che, diventando grandi, hanno dovuto affrontare problemi di scalabilita. Invece, non vede nessuno le aziende che
sono fallite perchehanno optato per lavorare molto sulla scalabilita e meno sul prodotto stesso.
E’ il motivo per cui ( venendo da java e php… ps: typo3 ti ricorda
niente ? ) ho scelto e rimango nella ruby-scatola
Sono d’accordo con il concetto che “there’s no silver bullet”, che se
devi gestire delle code forse e’ meglio basarsi su jruby che puo’
sfruttare i thread nativi e che se hai a disposizione uno strumento
tanto performante quanto scomodo allora e’ lo strumento sbagliato.
Mi permetto di dissentire sul resto
L’applicazione Ruby che scrivi deve essere hostata in un ambiente in
cui si deve sempre fare economia di risorse. Se occupi molta RAM per
gestire piu’ istanze dell’interprete per aumentare il parallelismo
delle richieste, c’e’ qualcosa che non va.
Significa semplicemente che quell’host ospitera’ meno webapps.
L’incapacita’ di gestire molte richieste in contemporanea preclude poi
la possibilita’ di sviluppare sistemi Comet che sono invece il futuro.
Pensa se fosse immediato scrivere applicazioni orientate agli eventi
in Ruby, non vedremmo forse una proliferazione di webapp che espongono
API e di servizi di hosting basati su Ruby?
On Jan 31, 2011, at 3:37 PM, maurizio de magnis wrote:
delle richieste, c’e’ qualcosa che non va.
Mi stai dicendo che se aumentando le istanze necessito di RAM c’
qualcosa che non va ?
Significa semplicemente che quell’host ospitera’ meno webapps.
Per software di questo livello pi host ospitano una sola webapp, non
credo che lo shared hosting rientri nel discorso.
L’incapacita’ di gestire molte richieste in contemporanea preclude poi
la possibilita’ di sviluppare sistemi Comet che sono invece il futuro.
No, decisamente non direi, sia sul fatto che Comet sia il “futuro”, sia
sul fatto che sia impossibile farlo.
Pensa se fosse immediato scrivere applicazioni orientate agli eventi
in Ruby, non vedremmo forse una proliferazione di webapp che espongono
API e di servizi di hosting basati su Ruby?
Guarda, io vivo a Seattle, e pi webapp in Rails di quelle che gi ci sono
dura, si parlerebbe di monopolio.
Temo che questa mania del software event-driven sia piuttosto
disinformata e passeggera, in parte perch node.js scala esattamente come
Rails, ovvero instanziando pi backend per reggere pi concorrenza, in
parte perch vedo che metti insieme cose apparentemente non correlate tra
di loro, come il metodo di scaling con il consumo di RAM, che
onestamente non c’entra una mazza (infatti node.js tutt’altro che
leggero a consumo di RAM).
Ci sono comunque molte piattaforme event-driven (curiosamente Python ha
un framework da paura a riguardo dal 2004, ma per iniziare ad essere
usato sul web ha dovuto aspettare Django), se Rails non va bene basta
guardare altrove.
Non che perch ora va di moda Clojure Ruby deve diventare un lisp
On Jan 31, 2011, at 4:32 PM, maurizio de magnis wrote:
Intendevo dire che per aumentare il parallelismo devo istanziare piu’
interpreti e ognuno di questi richiede un quantitativo di RAM non
indifferente
E allora tenta di limitare il numero di istanze, cosa che riesci a fare
profilando la codebase e limitando i tempi di risposta.
Voglio dire, Resque e affini ci sono da una vita, cos come soluzioni
quasi decenti per il caching, il minifying, nginx puo’ servire gli asset
direttamente, si puo’ usare gzip … di roba da fare per limitare i
blocchi ai backend ce n’. Se poi ancora lento si guarda altrove, ma
almeno non si sta sparando nel mucchio e il problema stato isolato.
Ovviamente alcuni problemi sono evidentemente difficili da risolvere con
questo modello, la “timeline” di Twitter un esempio.
Con Zooppa ho risolto con un servizietto in async_sinatra su EM e
RabbitMQ, che va benone. Ma ho sostituito una pagina con un servizio,
ci ho messo 10 giorni, non mi sono messo a riscrivere tutto usando
node.js o erlang
Significa semplicemente che quell’host ospitera’ meno webapps.
Per software di questo livello pi host ospitano una sola webapp, non credo che
lo shared hosting rientri nel discorso.
Il mio discorso riguarda trasversalmente sia le singole webapp
“Armageddon” che le piccole webapp negli ambienti shared: se sei
dotato di uno stack capace di gestire piu’ richieste a fronte di un
consumo di risorse ridotto avrai un vantaggio significativo in
entrambi i casi.
Beh si, ma qui forse stai confondendo performance e scalabilit, la
scalabilit, come detto, una cosa diversa, il giusto mezzo tra tempi di
sviluppo e costi.
Io mi sono trovato a pagare anche + di $5000 al mese di hosting, ma
arrivati a quel punto chiaro che hai un business dietro per sostenere
tali spese, e che ti conviene rispetto all’assunzione di uno
sviluppatore da $80000 all’anno (questa evidentemente una
generalizzazione).
La gestione della parte tecnica di una startup come Twitter o 4sq una
materia complessa, mi piacerebbe fosse sufficiente switchare a node.js,
ma bisogna considerare i costi di sviluppo, di deploy, il TTM, le SLA
che vendi, i costi di un down, e lo fai solo attraverso analisi e
profiling.
E’ appena uscito un gran bel testo a riguardo: The art of Capacity
Planning della O’Reilly.
L’incapacita’ di gestire molte richieste in contemporanea preclude poi
la possibilita’ di sviluppare sistemi Comet che sono invece il futuro.
No, decisamente non direi, sia sul fatto che Comet sia il “futuro”, sia sul
fatto che sia impossibile farlo.
ok, l’aspetto “divinatorio” e’ soggettivo =)
e comunque non ho detto che e’ impossibile, intendevo dire che
all’aumentare del numero di utenti, le performance calano
drasticamente.
Dipende, uno dei software pi conosciuti in Rails che potrebbe
avvantaggiarsi di Comet Campfire, e i 37s hanno usato Erlang usando una
strada opposta, il polling.
In ogni caso anche se applicazioni Comet-like dovessero essere il
futuro, forse meglio parlare di Websockets, a quel punto se le
performance sono cos orrende semplicemente scrivi un servizio in
un’altra tecnologia che salta completamente Rails e pusha sul browser
direttamente.
sono ancora molto ignorante su questo argomento
per lo scaling di rails mi riferivo alle soluzioni che implicano
cluster di mongrel.
E che ha di male ? Io con mongrel ho retto il traffico di att.com
(simplify.att.com) senza fare una piega, su 5 macchine. Un mashup
scritto a botte di 15 ore al giorno in una settimana, tutte bloccanti.
L’ho scalato usando il caching in modo furbo, le POST sull’API
ripopolavano la cache, mettendo gli upload (che erano robe anche da 200
mega …) in background con resque.
E c’ gi di meglio, come l’ottimo Unicorn.
Ci sono comunque molte piattaforme event-driven (curiosamente Python ha un
framework da paura a riguardo dal 2004, ma per iniziare ad essere usato sul web ha
dovuto aspettare Django), se Rails non va bene basta guardare altrove.
ma io infatti voglio restare su Ruby
e voglio anche un ambiente event driven Ruby based semplice tanto
quanto lo e’ l’ambiente “classico”!
Temo sia impossibile, purtroppo l’OOP un modello che ben si adatta ai
nostri cervelli, mentre quello event driven (e/o funzionale) IMHO no.
C’ comunque EventMachine.
Mi stai dicendo che se aumentando le istanze necessito di RAM c’ qualcosa che
non va ?
Credo che il concetto sia: “a parita di funzionalita, soluzioni
diverse richiedono quantita diverse di risorse (cpu, ram, disco), e Rails puo essere un po’ pesante”. E non credo che sia sbagliato.
Pero, per quanto mi riguarda, quel 'pesante' ripaga in flessibilita
e codice pulito.
Guarda, io vivo a Seattle, e pi webapp in Rails di quelle che gi ci sono dura,
si parlerebbe di monopolio.
Consiglio da uno del north west: fai un giro in Arizona o qualcosa
posto simile per una settimana durante l’inverno per asciugarti un
po:-)
Temo che questa mania del software event-driven sia piuttosto disinformata e
passeggera, in parte perch node.js scala esattamente come Rails, ovvero
instanziando pi backend per reggere pi concorrenza, in parte perch vedo che metti
insieme cose apparentemente non correlate tra di loro, come il metodo di scaling
con il consumo di RAM, che onestamente non c’entra una mazza (infatti node.js
tutt’altro che leggero a consumo di RAM).
Ci sono comunque molte piattaforme event-driven (curiosamente Python ha un
framework da paura a riguardo dal 2004, ma per iniziare ad essere usato sul web ha
dovuto aspettare Django), se Rails non va bene basta guardare altrove.
Ecco… il ‘re’ dell’event driven e Erlang, secondo me, e la vedi
che riesci a fare molto di piu con meno memoria rispetto a Rails, PHP o altri sistemi simili, perche non copia tutto il sistema con fork o
thread. Vale la pena darci un’occhiata per capire come funziona,
perche ha alcune idee molto interessanti, e molto diverse dal 'mainstream'. Poi... io ho dei dubbi sulle sue possibilita; non
credo che diventera un linguaggio molto usato, ma e comunque
qualcosa di notevole.
On Jan 31, 2011, at 3:37 PM, maurizio de magnis wrote:
L’applicazione Ruby che scrivi deve essere hostata in un ambiente in
cui si deve sempre fare economia di risorse. Se occupi molta RAM per
gestire piu’ istanze dell’interprete per aumentare il parallelismo
delle richieste, c’e’ qualcosa che non va.
Mi stai dicendo che se aumentando le istanze necessito di RAM c’ qualcosa che
non va ?
Ho espresso male il concetto
Intendevo dire che per aumentare il parallelismo devo istanziare piu’
interpreti e ognuno di questi richiede un quantitativo di RAM non
indifferente
Significa semplicemente che quell’host ospitera’ meno webapps.
Per software di questo livello pi host ospitano una sola webapp, non credo che
lo shared hosting rientri nel discorso.
Il mio discorso riguarda trasversalmente sia le singole webapp
“Armageddon” che le piccole webapp negli ambienti shared: se sei
dotato di uno stack capace di gestire piu’ richieste a fronte di un
consumo di risorse ridotto avrai un vantaggio significativo in
entrambi i casi.
L’incapacita’ di gestire molte richieste in contemporanea preclude poi
la possibilita’ di sviluppare sistemi Comet che sono invece il futuro.
No, decisamente non direi, sia sul fatto che Comet sia il “futuro”, sia sul
fatto che sia impossibile farlo.
ok, l’aspetto “divinatorio” e’ soggettivo =)
e comunque non ho detto che e’ impossibile, intendevo dire che
all’aumentare del numero di utenti, le performance calano
drasticamente.
Pensa se fosse immediato scrivere applicazioni orientate agli eventi
in Ruby, non vedremmo forse una proliferazione di webapp che espongono
API e di servizi di hosting basati su Ruby?
Guarda, io vivo a Seattle, e pi webapp in Rails di quelle che gi ci sono dura,
si parlerebbe di monopolio.
ottima cosa
Temo che questa mania del software event-driven sia piuttosto disinformata e
passeggera, in parte perch node.js scala esattamente come Rails, ovvero
instanziando pi backend per reggere pi concorrenza, in parte perch vedo che metti
insieme cose apparentemente non correlate tra di loro, come il metodo di scaling
con il consumo di RAM, che onestamente non c’entra una mazza (infatti node.js
tutt’altro che leggero a consumo di RAM).
sono ancora molto ignorante su questo argomento
per lo scaling di rails mi riferivo alle soluzioni che implicano
cluster di mongrel.
Ci sono comunque molte piattaforme event-driven (curiosamente Python ha un
framework da paura a riguardo dal 2004, ma per iniziare ad essere usato sul web ha
dovuto aspettare Django), se Rails non va bene basta guardare altrove.
ma io infatti voglio restare su Ruby
e voglio anche un ambiente event driven Ruby based semplice tanto
quanto lo e’ l’ambiente “classico”!
In effetti Erlang ha delle potenzialit notevoli. Secondo me non ce la
far mai a sfondare finch non cambier sintassi per cammuffarsi da
linguaggio procedurale. A quel punto sar un linguaggio con un nome
diverso, ma meritano attenzione le performance del runtime ed il modo in
cui il Erlang ingloba il parallelismo.
Puo’ essere che ti faccio la giornata: http://reia-lang.org/
Dubito anch’io diventer mai un linguaggio molto usato, anche perch
risolve problemi abbastanza specifici a cui non tutti sono interessati o
hanno necessit.
E’ che anche sforzandomi non riesco a vedere questo fatto come negativo
ed è, di solito,
