2009-07-22 11 views
7

Immagino che questa domanda sia stata posta molto in giro. Lo so Rails può scalare perché ci ho lavorato ed è fantastico. E non ci sono molti dubbi a riguardo per quanto riguarda i framework PHP.Costo del ridimensionamento Rails rispetto al costo del ridimensionamento Framework PHP vs Python

Non voglio sapere quali strutture sono migliori.

Quanto costa la differenza di scalabilità di Rails rispetto ad altri framework (PHP, Python) ipotizzando un'app di grandi dimensioni con 1 milione di visite al mese?

Questo è qualcosa che mi viene chiesto molto. Posso spiegare alla gente che "Rails scala abbastanza bene" ma, a lungo termine, quali sono gli aspetti economici?

Se qualcuno può fornire alcune metriche, sarebbe fantastico.

+2

Anch'io sono un po 'curioso ma dubito davvero che ci sia una risposta concreta a questa domanda. Ci sono troppe variabili. Design del sito, valore del tempo del programmatore rispetto al tempo della macchina, ecc. Penso che ci siano esempi di siti di grandi dimensioni per la maggior parte delle piattaforme, –

risposta

5

Uno dei principali fattori in questo è che non è influenzato dalla scelta del framework è l'accesso al database. Indipendentemente dall'approccio adottato, è probabile che i dati vengano inseriti in un database relazionale. Quindi la domanda è quanto è efficiente ottenere i dati dal database. Ciò dipende principalmente dal RDBMS (Oracle vs Postgres vs. MySQL), e non dal framework - eccetto che alcune librerie di mappatura dei dati possono fare un uso inefficiente di SQL.

Per il puro parametro "numero di visite", la domanda è in realtà la velocità con cui funziona il sistema di templating HTML. Quindi la domanda è: quante pagine puoi rendere al secondo? Vorrei fare di questo il parametro principale per determinare quanto sarebbe buono un sistema in scala.

Naturalmente, pagine diverse possono avere costi diversi; per alcuni, è possibile utilizzare la memorizzazione nella cache, ma non per gli altri. Quindi, nel misurare la scalabilità, dividi le tue 1 milione di visite in pagine economiche e costose e misurale separatamente. Insieme, dovrebbero fornire una buona stima del carico che il sistema può assumere (o il numero di sistemi necessari per soddisfare la domanda).

C'è anche il problema dell'uso della memoria. Se si dispone dei dati in SQL, ciò non dovrebbe essere importante, ma con la memorizzazione nella cache, potrebbe essere necessario prendere in considerazione anche la scalabilità. utilizzo della memoria principale.

4

IMHO Non penso che il costo del ridimensionamento sarà diverso tra questi tre perché nessuno di essi ha "batterie di scalabilità" inclusi. Non vedo grandi differenze architettoniche tra queste tre scelte che potrebbero causare una differenza significativa nel ridimensionamento.

In altre parole, l'architettura dell'applicazione domina il modo in cui l'applicazione viene ridimensionata indipendentemente da quale delle tre lingue.

Se è necessario memorizzare la cache, si utilizzerà almeno memcached (o qualcosa di simile che si interfaccia con tutte e tre le lingue). Forse aiuterai la tua scalabilità usando nginx per servire direttamente da memcache, ma questo ovviamente non cambierà le prestazioni di php/perl/python/ruby.

Se si utilizza MySQL o Postgresql, è ancora necessario progettare correttamente il database per il ridimensionamento indipendentemente dalla lingua dell'app e qualsiasi strumento utilizzato per avviare il clustering/mirroring si troverà al di fuori della propria app.

Penso che in termini di utilizzo della memoria Python (con mod_wsgi daemon mode) e Ruby (enterprise ruby ​​con passeggero/mod_rack) abbiano impronte decenti almeno paragonabili a PHP in fcgi e probabilmente meglio di PHP in mod_php (cioè apache MPM prefork + php in tutti i processi di apache fa schifo molta memoria).

Dove questa domanda potrebbe essere interessante è cercare di confrontare quelle 3 lingue con qualcosa come Erlang in cui si suppone abbiano scalabilità incorporata a basso costo automaticamente in tutti i processi di Erlang, ma anche in questo caso si avrà un collo di bottiglia del database RDBMS a meno che la tua app non si adatti perfettamente a uno dei database di Erlang come fare le cose, ad es CouchDB.

1

Purtroppo, non conosco alcun confronto di costi tra Rails, PHP e Django. Ma conosco un confronto dei costi di alcuni Java Web Framework: Spring (9k $), Wicket (59k $), GWT (6k $) e JSF (49k $).

avete la conferenza originale qui:

http://www.devoxx.com/display/DV11/WWW++World+Wide+Wait++A+Performance+Comparison+of+Java+Web+Frameworks

Qui è presente un post su di esso (più breve):

http://blog.websitesframeworks.com/2013/03/web-frameworks-benchmarks-192/

Se volete provare a infere su questo costo . Si potrebbe attraversare questi dati con l'bencharmk proposta da Techempower:

http://www.techempower.com/benchmarks/

Quindi, se si sa primavera è piuttosto a buon mercato confrontare wicket ed il Django/Rails avere segni peggiori nei benchmark rispetto Wicket e primavera, probabilmente significa rappresenteranno un costo più alto.

Spero che aiuti.

Problemi correlati