Scalabilità di Ruby on Rails rispetto a PHP

Question

Qualcuno può commentare quale è più scalabile tra RoR e PHP? Ho sentito che RoR è meno scalabile di PHP poiché RoR ha un po 'più di overhead con il suo framework MVC mentre PHP è più basso e più leggero. Questo è un po 'vago - qualcuno può spiegare meglio?

Answer 1

MVC è l'acronimo di Model-View-Controller, un modello di progettazione noto e comune, che mira a ottenere una chiara distinzione tra la logica aziendale (ad esempio il modello) e il livello di presentazione (Visualizza e controller). Questo è stato ampiamente trattato sul web e SO, quindi basta dare una ricerca.

RoR è un framework che ruota attorno a MVC e ActiveRecord costruito sul linguaggio di programmazione Ruby, come Zend Framework o Symfony è un framework costruito sul linguaggio di programmazione PHP. Confrontando la scalabilità di una struttura con una lingua, si confrontano mele e pere.

Per quanto riguarda la scalabilità di RoR: sì, RoR è stato criticato per il ridimensionamento in modo grave nel 2008, quando Twitter aveva alcuni problemi di prestazioni con esso. Questo è stato confutato da un certo numero di persone poco dopo. E mentre io non sono radicato nella comunità RoR, suppongo che RoR sia in scala, se lo fai correttamente. Ma tieni presente che la necessità di scalabilità è qualcosa che molti di noi desiderano, ma in realtà non lo fanno.

Quindi, a meno che non si debba prendere una decisione aziendale importante tra l'utilizzo di Ruby o PHP, non preoccuparsi di come vengono ridimensionate. E se lo hai, prendi in considerazione l'assunzione di consulenti per chiedere qui. E non sprecare mai il tuo tempo in flamewars tra le lingue.

Answer 2

Modifica: Gordon +2. +1 per la risposta e +1 per il commento! :)

La scalabilità per un framework è limitata al caching, agli archivi di sessioni, alla riduzione del numero di richieste HTTP, persino alle parti dell'interfaccia utente come creare sprite, caching di file js, ecc.! Potresti usare RoR/ZendPHP/CakePHP qualunque sia ancora la stessa cosa alla fine. Il vantaggio dell'utilizzo di RoR è che segue il paradigma MVC puro. È più facile concentrarsi sulla logica aziendale piuttosto che perdere tempo nella configurazione. È qui che RoR riesce su qualsiasi altro framework.

La scalabilità riguarda anche l'ORM utilizzato da un framework. Più veloci sono le operazioni di lettura/scrittura, migliori sono le prestazioni. Ma se non vuoi utilizzare un framework completo puoi sempre optare per micro-framework come sinatra, campeggio ecc. Che riducono un po 'l'overhead. Rails ha anche introdotto Rails Metal, costruito su rack che può essere utilizzato ad esempio per attività ricorsive e quindi aumentare le prestazioni.

In realtà la scalabilità di un'app riguarda principalmente il tuo hardware più del software coinvolto. Si occupa anche di come organizzi i tuoi dati nel database. Ad esempio, Google utilizza BigTable piuttosto che un RDBMS (come MySQL, PostGreSQL, SQLlite3, ecc.) Per una lettura e scrittura più veloce. In definitiva dipende dalla tua app.

vorrei suggerire si passa il tempo a vedere questa presentazione da Adam Wiggins, fondatore di Heroku:

Horizontal Scalability via Transient, Shardable, and Share-nothing Resources

Answer 3

Entrambi sono piuttosto lento.

Ruby è davvero molto lento, con un'impronta di memoria enorme, ma un linguaggio elegante e piacevole.

PHP è un po 'più veloce di Java e dot Net ma ancora piuttosto lento.

C, pascal o ml sono di qualche ordine di grandezza più veloce, ma la maggior parte delle persone trova molto più lento scrivere applicazioni web in esse.

Il mio suggerimento è di mettere un proxy inverso di bilanciamento del carico Nginx in primo piano e quindi scegliere il tuo framework, questo ti permette di aggiungere un numero abbastanza buono di istanze. Se ti interessano i costi dell'hardware e dell'elettricità, allora cerca uno stack più efficiente. La parte fondamentale è la cache intelligente.

Abbiamo un milione di utenti su un paio di macchine virtuali Nginx in esecuzione a carico minimo a causa del caching sensibile. Il contenuto dinamico è una miscela di cose e almeno 1000 volte più risorse rispetto alla cache. La chiave per il caching è che non è necessario tornare a nulla per verificare che la cache sia aggiornata, questa è stata la nostra migliore decisione di progettazione.

Utilizziamo una combinazione di C, C++, PHP, C#, Java, Python e Ruby a seconda di ciò che vogliamo ottenere.

C'è un bel articolo del blog su Ruby scalabilità dalle macchine configurando automaticamente utilizzando marionette a http://highscalability.com/blog/2011/6/13/automation-on-aws-with-ruby-and-puppet.html

Noi abbiamo un set up simile utilizzando marionette per tutte le nostre macchine virtuali. L'unico problema è che Puppet utilizza normalmente la maggior parte delle risorse per le nostre macchine non Ruby. Quindi vorremmo davvero riscrivere Puppet con qualcosa che richiede meno risorse di Ruby.