Rails de fond/exigence de tâche asynchrone

Question

Nous avons une application de rails v2.3.8/apache/passager & ont des exigences asynchrones pour certaines tâches de longue durée. J'ai donc évalué certaines solutions autour de rails/ruby, je voulais revenir sur certaines des solutions.

J'ai aussi eu une question - sur comment les tâches d'arrière-plan/travailleurs sont engendrés. Compte tenu de nos rails application va courir à l'intérieur d'un conteneur apache/passager, est-ce que cela signifie que l'arrière-plan/travailleurs vont également engendrer un processus apache/passager ??

Y a-t-il un seul thread/processus de travail qui est lancé, ce qui signifie que les travaux seront traités en série ou que les travaux seront traités en parallèle? Je viens d'un environnement java/j2ee donc j'ai une bonne compréhension de Message Beans/threading, mais je n'ai aucune idée de la façon dont les solutions de messagerie sur rails fonctionnent?

Certains des paramètres sur la base desquels nous évaluons les solutions suivantes sont - Performance/échelle, les travailleurs distribués (en cours d'exécution sur les nœuds séparés), rails de support v3

• beanstalkd -> async-observateur

• Surprenante -> Workling

• ActiveMQ (Stomp) -> Workling/activeMessageing

• Delayed JOB

Answer 1

Phusion Passenger traite uniquement les requêtes Web. Les tâches en arrière-plan sont mieux gérées par un système de file d'attente externe. Vous en avez déjà mentionné quelques-uns. Ces systèmes de files d'attente s'exécutent en tant que processus complètement distincts et n'affectent pas les processus gérés par Phusion Passenger.

Answer 2

Je sais que c'est une réponse vraiment tardive, mais je suis confronté à des problèmes qui méritent probablement d'être pris en compte. Avec la reproduction intelligente des passagers, toutes les connexions doivent être réinitialisées juste après la création d'un nouveau fil. Voir http://www.modrails.com/documentation/Users%20guide%20Nginx.html#_smart_spawning_gotcha_1_unintential_file_descriptor_sharing pour référence.

Cela inclut également les connexions à la file d'attente. Assurez-vous de les réinitialiser avec le code approprié dans le bloc

PhusionPassenger.on_event(:starting_worker_process) do |forked| 
    if forked 
    ... 
    end 
end if defined?(PhusionPassenger) 

.