Conseils d'architecture pour envoyer des mises à jour quotidiennes et hebdomadaires nécessitant un calcul

Question

J'ai une application Web qui envoie des mises à jour quotidiennes et hebdomadaires par courriel en fonction des autorisations des utilisateurs et de leurs paramètres d'alerte (quotidienne, hebdomadaire, mensuelle ou aucune) .

Chaque courriel vers un compte (qui aurait plusieurs utilisateurs) nécessite quelques appels et calculs de base de données. Ainsi, ces e-mails quotidiens/hebdomadaires sont très chers à mesure que le nombre d'utilisateurs augmente.

Existe-t-il des conseils généraux sur l'écriture de ces services? Je suis à la recherche de conseils ou de modèles d'architecture et pas vraiment de sujets tels que la délivrabilité des emails.

Answer 1

Je mettrais en cache les données avant le temps de traitement, si vous devez gérer de très grands ensembles d'informations, de sorte que les «calculs» DB peuvent être omis du cycle de traitement aux heures spécifiques. Rompre efficacement le traitement de sorte que la substance DB intensive soit effectuée un peu avant le traitement planifié de l'information. Quand vient le temps d'envoyer ces emails, j'imagine que vous pouvez traiter rapidement un très gros volume sans avoir besoin de beaucoup de réglages. Certes, je ne sais pas non plus de quel volume nous parlons ici.

Vous pouvez également filer l'application afin que vos données de traitement soient divisées en blocs logiques afin de réduire la quantité totale de données à traiter en une fois, en fonction de votre situation, cela pourrait simplifier les choses, normalement ne recommande pas d'entrer dans le fil, sauf s'il y a une bonne raison de le faire, et vous pouvez en avoir un. À tout le moins, utilisez un type de processus threadé en arrière-plan et désactivez-en quelques-uns en fonction de la façon dont vous segmentez vos données. Lorsque vous manipulez des exceptions, n'oubliez pas de laisser ceux qui apportent votre traitement, les gérer en enregistrant un tri ou une notification, puis passez à autre chose, vous ne voudriez pas d'erreur pour gâcher les choses pour un traitement ultérieur, je suis Bien sûr, vous avez probablement prévu pour cela. De plus, envoyez vos courriels de façon asynchrone pour qu'ils ne bloquent pas le traitement, c'est probablement une observation évidente, mais parfois des petites choses comme ça sont négligées et peuvent créer un goulot d'étranglement en envoyant beaucoup de courriels. En dernier lieu, testez-le avec une charge raisonnable au préalable et tirez dessus pour dépasser sa capacité.

Answer 2

Vous voudrez peut-être consulter les services de reporting SQL. Vous devrez peut-être traduire la configuration actuelle dans le format de rapport SQL, mais en retour vous aurez une interface administrative complète pour planifier la génération du rapport, permettant aux utilisateurs de modifier les entrées du rapport, la mise en cache des rapports historiques/actuels et le possibilité pour les utilisateurs de gérer leurs propres abonnements par courrier électronique.

http://msdn.microsoft.com/en-us/library/ms160334.aspx