Comme nous le savons tous, il n’est pas facile de mettre en œuvre une application qui fonctionne 24h/24 et 7j/7. Un de mes projets a duré plus de 20 heures sous une charge violente et est quand même mort héroïquement. Heureusement, ASP.NET et IIS nous fournissent des fonctionnalités simples qui nous permettent de créer facilement des applications .Net super stables. Cependant, ce qui est un peu désagréable, c'est que les méthodes de configuration sous les systèmes Windows 2000 (versions inférieures à IIS6.0) et Windows 2003 (IIS6.0) sont différentes.
Parlons d'abord du système Windows 2000. Ceux qui connaissent ASP.NET devraient tous connaître le fichier machine.config. Il est stocké dans le répertoire %WindowPath%Microsoft.NetFramework%.NetVersion%CONFIG. Utilisez n'importe quel éditeur de texte (le plus populaire est bien sûr "Notepad") pour ouvrir le fichier et rechercher la section <processModel...>. ASP.NET contrôle le processus de service ASP.NET (aspnet_wp.exe ou w3wp.ext) en fonction des paramètres de cette section. Le code de l'application ASP.NET que nous avons écrit s'exécute dans cet espace de processus. Si vous utilisez Framework 1.1, vous verrez plus de n propriétés dans cette section. Nous nous intéressons aux trois suivantes, suivies du signe égal sont leurs valeurs par défaut :
timeout="Infinite"
sleepTimeout="Infinite"
memoryLimit="60"
Vous ne pouvez pas les voir sous Framework 2.0, mais vous pouvez les ajouter manuellement.
Permettez-moi de traduire la signification de ces trois attributs. Après une exécution continue pendant la durée spécifiée par timeout, redémarrez le processus du service ASP.NET. La valeur par défaut du timeout est l'infini. Vous pouvez le réinitialiser au format "HH:MM:SS". " , par exemple, timeout=24:00:00 signifie un redémarrage après 24 heures ; si personne n'y accède dans le délai spécifié par ralentiTimeout, redémarrez le processus du service ASP.NET. La valeur par défaut de ralentiTimeout est également infinie et la méthode de configuration est comme ci-dessus ; si Si le pourcentage de mémoire utilisé par le processus de service ASP.NET par rapport à la mémoire totale du système dépasse la quantité spécifiée par memoryLimit, le processus de service ASP.NET sera redémarré.
Comprenez que grâce à la coopération de ces trois attributs, le processus de service peut être redémarré sans le savoir, afin que notre application puisse continuer à s'exécuter. Quand je dis cela, les lecteurs attentifs auront peut-être découvert le problème. Lorsque le processus de service sera redémarré, la session du client sera inévitablement perdue et le fonctionnement de l'utilisateur sera interrompu. Comment pouvons-nous réaliser « Dieu ne sait pas et les fantômes ne savent pas » ?
Ce problème existe, mais son impact peut être minimisé ou même complètement éliminé par les mesures suivantes :
Tout d'abord, nous pouvons définir IdleTimeout sur une valeur raisonnable, généralement je le définirai 3 fois sur 1,5 à 1,5 du délai d'expiration de la session. Réglez le délai d'attente sur la limite supérieure pendant laquelle le programme peut persister. Je le règle généralement sur 24 heures. Cela forcera le processus de service à redémarrer lorsqu'il est inactif. Puisqu'il n'y a pas de session à ce moment-là, il est impossible d'interrompre le fonctionnement de l'utilisateur. Cette configuration est très efficace dans un environnement de bureau de petites et moyennes entreprises, car il n'y a pratiquement aucun accès en dehors des heures d'ouverture.
Bien entendu, la méthode ci-dessus présente de grandes limites et ne peut fonctionner que dans des situations spécifiques. Si quelqu'un continue d'accéder ou redémarre lorsque la mémoire dépasse la limite, le fonctionnement de l'utilisateur sera toujours perturbé. Une solution ultime consiste à enregistrer l’état de la session dans un processus distinct. Sur ASP.Net, cela est également possible avec une configuration simple.
Source : salle d'enregistrement du BLOG