delayed_jobs vs Resque vs beanstalkd?

Question

Ecco le mie esigenze:

• Enqueue_in (10.hours, ...) (sintassi DJ è perfetto.)
• lavoratori si moltiplicano, in concomitanza. (Resque o beanstalkd sono buone per questo, ma non DJ)
• deve gestire push e pop di 100 posti di lavoro al secondo. (Ho bisogno di eseguire un test per assicurarsi che, ma penso DJ non può gestire così tanti posti di lavoro)

Resque e beanstalkd non fare l'enqueue_in.

C'è un plugin (resque_scheduler) che lo fa, ma non sono sicuro di come stabile sia.

Il nostro ambiente è su Amazon, e hanno srotolato il beanstalkd gratis per chi ha amazon casi, che è un vantaggio per noi, ma sono ancora non sicuro di quello che è l'opzione migliore qui.

Noi usiamo rotaie 2.3, ma stiamo portando a velocità per rotaie 3.0.3 presto.

Ma che cosa è la mia scelta migliore qui? Mi sto perdendo un altro gioiello che fa questo lavoro migliore?

mi sento la mia unica opzione che in realtà funziona ora è il resque_scheduler.

Modifica:

Sidekiq ( https://github.com/mperham/sidekiq ) è un'altra opzione che si dovrebbe check it out.

Answer 1

Per i miei progetti che si sentirà molto comfortbale con collectiveidea / delayed_job in rails2 e 3. Non so beanstalkd, ma cercherò presto :-). Ho seguito le indicazioni contenute nella documentazione Resque. Io segnalarlo.

Resque vs DelayedJob

Come si confronta con Resque DelayedJob, e perché si dovrebbe scegliere uno sopra l'altro?

• Resque supporta più code
• supporti DelayedJob grana più fine priorità
• lavoratori Resque sono resistenti a perdite di memoria / gonfiare
• lavoratori DelayedJob sono estremamente semplici e facili da modificare
• Resque richiede Redis
• DelayedJob richiede ActiveRecord
• Resque può inserire solo gli oggetti JSONable Ruby on una coda come argomenti
• DelayedJob può inserire qualsiasi oggetto Ruby on la sua coda come argomenti
• Resque include un'applicazione Sinatra per monitorare quello che sta succedendo
• DelayedJob può essere interrogato da dentro la tua applicazione Rails, se si desidera aggiungere un'interfaccia

Se stai facendo lo sviluppo Rails, che già dispone di un database e di ActiveRecord. DelayedJob è super facile da installare e funziona alla grande. GitHub ha utilizzato per molti mesi per elaborare quasi 200 milioni di posti di lavoro.

Scegli Resque se:

• È necessario più code
• Non si cura / antipatia priorità numerici
• Non è necessario persistere ogni oggetto Rubino mai
• Hai potenzialmente enormi code
• Vuoi vedere cosa sta succedendo
• Ci si aspetta un sacco di fallimento / caos
• È possibile impostare Redis
• Non sta eseguendo a corto di RAM

Scegliere DelayedJob se:

• Vi piace priorità numerici
• Non stai facendo un gigantesco ammontare di posti di lavoro ogni giorno
• I tuoi soggiorni coda piccola e agile
• Ci non è un fallimento molto / caos
• Si vuole buttare facilmente qualsiasi cosa sulla coda
• Non si desidera impostare Redis

Scegli Beanstalkd se:

• Vi piace priorità numerici
• Si desidera estremamente veloce coda
• Non si vuole perdere si RAM
• Si vuole servire elevato numero di posti di lavoro
• Stai bene con JSONable Rubino oggetti in una coda come argomenti
• È necessario più code

In nessun modo è Resque una "migliore" DelayedJob, quindi assicuratevi di scegliere lo strumento che è meglio per la vostra applicazione.

Un bel confronto tra la fila velocità backend :

                 enqueue                work
-------------------------------------------------
delayed job |   200 jobs/sec     120 jobs/sec
resque      |  3800 jobs/sec     300 jobs/sec
rabbitmq    |  2500 jobs/sec    1300 jobs/sec
beanstalk   |  9000 jobs/sec    5200 jobs/sec

Have a nice day!

P.S. C'è un Railscast su resque , Delayed Job ( rivisto versione ) e Beanstakld . Date un'occhiata!

P.P.S. Il mio preferito è choiche ora Sidekiq (molto semplice, veloce ed efficiente per lavori semplici), dare un'occhiata a questa pagina per il confronto.

Answer 2

Amazon fagiolo magico non è Beanstalkd.

Beanstalkd - la coda - non hanno un lavoro in ritardo, che non saranno riservati fuori dalla coda fino a quando il dato numero di secondi sono passati. Se questo è ciò che significa Enqueue_in(10.hours, ... ), allora è zucchero sintattico per calcolare il numero di secondi, e non fare un lavoro disponibile fino ad allora.

Answer 3

Solo una piccola nota: delayed_job 3.0+ supporti chiamati code

object.delay(:queue => 'tracking').method    
Delayed::Job.enqueue job, :queue => 'tracking'    
handle_asynchronously :tweet_later, :queue => 'tweets'