2011-09-12 12 views
6

Stavo per iniziare a ricevere delayed_job e a funzionare sulla mia app quando ho trovato Appoxy SimpleWorker su Heroku.Delayed_job vs. Appoxy SimpleWorker

L'appoxy dice che è molto parallelo e che ridimensiona i lavoratori su e giù per minimizzare i costi. Tuttavia, mi sembra che con HireFire sia anche delayed_job. Ecco la mia domanda: quale sceglieresti: delayed_job + HireFire o SimpleWorker? (e perché?)

https://github.com/tobi/delayed_job
http://hirefireapp.com/
http://addons.heroku.com/simple_worker

La mia app è piccolo in questo momento - il volume è basso e il numero di applicazioni non dovrebbe essere straordinariamente alto per un bel po '.


In quale altro luogo si potrebbe mai sperare di ottenere risposte direttamente dai fondatori di entrambi i servizi? Grazie Michael e Travis!

risposta

5

Hi (questo è l'autore di HireFire)

cercherò di fornire alcune informazioni riguardanti le differenze tra i servizi. Non sono sicuro che ti aiuterà molto con la tua decisione, ma almeno è qualcosa!

Entrambe le soluzioni hanno un approccio diverso. HireFire si limita a ridimensionare il tuo web Heroku e le dinamiche dei lavoratori quando necessario. Non è necessario modificare nulla nella base di codice esistente, è sufficiente utilizzare il lavoro differito come di consueto. Non devi inviare/scrivere codice per un ambiente/piattaforma separato poiché è compilato come una lumaca sulla piattaforma di Heroku al momento dell'implementazione, e quando un nuovo dyno web o lavoratore si alza, lo slug viene usato e viene eseguito immediatamente (contenente tutto il tuo Variabili/impostazioni ENV

Lo svantaggio di HireFire rispetto a SimpleWorker è che HireFire è specifico di Heroku, quindi se mai si passa da Heroku ad esempio a EngineYard o a una casella VPS/dedicata, HireFire non funzionerà, ma SimpleWorker non è strettamente legato ad Heroku, anche se è probabilmente molto economico da ospitare su una piattaforma non PaaS (in confronto) quindi l'auto-ridimensionamento non sarebbe necessariamente necessario o quasi.

I è stato un cliente di SimpleWorker prima di sviluppare HireFire e la t Personalmente non mi piaceva il fatto che dovevo spingere parte del mio codice base a SimpleWorker, caricare nel mio ambiente Rails, riconnettermi al database dalla loro posizione di server e fare anche richieste API (?) ogni volta che volevo inviare un lavoro nel cloud (anche se ora potrebbe essere cambiato, quindi ti incoraggio a verificarlo da te stesso per essere sicuro, e forse non è un grosso problema per te come lo era per me). Per me è stato semplicemente troppo fastidio/tentativi ed errori ogni volta che volevo aggiungere nuove classi di lavoro e ho dovuto caricare tutti i singoli pezzi di codice dalla mia app e le mie gemme nei file della classe di lavoro stessa, mentre in esecuzione heroku ps:workers 1 o heroku ps:scale worker=2 creerebbe istantaneamente un lavoratore o due e avvierà l'elaborazione con zero modifiche al mio codice base, esattamente come quando lo eseguo localmente, poiché la mia intera app è già compilata come una lumaca su Heroku, lo usa solo, inclusa la mia ENV variabili e altre impostazioni/addon e si avvia velocemente.

Con HireFire è sufficiente aggiungere al vostro the hirefireapp gem Gemfile, aggiungere l'account Heroku/applicazioni all'interfaccia web HireFire, personalizzare le vostre esigenze di scala, distribuire l'applicazione a Heroku, e il gioco è fatto. Le tue applicazioni saranno costantemente monitorate e gestite/regolate (al minuto o meno).

HireFire non viene fornito con un'interfaccia slick con tabelle di lavori e il loro stato (in esecuzione/finito/non riuscito/ecc.) (Ha una panoramica della quantità corrente di dinamiche web/worker e lavori in coda per ogni app naturalmente, e le impostazioni di ridimensionamento personalizzabili), anche se questo è davvero il lavoro della biblioteca dei lavoratori per fornire tale funzionalità. Lavoro ritardato da quello che so ha una o due piccole interfacce di amministrazione che è possibile utilizzare (open source) che non sono legate a HireFire. Poiché SimpleWorker è sia un servizio in hosting, sia una libreria di lavoro in uno, fornisce anche un'interfaccia web.

HireFire ha la capacità di scalare anche i tuoi dynos web, non solo i tuoi dynos di lavoro.

Entrambi i servizi hanno la capacità di elaborare molti lavori in parallelo, poiché sia ​​Heroku che SimpleWorker sono pro-valutati al secondo da quello che ho capito. Quindi, se fai girare 10 dinamiche di lavoro per 6 secondi, o 1 per 60 secondi non fa differenza (o appena) in costi.

Non ho usato SimpleWorker dopo aver rilasciato HireFire da solo, che era un po 'di tempo fa quindi non sono sicuro di cosa altro SimpleWorker offre in questi giorni o se hanno semplificato il processo da allora, quindi non sono sicuro se il sopra le affermazioni che ho fatto sono ancora valide in questo momento.

Spero che questo aiuti!

+0

Michael, grazie mille per la tua risposta dettagliata! – sscirrus

+0

Prego! –

4

Hi (fondatore di SimpleWorker),

Michael ha riassunto abbastanza bene, ma io aggiungerò alcune differenze tra Heroku Lavoratori e SimpleWorker, non necessariamente HireFire.

  • Heroku ha un massimo di 24 lavoratori in una volta, il che significa che possono essere eseguiti solo 24 lavori contemporaneamente. Con SimpleWorker, puoi eseguire 1000 contemporaneamente (e altro man mano che cresciamo) senza modifiche.
  • Il ridimensionamento con SimpleWorker non richiede alcuno sforzo in modo che l'applicazione cresca, non sia necessario modificare nulla, basta continuare a lanciare più lavori a modo nostro.
  • Heroku addebita se si sta utilizzando o meno il lavoratore, SimpleWorker no. Questo è il problema risolto da HireFire, quindi non è un problema se usi HireFire.
  • SimpleWorker ha la pianificazione integrata in modo da non aver bisogno di cron o di altro per dare il via al lavoro.
  • interfaccia di gestione in modo da poter visualizzare tutti i tuoi lavoratori/posti di lavoro, trovare gli errori, ottenere avvisi di errore, visualizzare i registri per tutti i vostri lavori, ecc

Il rovescio della medaglia è che ci vuole un po 'più pensato di utilizzare SimpleWorker dal momento che non sta eseguendo il tuo ambiente Rails completo. Devi pensare ai tuoi lavoratori come entità separate che girano su un sistema diverso (quali sono). Per cose semplici come inviare un'e-mail in background o scaricare alcune cose dal tuo front end qui e là, i lavoratori di Heroku sono probabilmente una buona scelta. Se si eseguono lavori batch di grandi dimensioni, pianificazione, lavori di lunga durata, maggiore visibilità nei propri lavori, ecc., Si consiglia di provare SimpleWorker.

A proposito, abbiamo recentemente messo su alcuni nuovi video in modo da poter avere un'idea di come funziona e come è facile da usare: http://www.simpleworker.com/how_it_works/videos

Speranza che aiuta! E sentiti libero di farmi tutte le domande che hai su SimpleWorker.

+0

Grazie per aver riassunto le cose che ho perso! La pianificazione è sicuramente una bella caratteristica, mentre con Heroku pagherei $ 5 per cron, e non è così flessibile come quello che offre SimpleWorker. * Una cosa da notare è che, mentre il cursore di dyno web/worker di Heroku sull'interfaccia web scorre solo fino a 24, se usi la riga di comando (gemma di heroku) puoi far girare centinaia di lavoratori in pochi secondi. '$ heroku ps: scale worker = 100', ad esempio, imposterà la tua quantità di lavoro a' 100'. (Funziona con il loro nuovo stack "Celadon Cedar", non l'ho testato con lo stack precedente: "Badious Bamboo") –

