Attività di rake multithreading

Question

Sto scrivendo un'attività di rake che verrebbe chiamata ogni minuto (probabilmente ogni 30 secondi in futuro) da Whenever e contatta un endpoint API di polling (per utente nel nostro database). Ovviamente, questo non è efficiente eseguito come un singolo thread, ma è possibile il multithread? In caso contrario, esiste una buona libreria HTTP basata su eventi che sarebbe in grado di portare a termine il lavoro?

Answer 1

Sto scrivendo un compito rastrello che sarebbe stato chiamato ogni minuto (possibilmente ogni 30 secondi in futuro) di Ogni volta che

Attenzione di Rails tempi di avvio, potrebbe essere meglio utilizzare un forking modello come Resque o Sidekiq, Rescue fornisce https://github.com/bvandenbos/resque-scheduler che dovrebbe essere in grado di fare quello che ti serve, non posso parlare di Sidekiq, ma sono sicuro che ha qualcosa di simile disponibile (Sidekiq è molto più recente di Resque)

Ovviamente, questa operazione non è efficiente come un singolo thread , ma è possibile il multithread? In caso contrario, esiste una buona libreria HTTP basata su eventi che sarebbe in grado di portare a termine il lavoro?

io suggerirei di guardare ActiveRecord's find_each per suggerimenti su come rendere il processo più efficiente finder, una volta che hai i batch si può facilmente fare qualcosa usando le discussioni come:

# 
# Find each returns 50 by default, you can pass options 
# to optimize that for larger (or smaller) batch sizes 
# depending on your available RAM 
# 
Users.find_each do |batch_of_users| 
    # 
    # Find each returns an Enumerable collection of users 
    # in that batch, they'll be always smaller than or 
    # equal to the batch size chosen in `find_each` 
    # 
    # 
    # We collect a bunch of new threads, one for each 
    # user, eac 
    # 
    batch_threads = batch_of_users.collect do |user| 
    # 
    # We pass the user to the thread, this is good 
    # habit for shared variables, in this case 
    # it doesn't make much difference 
    # 
    Thread.new(user) do |u| 
     # 
     # Do the API call here use `u` (not `user`) 
     # to access the user instance 
     # 
     # We shouldn't need to use an evented HTTP library 
     # Ruby threads will pass control when the IO happens 
     # control will return to the thread sometime when 
     # the scheduler decides, but 99% of the time 
     # HTTP and network IO are the best thread optimized 
     # thing you can do in Ruby. 
     # 
    end 
    end 
    # 
    # Joining threads means waiting for them to finish 
    # before moving onto the next batch. 
    # 
    batch_threads.map(&:join) 
end 

Questo avrà inizio non più di batch_size di thread, in attesa che ogni batch_size termini.

Sarebbe possibile fare qualcosa di simile, ma poi si avrà un numero incontrollabile di thread, c'è un'alternativa da cui si potrebbe trarre vantaggio qui, diventa molto più complicato tra cui un ThreadPool e una lista condivisa di lavoro per faccio, l'ho postato come a Github quindi non per spam stackoverflow: https://gist.github.com/6767fbad1f0a66fa90ac

Answer 2

Vorrei suggerire l'utilizzo di sidekiq che è ottimo per il multithreading. È quindi possibile accodare lavori separati per utente per il polling dell'API. clockwork può essere utilizzato per rendere ricorrenti i lavori che si accodano.