Charger les modèles Ruby on Rails sans charger l'intégralité du framework

Question

Je cherche à créer un démon personnalisé qui exécutera diverses tâches de base de données telles que le retardement des mailings et des notifications utilisateur (chaque avis est une ligne distincte dans la table des notifications). Je ne veux pas utiliser script/runner ou rake pour effectuer ces tâches car il est possible que certaines tâches nécessitent uniquement la création d'une ou deux lignes de base de données ou de milliers de lignes en fonction de la tâche. Je ne veux pas de frais généraux de lancer un processus de rubis ou de charger l'ensemble du cadre de rails pour chaque opération. Je prévois de garder ce démon en mémoire à plein temps.

Pour créer ce démon, je voudrais utiliser mes modèles de mon application ruby ​​on rails. J'ai un certain nombre de plugins de rails tels que acts_as_tree et AASM que j'aurai besoin de charger si je dois utiliser les modèles. Certains des plugins que je dois charger sont des hacks personnalisés sur ActiveRecord :: Base que j'ai créés. (Je suis prêt à accepter la suppression ou recoder certains des plugins si elles ont besoin de composants d'autres parties de rails.)

Mes questions sont

• Est-ce une bonne idée?
• Et - Est-ce possible de faire d'une manière qui ne m'a pas inclus manuellement chaque fichier dans mes modèles et plugins?

Si pas une bonne idée

• Qu'est-ce qu'une bonne alternative?

(je ne suis pas accolées à faire écrire mes propres requêtes SQL, mais je dois ajouter des contraintes de base de données et un utilisateur séparé pour le démon afin d'éviter tout accident stupide. Compte tenu de mon manque de familiarité avec la configuration d'une base de données, je Nous aimerions utiliser l'enregistrement actif comme une béquille.)

Answer 1

Il semble que votre souci est que vous ne voulez pas payer le temps ou le coût en mémoire pour faire tourner la pile de rails chaque fois que votre tâche doit être exécutée ? Si vous envisagez de garder le daemon en fonctionnement à temps plein, vous pouvez simplement démoniser un processus qui a chargé votre pile de rails et ne devrez payer cette pénalité de mémoire ou de temps pour charger la pile qu'une seule fois, le démon démarre.

Async_worker est un bon exemple de ce genre de modèle: Il utilise Beanstalk pour transmettre des messages à un ou plusieurs processus de travail qui sont chacun juste daemons qui ont chargé les rails pile complète. Une chose à laquelle vous devez faire attention est que vous devrez redémarrer vos processus démonisés lors d'un déploiement afin qu'ils puissent recharger votre pile de rails mise à jour. J'utilise ceci pour une application url-shortener (le seul processus de travail asynchrone que j'exécute est en attente de sauvegarder les données de référence après que le visiteur soit redirigé), et ça fonctionne bien, j'ai juste une tâche capistrano after:deploy qui redémarre n'importe quel async ouvriers).

Answer 2

Vous pouvez charger un aspect de Rails tel qu'ActiveRecord mais lorsque vous y arrivez, le coût de chargement de l'environnement entier n'est pas beaucoup plus important que le chargement d'ActiveRecord lui-même. Vous pourriez certainement ne pas inclure des aspects comme ActionMailer ou certains des bits latéraux, mais je vais deviner que vous ne verrez pas beaucoup de succès. Ce que je suggérerais plutôt est courir soit par l'intermédiaire de coureur/console comme vous avez dit que vous ne vouliez pas mais plutôt que le bootstrap chaque fois, essayiez de faire des choses en lots ainsi vous faites 1000 à la fois au lieu de 1.Il y a beaucoup de projets qui utilisent ce style, certains des envois en nombre viennent à l'esprit si vous voulez des exemples. DJ (delayed_job) fait la même chose en stockant un peu dans la base de données en disant que ce code doit être exécuté à un moment donné en utilisant la pile d'environnement mais il essaye de grouper autant que possible pour gagner.

L'autre option consiste à avoir une application mini-rails persistante avec autant de ressources que possible afin que l'utilisation de la mémoire soit plus faible, ce qui permet d'écouter les demandes et d'enchérir quand vous le souhaitez. Ce serait plus de mémoire mais la latence du bootstrapping serait essentiellement annulée.

Enfin, après coup, ce serait un excellent usage pour Postgres.