Entretien des tâches de fond sur un grand site

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/13711

Question

Nous avons affaire à un problème intéressant sur StackOverflow.

Nous avons tout un tas de petits « besoins à faire bientôt-ish » tâches. Un exemple est mise à jour « Questions connexes » listes. Ce que nous avons fait dans le passé est de ferroutage ces tâches les charges de ONTO page de certains utilisateurs.

Cela n'a jamais été idéal, mais il n'a pas été vraiment perceptible. Maintenant que le SO a dépassé la barre des 1.000.000 question, les utilisateurs malchanceux commencent à le sentir.

La solution naturelle est de pousser effectivement ces tâches en arrière-plan. Il existe deux grandes façons de le faire je compte.

1. Dans IIS comme une coutume thread-piscine / travail-Queue

En fait, nous tourner un peu (non ThreadPool , afin de ne pas interférer avec les threads IIS) et ont des collections les services qu'il leur que nous sommes bousculade funcs dans.

Le grand pro est ici la simplicité. Nous n'avons pas à vous soucier de quoi que ce soit marshaling, et nous ne devons nous assurer un service externe et qu'il répond.

ont également accès à l'ensemble de notre code commun.

Le con est, bien que nous ne devrions pas utiliser des fils de fond. Les objections que je connais sont centrées autour de faim IIS (si vous utilisez ThreadPool) et les fils au hasard qui meurent (à cause du recyclage AppPool).

Nous avons l'infrastructure existante pour faire la mort de fil au hasard un non-problème (il est possible de détecter une tâche a été abandonnée, essentiellement), et en limitant le nombre de threads (et à l'aide de fils non ThreadPool) n'est pas difficile non plus.

Suis-je manque d'autres objections à IIS dans le processus de mise en commun fil / travail-files d'attente?

Transféré à StackOverflow , car il n'a pas vraiment abordé ici.

2. En tant que service

Soit une solution tierce, ou un sur mesure.

En fait, nous aurions maréchal une tâche à travers la frontière de processus pour un service et tout simplement oublier. On peut supposer que nous liant un code, ou limité à SQL brute + une chaîne de connexion.

Le pro est que son la « bonne façon » de le faire.

Les inconvénients sont que nous sommes soit très limités dans ce que nous pouvons faire, ou nous allons devoir travailler un système pour maintenir ce service en phase avec notre base de code. Nous avons aussi besoin de brancher toutes nos erreurs et l'exploitation forestière surveillance en quelque sorte, que nous obtenons gratuitement avec l'option « Dans IIS ».

Y at-il d'autres avantages ou des problèmes avec l'approche de service?

En un mot, sont là des problèmes insurmontables et unforseen cette approche make # 1 ingérable et si oui sont là de bons services de tiers, nous devrions examiner la démarche no 2?

Était-ce utile?

La solution

