2010-07-20 2 views
0

J'ai un modèle appelé Vote qui est changé très fréquemment (personnes votant sur des trucs). Je fais d'autres analyses après un vote, comme interpoler si l'électeur est un homme/une femme, quel âge, etc. Cela se traduit par la mise à jour des compteurs (votes adultes, votes des femmes, etc.) du même modèle.job d'arrière-plan vs after_save callback

Je me demande quelle est la meilleure façon de faire cela après le traitement de la sauvegarde, devrait-il s'agir d'un travail d'arrière-plan (j'utilise le plugin delayed_job) ou devrait-il être laissé comme rappel after_save? Quel est le meilleur du point de vue de la performance?

Je n'ai pas vraiment besoin d'afficher jusqu'à la deuxième dernière donnée à l'utilisateur (même le rappel after_save ne l'accomplit pas de toute façon).

Merci

+0

J'imagine que cela dépend de la mécanique de vos analyses? Est-ce un processus où il analyse une piscine entière, d'une manière qui serait moins chère à faire en masse qu'un enregistrement à la fois? – jasonpgignac

Répondre

1

Ma règle de base est que si elle prend plus d'une seconde (en moyenne) pour compléter - je shove à un travail de fond, sinon je garderai en synchrone. J'utilise delayed job, ça marche bien et je n'ai eu aucune raison de le laisser. J'ai eu un cas où je n'ai pas eu besoin de frapper la base de données dans le travail d'arrière-plan et j'ai utilisé une tâche de rake personnalisée, c'était très efficace et m'a sauvé devoir mettre en application un processeur de tâche d'arrière-plan.

+0

Deuxièmement cette approche avec un autre point: Si la tâche est non critique à l'utilisation de l'application OU l'utilisateur ne nécessite pas cette information mise à jour immédiatement delayed_job it. E par exemple, la mise à jour de systèmes tiers (facturation peut-être) d'un changement de nom d'utilisateur n'a aucune incidence sur la capacité de l'utilisateur à utiliser votre application, alors utilisez delayed_job –