Qual è lo stato attuale dei processi di threading, concorrenza e fork, in Ruby on Rails?

Question

Ruby on Rails non fa molto bene le risposte alle richieste multithread, o almeno non ActiveRecord.

L'idea di una sola richiesta-risposta attiva contemporaneamente può essere una seccatura durante la creazione di applicazioni Web che interrompono un comando shell che impiega molto tempo a finire.

Cosa mi piacerebbe sono alcune delle tue opinioni su questo tipo di configurazioni? Rails forse non è adatto per alcune applicazioni?

Inoltre, quali sono le circostanze attuali in merito alla concorrenza in Ruby on Rails? Quali sono le migliori pratiche. Ci sono soluzioni alternative alle carenze?

Answer 1

Attualmente Rails non gestisce le richieste simultanee all'interno di un singolo processo Ruby MRI (Matz Ruby Interpreter). Ogni richiesta è essenzialmente racchiusa in un mutex gigante. Un sacco di lavoro è stato fatto per rendere il prossimo thread di Rails 2.2 sicuro, ma non ne trarrai molti benefici quando girerai con Ruby 1.8x. Non posso commentare se Ruby 1.9 sarà diverso perché non ne ho molta familiarità, ma probabilmente non avrei pensato.

Un'area che sembra molto promettente a questo proposito è l'esecuzione di Rails usando JRuby, perché la JVM è generalmente riconosciuta come brava nel multi-threading. Arun Gupta di Sun Microsystems ha dato alcuni dati interessanti sulle prestazioni su questa configurazione su RailsConf Europe di recente.

Answer 2

Neverblock consente la funzionalità non bloccante senza modificare il modo in cui scrivi i programmi. È davvero un progetto interessante, ed è stato backportato per lavorare su Ruby 1.8.x (si basa sulle fibre di Ruby 1.9). Funziona con PostgreSQL e MySQL per eseguire query non bloccanti. I benchmark sono pazzi ...

Answer 3

Matz's Ruby 1.8 utilizza thread verdi e Matz's Ruby 1.9 utilizzerà O / S nativi filettature. Altre implementazioni di Ruby 1.8, come JRuby e IronRuby, utilizzano thread O / S nativi. YARV, abbreviazione di Yet Another Ruby VM, utilizza anche thread O / S nativi ma ha un blocco dell'interprete globale per garantire che sia in esecuzione un solo thread Ruby in un determinato momento.

Answer 4

Se ciò che si esegue nella shell non è necessario per il rendering della pagina (ad es. si stanno solo attivando attività di manutenzione o altro), è necessario avviarle come processi in background. Guarda storno e workling.

Se ciò non si applica alla tua situazione, dovrai assicurarti che vengano eseguite più istanze dei server delle app. Tradizionalmente le persone inizierebbero più istanze di Mongrel. Ma ora direi che il modo più semplice per avere una configurazione solida è di gran lunga usando Phusion Passenger . È un modulo Apache che ti consente di specificare facilmente quante istanze (min e max) dei tuoi server di app vuoi avere in esecuzione. Il passeggero fa il resto. E se ricordo bene, non fa stupido round robin per inviare richieste. Penso che sia per disponibilità.

Answer 5

Ruby 1.9 aggiunge fibre leggere:

http://www.infoq.com/news / 2007/08 / ruby-1-9-fibre