A quelques semaines j'ai demandé une question similaire sur le SO. Dans une coquille de noix, mon approche depuis un certain temps a été de développer un service Windows. J'utiliser NServiceBus (essentiellement MSMQ sous les couvertures) au maréchal des demandes de mon application Web pour mon service. Je l'habitude d'utiliser WCF mais obtenir une transaction distribuée pour fonctionner correctement sur WCF semblait toujours comme une douleur dans le cul. NServiceBus a fait le tour, je pouvais valider les données et créer des tâches dans une transaction et ne vous inquiétez pas si mon service était opérationnel au moment. A titre d'exemple simple, si jamais je devais envoyer un e-mail (par exemple un e-mail d'inscription) Je créerais le compte utilisateur et de déclencher un signal à mon service Windows (pour envoyer l'e-mail) dans une transaction. Le gestionnaire de messages sur le côté service reprendrait le message et le processus en conséquence.

Depuis ASP .NET 4.0 et AppFabric ont été libérés, il y a un certain nombre d'alternatives viables au mécanisme ci-dessus. Revenant à la question je l'ai mentionné ci-dessus, nous avons maintenant AppInitialize de AppFabric (via net.pipe), ainsi que la fonction de démarrage automatique ASP .NET 4.0 qui rendent le développement des services Windows en tant qu'applications Web une alternative viable. J'ai commencé à le faire dès maintenant pour plusieurs raisons (le plus grand déploiement d'un être n'est plus une douleur dans le cul):

  1. Vous pouvez développer une interface Web sur votre service (car il est en cours d'exécution comme une application Web). Cela est extrêmement utile de voir ce qui se passe lors de l'exécution.
  2. Votre modèle de déploiement pour vos applications Web fonctionnera pour votre application de service.
  3. IIS offre quelques fonctionnalités soignées pour le traitement des pannes d'application (similaire à certains égards à un service Windows).
  4. Les développeurs Web sont très familiers avec le développement d'applications Web (naturellement), la plupart ne savent pas beaucoup sur les meilleures pratiques lors de l'élaboration d'un service Windows.
  5. Il fournit un certain nombre d'alternatives à l'exposition d'une API pour d'autres applications à consommer.

Si vous allez dans cette voie (pardonnez-moi pour copier et coller de mon message original) Je certainement envisager de faire tourner la logique de fond dans une application Web distincte. Il y a plusieurs raisons pour cela:

  1. Sécurité . Il peut y avoir un modèle de sécurité différent pour l'interface utilisateur d'afficher des informations sur les processus d'arrière-plan en cours d'exécution. Je ne veux pas exposer cette interface à quelqu'un d'autre mais l'équipe ops. En outre, l'application peut également fonctionner comme un autre utilisateur qui a un ensemble élevé d'autorisations.
  2. Maintenance . Ce serait génial d'être en mesure de déployer des modifications à l'application d'hébergement des processus d'arrière-plan, sans impact sur l'utilisateur en utilisant le site Web frontal.
  3. Performance . Avoir l'application séparée des principales demandes des utilisateurs de traitement de site, on entend des fils de fond ne va pas diminuer la capacité de IIS pour gérer la file d'attente de requête entrante. En outre, l'application du traitement des tâches de fond pourrait être déployé sur un serveur distinct si nécessaire.

Faire cela revient à l'aspect marshaling. WCF, NServiceBus / RabbitMQ / ActiveMQ etc., la vanille MSMQ, API RESTful (pensez MVC) sont toutes les options. Si vous utilisez Windows Workflow 4.0, vous pouvez exposer un point de terminaison d'hôte qui votre application Web pourrait consommer.

L'approche d'hébergement Web pour les services est encore assez nouveau pour moi, seul le temps dira si c'était le bon choix. Jusqu'à présent, si bien que. Soit dit en passant, si vous ne voulez pas utiliser AppFabric (je ne pouvais pas parce que, pour une raison bizarre, Windows Server Web Edition est pas pris en charge), la capacité de démarrage automatique mentionné dans le poste de Gu fonctionne bien. Restez à l'écart du fichier applicationhost.config cependant, tout ce poste est possible de configurer via la console (éditeur de configuration au niveau du serveur principal) IIS.

Note: Iavait d'abord affiché quelques liens plus dans ce message mais hélas, ceci est mon premier poste à cet échange et un seul lien est pris en charge! Il y avait en fait deux autres, pour les amener Google « Mort aux services Windows ... Vive AppFabric! » et "auto-start-asp-net-applications". Désolé à ce sujet.

Autres conseils

Il est en fait une troisième voie dans Windows pour exécuter les services de base, et il est très fréquent dans le monde UNIX. La troisième voie est un travail de CRON qui exécute un morceau de votre infrastructure. Dans Windows, il est connu sous le nom task scheduler et est très commun pour le code en cours d'exécution sur une base régulière. Pour utiliser cela, vous créer une application en ligne de commande qui est exécutée sur un calendrier prédéfini. L'avantage de ceci est que vous n'avez pas à vous inquiéter si les séjours de processus en cours d'exécution et comme jusqu'à un service, parce que si elle échoue pour une raison quelconque, il suffit de commencer la prochaine fois.

En ce qui concerne les tâches spécifiques marshaling, vous avez vraiment besoin de stocker ces tâches dans une mémoire binaire persistante. Jusqu'à ce que l'application de ligne de commande les ramasse sur le stockage et les exécute. Je l'ai fait dans le passé en utilisant la base de données Cassandra en tant que fournisseur d'état de session pour bourrer les tâches de fond pour les utilisateurs spécifiques dans la base de données Cassandra, et ayant la ligne de commande les ramasser et de les exécuter pour l'utilisateur.

Cela peut ne pas être la solution marshaling typique, mais ça a très bien fonctionné pour moi et il est avéré être une solution très élégante, parce que les tâches planifiées ont survécu à des arrêts, des problèmes de réseau, et toute machine pourrait exécuter la tâche depuis il a été stockée de manière centralisée.

promotion éhontée, mais c'est mon projet et la solution que je viens brièvement exposé en détail est la raison pour laquelle j'ai créé le projet: http://github.com/managedfusion/fluentcassandra/

Cron + Web App

Ceci est une conception aguerrie que échelles horizontale avec votre batterie de serveurs Web et assure que vous utilisez la pile technologie web vous savez déjà.

Voici comment cela fonctionne:

  1. Créer un contrôleur / action dans votre application web pour gérer les tâches de fond prévues. Par convention, je l'appelle habituellement http://mydomain.com/system/cron la mienne.
  2. Pour plus de sécurité, cette action doit être verrouillé aux adresses IP authentifiées sur le réseau local.
  3. Sur une machine séparée, installez Wget et configurer un Scheduled tâche pour avoir wget chercher la ressource à l'étape 1. vous pouvez faire que la tâche aussi souvent que vous le souhaitez (I généralement opter pour 30 secondes). Ne pas oublier de passer l'argument cookie approprié wget afin qu'il authentifie à votre application web.
  4. Pour la redondance, vous pouvez également installer une seconde prévue wget sur une deuxième machine.

Hourra! Maintenant, vous avez un itinéraire qui sera appelé toutes les 30 secondes. Et si la demande prend 5 minutes à traiter, personne ne se souciera, parce qu'il ne fait pas partie de la demande de page d'un utilisateur.

L'action cron finit recherche très simple: il a une liste des méthodes d'exécution sur une certaine fréquence. Lorsqu'une demande arrive, il voit s'il y a une méthode qui doit être exécuté et appelle la méthode appropriée. Cela signifie que vous pouvez contrôler le calendrier dans votre base de données , où vous avez probablement déjà beaucoup d'autres données importantes de configuration pour votre site.

Plus important encore (pour vous), cela signifie que vos emplois ne doivent pas être appelés à un horaire fixe. Vous pouvez écrire toute logique que vous voulez pour déterminer quand exécuter une méthode.

Avantages et inconvénients

Avantages
  • Vous êtes déjà très bon à l'écriture de code ASP.NET MVC, donc cela vous permet d'écrire vos tâches de fond dans la même plateforme que vous écrivez le reste de votre solution dans.
  • Les tâches sont exécutées dans le même contexte que votre application web, vous pouvez partager le cache et faire usage de méthodes d'aide qui existent déjà.
  • Si vous avez wget chercher un équilibrage de charge URI, vos tâches de fond sont à charge équilibrée maintenant aussi bien.
  • Déploiement simultané - vous n'avez pas à vous soucier de la synchronisation de votre application web avec votre logique de tâche de fond, parce qu'ils sont tous dans le même déploiement.
Les inconvénients
  • Au fil des ans, quelques personnes me l'ont dit cette conception est « très couplé », mais lorsqu'il est pressé, ils n'ont pas été en mesure d'expliquer pourquoi c'est une mauvaise chose.

Remarque: Si vous avez des questions ou des préoccupations, s'il vous plaît ajouter un commentaire . Je suis heureux d'élaborer.

J'ai essayé et utilisé à peu près toutes les manières possibles de faire cela dans mon application actuelle. J'ai commencé à faire la même chose que vous faites actuellement, ferroutage sur une demande de l'utilisateur pour remplir les données, puis en cache aller de l'avant. Je compris que c'était une mauvaise idée aussi (surtout que vous l'échelle à plusieurs serveurs Web, plus les utilisateurs prennent le coup).

J'ai aussi eu une tâche planifiée qui frappe une URL dans l'application ASP.NET - c'est une solution décente mais il commence à se décomposer la minute où vous l'échelle passé 1 serveur web

.

Actuellement, j'utilise deux méthodes différentes, à la fois à l'aide Quartz.NET qui est une petite bibliothèque. La première est en cours d'exécution Quartz.NET en cours avec ASP.NET, il est installé dans le global.asax et exécute toutes les deux minutes. J'utilise ceci pour mettre à jour le cache ASP.NET hors bande qui est la seule raison pour laquelle il est exécuté dans le cadre d'ASP.NET.

La seconde est que je l'ai écrit une bibliothèque pour envelopper Quartz.NET appelé DaemonMaster - il est facile de déposer une DLL dans un répertoire et avoir exécuté dans un service Windows. Je l'ai trouvé permet d'éviter certaines des parties ennuyeux de travailler avec un service Windows et nettoie également le Quartz.NET api certains. Les services qui traversent DaemonMaster sont de deux saveurs différentes, les premiers sont des emplois qui ont besoin de courir tous les soirs ou tous les X minuts. Les autres emplois hors d'une travail file d'attente basée sur des données venant de l'application ASP.NET. L'application ASP.NET laisse tomber des objets JSON sur RabbitMQ et le sondage des services RabbitMQ ensuite traiter les données.

D'après ce que je vous suggère d'aller avec un service Windows (et vérifier DaemonMaster) et si besoin, utilisez une file d'attente comme RabbitMQ pour faire passer les données de l'application ASP.NET aux services - il a travaillé le meilleur de toutes ces solutions. Si vous êtes le cache de chargement en cours d'exécution puis dans ASP.NET est logique, sinon je ne pense pas que ce soit.

Je ferais de la bonne façon et d'avoir un service Windows en cours d'exécution qui surveille une « file d'attente ». Je dis « file d'attente », car la programmation w / MSMQ est semblable à coller pokers chaud dans vos globes oculaires.

Je suis tombé amoureux de la simplicité de

Nous avons été très heureux avec un / Service Bus Message Queue / approche service. L'architecture de base est la suivante.

Site Web envoie un message à la file d'attente 

bus.Send(new ProjectApproved()); // returns immediately

service Windows reçoit et traite un message dans son propre temps 

public class DoesSomethingAwesome : ConsumerOf<ProjectApproved>
{
   public void Consume(ProjectApproved Message)
   {
      // Do something "offline"
   }
}

L'avantage est qu'il n'y a pas de retard pour le service frontal que les utilisateurs sont connectés aussi. Le service Windows peut être arrêté et être mis à jour sans interruption sur le site principal. Plus il est extrêmement rapide .

Si vous ne pouvez pas stocker toutes vos données dans le message que vous pouvez toujours stocker et récupérer plus tard. Je suggère d'utiliser un mécanisme de stockage de documents tels que: RavenDB ou MongoDB où il est très direct pour stocker vos classes sans modifications.

Site Web envoie un message à la file d'attente 

// Save your object
store.Save(completeProject);

// Send a message indicating its ready to be processed
bus.Send(new ProjectApproved() { ProjectId = completeProject.Id });

service Windows reçoit et traite un message dans son propre temps 

public class DoesSomethingAwesome : ConsumerOf<ProjectApproved>
{
   public void Consume(ProjectApproved Message)
   {
      // Retrieve your object back
      var completeProject = store.Get(Message.ProjectId);
   }
}

Pour rendre les choses utilisation simple nous: Rhino et ESB Topshelf . La configuration est extrêmement simple et de mettre cela en place pour une application existante a prouvé prendre très peu de temps.

Je suis curieux de savoir pourquoi une combinaison des deux n'est pas une option viable. En ce moment, vous déclenchez emplois sur les pages vues, avec un peu de chance d'obtenir la sève attente coincé 10 secondes pour que la page à venir. Au moins c'est ma compréhension de votre méthode actuelle.

Toutefois, ces emplois prennent plus de temps et plus à courir que le site se développe, et vous ne voulez pas faire dérailler l'expérience utilisateur sur le site. Pas même pour quelques (ou peut-être beaucoup) les utilisateurs malchanceux à travers le jour, alors maintenant que vous pensez à la planification des travaux en arrière-plan.

Je ne vois pas pourquoi une course de travail d'arrière-plan à intervalles réguliers ne peuvent pas reproduire les visiteurs d'un. Maintenant, je ne suis pas un programmeur Windows, mais dans le monde Linux, je mis en place une tâche cron qui fonctionne à intervalles réguliers, et il aurait 2 lignes de code. 

#!/bin/bash
wget -O /dev/null http://stackoverflow.com/specially_crafted_url

Il combine les avantages des deux systèmes. Il est fait en arrière-plan. Il n'a pas d'effet utilisateurs. Il utilise encore une vue de la page pour lancer le travail. Je l'ai vu cette approche utilisée auparavant. Il a tendance à être le juste milieu entre les moyens simples de vieux, et les moyens plus complexes à venir sur la route.

Mise à jour

Je pense que vous pouvez contourner le problème d'équilibrage de charge en exécutant les coureurs de travail sur les serveurs Web eux-mêmes. Le coureur de l'emploi tire une URL de la file d'attente d'emploi, et fonctionne comme ceci: 

wget -O /dev/null http://localhost/specially_crafted_url

En raison de la nature des files d'attente emploi / messagerie, les emplois se répartis également entre les coureurs d'emploi, ce qui signifie que le specially_crafted_url est finalement réparti entre vos serveurs Web.

Je pense que la con avec l'approche de pur service est que vous avez le code dispersés dans le service et loin de l'application de base.

Voici ce que nous avons fait avec un grand fond emplois non sensibles au facteur temps, ce qui maintient le code ensemble et simplifie le service:

  1. Créer une file d'attente d'emplois (soit en mémoire ou DB, quelle que soit la persistance est nécessaire pour les types d'emplois)
  2. Créer un service web qui exécutera les travaux en attente
  3. app service mort simple qui appelle le service Web à un intervalle spécifié, laissez toutes les choses complexes (de recherche d'emploi et de l'exécution) au service Web dans votre base de code de base.

Encore plus simple, il suffit de faire l'appel dans une application de la console et utiliser Planificateur de tâches ou VisualCron pour le transformer en un « service ».

J'ai aimé Topshelf. Conserve la simplicité, mais font encore la bonne façon en cours d'exécution en tant que service Windows. Fondamentalement créer une application console, ajoutez environ 15-20 lignes de code, il installe en tant que service.

http://code.google.com/p/topshelf/

Que diriez-vous d'avoir un service Windows très simple qui fonctionne sur le serveur Web et frappe périodiquement une URL d'entretien qui fait vos tâches diverses. Faites-le étrangle la quantité de travail qu'il fait dans une requête donnée.

Je vais buck ici la tendance apparente et suggère d'aller pour le modèle en IIS. Je l'ai utilisé moi-même et ça fonctionne vraiment bien. Il est vraiment pas difficile à mettre en œuvre une classe thread piscine correcte (au fil des ans, j'ai prolongé mon fil classe piscine pour soutenir la création dynamique et la destruction de fils, une nouvelle tentative d'emplois, etc.). Les avantages sont:

  • Aucun service externe pour surveiller
  • Simplicité de mise en œuvre: pas de rassemblement inter-processus, pas suivi de travail avancé
  • Vous êtes toujours dans votre IIS processus, de sorte que vous pouvez faire tout votre habituelle exploitation forestière et ainsi de suite (pas besoin de plusieurs fichiers journaux)
  • Déploiement simplifié Considérablement (lorsque vous mettez à jour un service, vous devez arrêter le service, copiez les fichiers, démarrez le service - ce qui est, en plus de mises à jour habituelles au code de site)

A mon avis, une solution dans IIS est tout simplement la « prochaine étape » de ferroutage sur le travail de pages vues au hasard.

Resque est agréable. Ou même kthxbye si vous devez être avisé de la valeur résultante une fois qu'il est terminé.

Les deux basés Redis / Ruby tho.

Honnêtement, si vous faites une approche basée sur les services, il n'a vraiment pas besoin d'être super-intégré à votre plate-forme actuelle, que je me sens est un plus. J'espère que ce pourrait être un système set-and-forget qui fonctionnerait (avec le suivi d'un certain type) et des emplois complets. Je ne suis pas sûr qu'il doit être exécuté sur la même plate-forme du tout depuis sa juste mise à jour / modifier les informations de base de données.

Assez sûr que vous pourriez sortir avec beaucoup plus pour beaucoup moins si vous exploitez ce travail un peu vers une entité distincte, d'autant qu'il vous semble traiter des questions de filetage. Les deux Resque et kthxbye déplacer le traitement vers des processus séparés pour permettre le système d'exploitation pour gérer la concurrence.

Resque

kthxbye

J'utiliser un service WCF était hébergé l'écoute à une file d'attente MSMQ.

de Pro

  • fire and forget une façon dont les messages de l'application Web

  • MSMQ / WCF étranglement et ré-essai

  • livraison garantie; D

  • Gestion Dead Letter

  • Traitement réparti

  • WAS / MSMQ activation

Con

  • MSMQ (il est pas mort ... Et pourtant)

Le MSMQ dispose WCF rend l'utilisation de MSMQ vraiment sympa. Oui, vous saigne sur la configuration, mais les avantages l'emporteront sur le sacrifice.

Je l'ai rencontré ce deux ou trois fois lors du développement d'applications Web. Nous avons le résoudre en créant une application console Windows qui exécute la tâche et la création d'une tâche planifiée qui fonctionne tout aussi souvent faire réellement la tâche.

Vous pouvez shunter le travail sur un fil de fond (ou de fils de fond) en utilisant Rx et quelque chose comme ce qui suit: 

var scheduler = new EventLoopScheduler( SchedulerThreadName );
_workToDo = new Subject<Action>();
var queueSubscription = _workToDo.ObserveOn( scheduler ).Subscribe( work => work() );
_cleanup = new CompositeDisposable( queueSubscription, scheduler );

Pour utiliser: 

var work = () => { ... };
_workToDo.OnNext( work ); // Can also put on error / on complete in here

hôte tout ce que l'intérieur d'une classe qui il n'y a que jamais l'un des (alias un singleton, mais le faire correctement - utiliser vous pour déterminer conteneur IoC le mode de vie).

Vous pouvez contrôler la taille du pool de threads etc en écrivant un planificateur personnalisé au lieu d'utiliser la EventLoopScheduler (qui gère un seul thread).

J'ai mis en œuvre ce genre de chose à quelques reprises. Sur les fenêtres, je mis en place un programme de ligne de commande python qui fait quelque chose à plusieurs reprises. Ce programme expose également une interface xmlrpc sur un port. Ensuite, un travail-tâche planifiée exécute toutes les minutes et interroge les interfaces xmlrpc. Si elles ne sont pas, il essaie de les lancer. Si elle ne peut pas, ça me e-mails.

L'avantage est que le travail qui fonctionne est pas ou cron calendrier lié. J'ai un travail de processus qui exécute toutes les secondes, mais attendra plus longtemps et plus entre un nouvel emploi selon qu'il avait du travail à faire. En outre, il peut être utilisé pour agir intelligemment en fonction du résultat. Vous avez une erreur 500? Vous avez un délai très long? Faire autre chose. Notifier un autre service. Etc.

Et les mêmes système fonctionne sur unix, avec des modifications mineures.

Je n'ai pas de réponse pour vous moi-même, mais le problème sonne une cloche - Je me souviens des gars au hasard la discussion sur un podcast une fois .

Spolsky: Je remarque un des des questions que vous avez posées sur le blog était comment devriez-vous gérer l'entretien tâches récurrentes en général?

Atwood: Oui.

Spolsky: Est-ce un juste caractérisation? Chaque site certaines tâches que vous ne voulez pas exécuter au moment où une page Web est chargement, mais vous voulez exécuter avec une certaine récurrence de quelque sorte.

Atwood: Ya, tâches de fond sorte de chose.

Spolsky: Ya, alors qu'est-ce que vous figure out?

Atwood: Eh bien, j'ai demandé à l'origine sur Twitter, parce que je voulais juste quelque chose de poids léger. Je vraiment ne voulait pas comme écrire une fenêtre un service. Je me sentais comme ça était hors de Code bande. De plus le code qui fait fait le travail est une page web en fait, parce que pour moi qui est une unité logique des travaux sur un site Web est une page Web. Ainsi, il est vraiment que nous appelons Rentrant dans le site Web, il est comme une autre demande dans le site, donc je il considéré comme quelque chose qui devrait ligne de séjour, et la petite approche que nous sommes arrivés qui a été recommandé à moi sur Twitter devait essentiellement ajouter quelque chose à la cache de l'application avec une échéance fixe, alors vous avez un retour d'appel ainsi quand il expires que appelle une fonction qui ne le travail vous ajouter de retour dans le cache avec la même échéance. Ainsi, il est un peu, peut-être « ghetto » est le mot juste.

Task Queue Java Présentation de l'API

Concepts Tâche Dans le traitement App Engine d'arrière-plan, une tâche est une description complète d'une petite unité de travail. Cette description se compose de deux parties:

  • Une charge utile de données qui paramétrise la tâche.
  • Code qui met en œuvre la tâche.

Tâches hors ligne Hooks Web Heureusement, l'Internet offre une solution de telle déjà, sous la forme d'une requête HTTP et sa réponse. La charge utile de données est le contenu de la requête HTTP, comme variables de formulaire Web, XML, JSON ou codées des données binaires. Le code de référence est l'URL elle-même; le code actuel est celui que les logique de serveur exécute dans la préparation de la réponse.

Do deux

Ajout d'un paramètre facultatif à la trajectoire de la question qui fait le travail que vous ferroutage actuellement sur les demandes des utilisateurs:

Entretien des tâches de fond sur un grand site

Créer une application console qui fonctionne sur chaque serveur et ouvre le journal IIS partagé binaire et lit à la fin actuelle du fichier. Utilisez un FileSystemWatcher ou un intervalle chronométré pour lire en avant pour les mises à jour comme IIS Collectionnez rincée le journal.

Utilisez ces informations pour déterminer quelles pages ont été en cours d'affichage.

Utilisez les urls page du journal analysable pour appeler la version « extrastuff » de l'URL sur localhost avec un objet webclient.

Ajoutez dans un code aux fichiers de commutation à la fin de chaque période de journal ou redémarrer le processus chaque période de journal.

Licencié sous: CC-BY-SA avec attribution
scroll top