service Windows vs tâche planifiée

Quels sont les avantages et inconvénients des services Windows par rapport aux tâches planifiées pour exécuter un programme à plusieurs resockets (par exemple toutes les deux minutes)?

Mettre à jour:

Près de quatre ans après ma réponse initiale et cette réponse est très dépassée. Depuis l’arrivée de TopShelf , le développement des services Windows est devenu facile. Maintenant, il vous suffit de comprendre comment prendre en charge le basculement …

Réponse originale:

Je ne suis vraiment pas un fan de Windows Scheduler. Le mot de passe de l’utilisateur doit être fourni comme indiqué ci-dessus par @moodforall , ce qui est amusant lorsque quelqu’un modifie le mot de passe de cet utilisateur.

L’autre inconvénient majeur de Windows Scheduler est qu’il fonctionne de manière interactive et non en tant que processus d’arrière-plan. Lorsque 15 fenêtres MS-DOS s’affichent toutes les 20 minutes au cours d’une session RDP, vous ne pouvez pas les installer en tant que services Windows.

Quel que soit votre choix, je vous recommande de séparer votre code de traitement en un composant différent de l’application console ou du service Windows. Vous avez ensuite le choix d’appeler le processus de travail à partir d’une application console et de le connecter à Windows Scheduler ou d’utiliser un service Windows.

Vous constaterez que la planification d’un service Windows n’est pas amusante. Un scénario assez courant est que vous avez un long processus à exécuter périodiquement. Cependant, si vous traitez une queue, vous ne souhaitez pas que deux instances du même agent traitent la même queue. Vous devez donc gérer le minuteur pour vous assurer que votre long processus d’exécution a dépassé l’intervalle de temps imparti. Il ne redémarre pas tant que le processus existant n’est pas terminé.

Après avoir écrit tout cela, vous pensez, pourquoi ne pas utiliser Thread.Sleep? Cela me permet de laisser le thread en cours d’exécution continuer jusqu’à ce qu’il soit terminé et l’intervalle de pause entre en jeu, le thread s’endort et redémarre après le temps requirejs. Soigné!

Ensuite, vous lisez tous les conseils sur Internet avec beaucoup d’experts qui vous disent que c’est vraiment une mauvaise pratique de programmation:

http://msmvps.com/blogs/peterritchie/archive/2007/04/26/thread-sleep-is-a-sign-of-a-poorly-designed-program.aspx

Donc, vous vous gratterez la tête et vous vous demanderez, WTF, Annuler les paiements en attente -> Oui, j’en suis sûr -> Annulez tout le travail d’aujourd’hui … putain, putain, putain ….

Cependant, j’aime ce modèle, même si tout le monde pense que c’est de la merde:

Méthode OnStart pour l’approche à un seul thread.