+0

@ TRAVIS - grazie mille per la tua risposta! È bello sentire entrambi voi ragazzi. – sscirrus

+0

dovrebbe aver avuto il tempo di correggere la falsa dichiarazione di max 24 lavoratori ora ... – oma

0

utilizzare lavoro ritardato e poi hanno un compito rastrello che uso per scalare miei operai Heroku sulla base di se o non ci sono delayed_jobs nel mio database:

namespace :heroku do 
    namespace :workers do 
    desc "stop heroku workers" 
    task :stop do 
     p ['stopping workers for', CONFIG['heroku_project']] 
     Heroku::Client.new(ENV['HEROKU_EMAIL'], ENV['HEROKU_PASSWORD']).set_workers(CONFIG['heroku_project'], 0) 
    end 

    desc "start heroku workers" 
    task :start do 
     p ['starting workers for', CONFIG['heroku_project']] 
     Heroku::Client.new(ENV['HEROKU_EMAIL'], ENV['HEROKU_PASSWORD']).set_workers(CONFIG['heroku_project'], 1) 
    end 

    desc "starts workers if the are items in the queue, otherwise, stops them." 
    task :check_queue => :environment do 
     p ["Env: ", Rails.env] 
     count = DelayedJob.find_pending.count 
     p ['Pending delayed jobs: ', count] 
     if count > 0 
     Rake::Task['heroku:workers:start'].invoke 
     else 
     Rake::Task['heroku:workers:stop'].invoke 
     end 
    end 
    end 
end 

Con lo scheduler aggiuntivo posso controllare sui miei lavoratori ogni 10 minuti per mantenere bassi i costi.

Mi piace questa soluzione perché posso utilizzare DelayedJob (che conosco bene), e piuttosto che usare un altro plug-in o una terza parte tutto ciò di cui ho bisogno è un semplice compito di rake per limitare i costi su Heroku ed essenzialmente pagare solo per cosa Io uso.

+0

Ciao Gabeodess, mi piace il tuo approccio e voglio provarlo. Puoi per favore approfondire come farlo funzionare? Ho installato e funzionante DJ. Ho creato un compito di rake. Dove posso impostare ENV ['HEROKU_EMAIL'], ENV ['HEROKU_PASSWORD'] e CONFIG ['heroku_project']? Questi valori sono codificati? – Alex

Problemi correlati