Comment garder mon application ASP.NET toujours «en vie», et si c'est une mauvaise idée, pourquoi ne devrais-je pas le faire?

Question

J'ai récemment déployé une application ASP.NET sur mon tout nouveau VPS et, bien que je sois satisfait de l'augmentation générale des performances qu'un VPS peut donner à une solution d'hébergement partagé, je ne suis pas satisfait du temps de démarrage de mon ordinateur. application.

Le démarrage de mon application Web prend un certain temps. Je ne l'exécute pas en mode débogage (désactivé dans mon Web.config), et il n'a pas de travail à effectuer au démarrage - je n'ai pas de code dans mon gestionnaire d'événements de démarrage d'application, je n'en démarre aucun. fils supplémentaires, rien. La première fois que mon client accède à ma demande, il faut environ 15 à 20 secondes pour répondre. Les appels suivants prennent 1-2 secondes, à moins d’attendre quelques minutes que mon application soit fermée. Ensuite, le démarrage a repris 15 à 20 secondes.

(Je suis conscient que mon point de repère est très peu scientifique, ces chiffres devraient simplement donner une idée de la performance au démarrage de mon application).

D'après ma compréhension de ASP.NET, IIS (7.0, dans ce cas), compile une application Web lors de sa première exécution, puis met en cache ces fichiers binaires jusqu'à ce que l'application Web soit modifiée. Ma compréhension est-elle fausse?

Donc, après cette préface de la taille d'un livre, voici mes questions:

• Ma compréhension de la compilation d'ASP.NET est-elle incorrecte? Comment ça fonctionne réellement?
• Existe-t-il un moyen de forcer IIS à mettre en cache mes fichiers binaires ou à conserver mon application en vie indéfiniment?
• Si c'est une mauvaise idée de faire l'une des choses de ma question précédente, pourquoi est-ce une mauvaise idée et que puis-je faire à la place pour augmenter les performances de démarrage?

Merci!

Modifier: il semble que ma question soit un léger double de cette question (je pensais avoir fait un meilleur travail de recherche d'une réponse à cette question ici, haha). Cependant, je pense que ma question est plus complète et je vous serais reconnaissant de ne pas fermer le double comme duplicata, à moins que vous ne posiez de meilleures questions, déjà posées, qui traitent de cela.

Answer 1

IIS ferme également votre application Web après une période donnée, en fonction de sa configuration. Je ne connais pas aussi bien IIS7 et où le configurer, vous voudrez peut-être faire quelques recherches pour savoir comment le configurer ( point de départ? ).

Est-ce mauvais? Cela dépend de la qualité de votre code. Si vous ne perdez ni mémoire ni ressources, probablement pas.

L’autre solution consiste à précompiler votre site Web . Cela pourrait être la meilleure option pour vous. Vous devrez toutefois vérifier et voir, car cela peut présenter des inconvénients, en fonction de la manière dont vous interagissez avec votre site Web.

Answer 2

  

D'après ma compréhension de ASP.NET, IIS (7.0, dans ce cas), compile une application Web lors de sa première exécution, puis met en cache ces fichiers binaires jusqu'à ce que l'application Web soit modifiée. Ma compréhension est-elle fausse?

C'est correct. Plus précisément, les assemblys sont construits en tant que clichés instantanés (à ne pas confondre avec la fonction de service d'instantané de volume / copie fantôme). Cela vous permet de remplacer le code dans le dossier à la volée sans affecter les sessions en cours existantes. ASP.NET détectera le changement et compilera les nouvelles versions dans le répertoire cible (généralement Fichiers ASP.NET temporaires ). Pour en savoir plus sur ce processus: Comprendre la compilation dynamique ASP.NET

Answer 3

Si c’est purement le moment de la compilation, l’approche la plus efficace consiste souvent à visiter le site Web vous-même après le recyclage. Passez un appel à intervalles réguliers pour vous assurer que c'est vous qui recevez le délai de 15 secondes et non votre client.

Cela m'étonnerait cependant que tout le temps de la compilation soit écoulé (en fonction du matériel): disposez-vous de nombreuses instances statiques de classes? Font-ils beaucoup de travail au démarrage?

Avec le traçage ou le profilage, vous pouvez probablement déterminer assez rapidement où le temps de démarrage a été utilisé.

En ce qui concerne la raison pour laquelle garder un processus est une mauvaise idée, je pense que cela est dû à une clarification. Quelle que soit la qualité de la gestion de nos données ou de la qualité de fonctionnement du GC, le processus de redémarrage permet un nettoyage satisfaisant. Des choses comme la fragmentation peuvent disparaître et tout autre problème de ressources qui se développe au fil du temps est résolu. Par conséquent, il est très déconseillé de laisser un processus serveur s'exécuter indéfiniment.