protected override void OnStart (ssortingng args) { // Create worker thread; this will invoke the WorkerFunction // when we start it. // Since we use a separate worker thread, the main service // thread will return quickly, telling Windows that service has started ThreadStart st = new ThreadStart(WorkerFunction); workerThread = new Thread(st); // set flag to indicate worker thread is active serviceStarted = true; // start the thread workerThread.Start(); } 

Le code instancie un thread séparé et lui associe notre fonction worker. Ensuite, il lance le thread et laisse l’événement OnStart se terminer, afin que Windows ne pense pas que le service est bloqué.

Méthode de travail pour l’approche à un seul thread.

 ///  /// This function will do all the work /// Once it is done with its tasks, it will be suspended for some time; /// it will continue to repeat this until the service is stopped ///  private void WorkerFunction() { // start an endless loop; loop will abort only when "serviceStarted" // flag = false while (serviceStarted) { // do something // exception handling omitted here for simplicity EventLog.WriteEntry("Service working", System.Diagnostics.EventLogEntryType.Information); // yield if (serviceStarted) { Thread.Sleep(new TimeSpan(0, interval, 0)); } } // time to end the thread Thread.CurrentThread.Abort(); } 

Méthode OnStop pour l’approche à un seul thread.

 protected override void OnStop() { // flag to tell the worker process to stop serviceStarted = false; // give it a little time to finish any pending work workerThread.Join(new TimeSpan(0,2,0)); } 

Source: http://tutorials.csharp-online.net/Creating_a_.NET_Windows_Service%E2%80%94Alternative_1%3a_Use_a_Separate_Thread (lien mort)

Cela fait des années que je gère de nombreux services Windows et cela fonctionne pour moi. Je n’ai toujours pas vu un modèle recommandé sur lequel les gens sont d’accord. Faites simplement ce qui fonctionne pour vous.

Quelques informations erronées ici. Windows Scheduler est parfaitement capable d’exécuter des tâches en arrière-plan sans que Windows ne s’affiche et sans mot de passe. Exécutez-le sous le compte NT AUTHORITY \ SYSTEM. Utilisez ce commutateur schtasks:

/ ru SYSTEME

Mais oui, pour accéder aux ressources du réseau, la meilleure pratique consiste à utiliser un compte de service avec une stratégie de mot de passe distincte sans expiration.

MODIFIER

Selon votre système d’exploitation et les exigences de la tâche elle-même, vous pouvez utiliser des comptes moins privilégiés que Localsystem avec l’option /ru .

Du bon manuel ,

 /RU username A value that specifies the user context under which the task runs. For the system account, valid values are "", "NT AUTHORITY\SYSTEM", or "SYSTEM". For Task Scheduler 2.0 tasks, "NT AUTHORITY\LOCALSERVICE", and "NT AUTHORITY\NETWORKSERVICE" are also valid values. 

Task Scheduler 2.0 est disponible à partir de Vista et Server 2008.

Dans XP et Server 2003, le system est la seule option.

Quel est le coût de démarrage et de fermeture de l’application? Toutes les deux minutes, c’est assez souvent. Un service permettrait probablement au système de fonctionner plus facilement que d’exécuter votre application si fréquemment.

Les deux solutions peuvent exécuter le programme lorsque l’utilisateur n’est pas connecté, donc pas de différence. L’écriture d’un service est toutefois un peu plus complexe qu’une application de bureau classique: vous pourriez avoir besoin d’un client d’interface graphique distinct qui communiquera avec l’application de service via TCP / IP, des canaux nommés, etc.

Du sharepoint vue de l’utilisateur, je me demande ce qui est plus facile à contrôler. Les services et les tâches planifiées sont pratiquement inaccessibles pour la plupart des utilisateurs non techniques, c.-à-d. Qu’ils ne réalisent même pas qu’ils existent et peuvent être configurés / arrêtés / reprogrammés, etc.

En développement .NET, je commence normalement par développer une application console, qui exécutera toutes les sorties de journalisation dans la fenêtre de la console. Cependant, il ne s’agit que d’ une application console lorsqu’elle est exécutée avec l’argument /console la commande. Lorsqu’il est exécuté sans ce paramètre, il agit comme un service Windows, qui continuera à fonctionner sur mon propre minuteur programmé et codé.

À mon avis, les services Windows sont normalement utilisés pour gérer d’autres applications, plutôt qu’une application longue durée. OU .. ils exécutent en continu des applications lourdes telles que SQL Server, BizTalk, RPC Connections, IIS (même si IIS décharge techniquement le travail vers d’autres processus).

Personnellement, je privilégie les tâches planifiées sur Window Services pour les tâches et applications de maintenance répétitives telles que la copie / synchronisation de fichiers, l’envoi, la suppression ou l’archivage en masse d’emails, la correction de données (lorsque d’autres solutions ne sont pas disponibles).

Pour un projet, j’ai été impliqué dans le développement de 8 ou 9 services Windows, mais ceux-ci restnt en mémoire, inactifs, avec 20 Mo de mémoire ou plus par instance. Les tâches planifiées feront leur travail et libéreront la mémoire immédiatement.

Le mot “service” partage quelque chose en commun avec “serv’er”. On s’attend à ce qu’il soit toujours en cours d’exécution et “serv’e”. Une tâche est une tâche.

Jeu de rôle. Si je suis un autre système d’exploitation, application ou périphérique et que j’appelle un service, je m’attends à ce qu’il s’exécute et j’attends une réponse. Si je (os, app, dev) juste besoin d’exécuter une tâche isolée, alors je vais exécuter une tâche, mais si j’espère communiquer, probablement une communication bidirectionnelle, je veux un service. Cela a à voir avec le moyen le plus efficace pour deux choses à communiquer, ou une seule chose qui veut exécuter une seule tâche.

Ensuite, il y a l’aspect planification. Si vous voulez que quelque chose fonctionne à une heure précise, programmez. Si vous ne savez pas quand vous en aurez besoin ou si vous en aurez besoin à la volée, service.

Ma réponse est de nature plus philosophique parce que cela ressemble beaucoup à la façon dont les humains interagissent et travaillent avec un autre. Plus nous comprenons l’art de la communication et les «entités» comprennent leur rôle, plus cette décision devient facile.

Mis à part la philosophie, lorsque vous faites du prototypage rapide, comme le fait souvent mon service informatique, vous faites tout ce qui est en votre pouvoir pour joindre les deux bouts. Une fois que les éléments de prototypage et de preuve de concept sont dépassés, généralement au début de la planification et de la découverte, vous devez décider de ce qui est plus fiable pour la durabilité à long terme.

OK, en conclusion, cela dépend beaucoup de nombreux facteurs, mais j’espère que cela a permis de mieux comprendre la situation.

  1. Il est plus facile de configurer et de verrouiller les services Windows avec les permissions appropriées.
  2. Les services sont plus «visibles», ce qui signifie que tout le monde (c.-à-d. Les techniciens) sait où chercher.

Un service Windows n’a besoin de personne connecté, et Windows dispose d’installations permettant d’arrêter, de démarrer et de consigner les résultats du service.

Une tâche planifiée ne nécessite pas d’apprendre à écrire un service Windows.

Pourquoi ne pas fournir les deux?

Dans le passé, j’ai mis les bits de base dans une bibliothèque et j’ai passé un appel à Whatever.GoGoGo () à la fois dans un service et dans une application de console.

Avec quelque chose que vous lancez toutes les deux minutes, les chances sont décentes de ne pas faire grand chose (par exemple, juste une fonction de type “ping”). Les wrappers ne doivent pas contenir beaucoup plus qu’un seul appel de méthode et une certaine journalisation.

C’est une vieille question mais j’aimerai partager ce que j’ai vécu.

Récemment, on m’a demandé de capturer la capture d’écran d’un radar (à partir d’un site Web météorologique) et de l’enregistrer sur le serveur toutes les 10 minutes.

Cela m’a obligé à utiliser WebBrowser. Je fais généralement des services Windows, alors j’ai décidé de faire ce service aussi, mais ça continuerait à tomber en panne. C’est ce que j’ai vu dans le chemin d’access du module d’erreur de l’observateur d’ événements : C: \ Windows \ system32 \ MSHTML.dll

Comme la tâche était urgente et que j’avais très peu de temps pour faire des recherches et expérimenter, j’ai décidé d’utiliser une simple application de console et de la déclencher en tant que tâche.

J’ai vraiment aimé l’ article de Jon Galloway recommandé dans la réponse acceptée par Mark Ransom.

Récemment, les mots de passe sur les serveurs ont été modifiés sans que je m’en acquitte et tous les services n’ont pas pu être exécutés car ils ne pouvaient pas se connecter. Donc, le ppl affirmant dans l’article commente que c’est un problème. Je pense que les services Windows peuvent faire face au même problème (veuillez me corriger si je me trompe, je suis un débutant)

Aussi, la chose mentionnée, si vous utilisez des fenêtres du planificateur de tâches ou la fenêtre de la console apparaît. Je n’ai jamais fait face à ça. Il peut apparaître mais c’est au moins très instantané.

Les services Windows veulent plus de patience jusqu’à ce que cela soit fait. Il a un peu de débogage et d’installation. C’est sans visage. Si vous avez besoin d’une tâche qui doit être effectuée chaque seconde, minute ou heure, vous devez choisir le service Windows.

La tâche planifiée est rapidement développée et a un visage. Si vous avez besoin d’une tâche quotidienne ou hebdomadaire, vous pouvez utiliser la tâche planifiée.