2 votes

Mettre à niveau vers IIS7 depuis IIS6 pour améliorer les performances de l'application

J'ai une application ASP Classic qui s'exécute actuellement dans IIS6, mais souvent, en raison du non respect des "meilleures pratiques" par le programmeur initial, cette application lance une erreur de mémoire insuffisante après plusieurs heures.

À l'origine, j'avais posé cette question sur StackOverflow en référence au problème initial.

Les solutions idéales seraient de migrer l'application vers .NET, ou de déboguer le code brut pour trouver les fuites de mémoire et les corriger. Cependant, il y a près d'un million de lignes de code... et il a fallu du temps pour trouver divers problèmes et les résoudre, et plus de temps est nécessaire pour trouver d'autres fuites de mémoire.

Ma question est : Est-ce que IIS7 gérerait mieux ou plus efficacement l'utilisation de la mémoire du VBScript que IIS6, au point que ce serait une amélioration ? Est-il utile de migrer l'application vers IIS7 pour aider à atténuer ce problème ? Évidemment, le problème ne disparaîtrait pas complètement, car il y a toujours des fuites, mais est-ce que cela s'améliorerait ?

L'application s'exécute sur Windows Server 2003.

3voto

Thecamelcoder Points 11

Il fonctionnerait plus longtemps si vous passiez à x64. Il pourrait utiliser autant de mémoire que vous pourriez lui donner avant de planter. En x86, vous ne dépasseriez probablement même pas la limite de processus de 2 Go avant de planter. Ensuite, vous pourriez recycléer le pool d’applications moins souvent et espérons-le après les heures de bureau où moins d’utilisateurs sont impactés.

Mais est-ce qu'il "gère mieux ou plus efficacement VBScript"? Non.

0voto

TristanK Points 8893

La migration pourrait être plus problématique que cela n'en vaut la peine. IIS 6 a essentiellement les mêmes options de recyclage que la version 7, et c'est probablement ce que je considérerais en premier dans votre situation.

S'il y a effectivement une fuite de mémoire, vous pourriez mettre en place un recyclage basé sur la limite de mémoire.

Par exemple : si l'application finit par consommer 800 Mo d'octets privés, elle sera recyclée. (Le recyclage crée un nouveau processus pour remplacer l'ancien, puis termine l'ancien).

Si votre application ne réagit pas mal au recyclage (le recyclage entraîne une perte d'état - par exemple, l'état de session, les variables en mémoire, etc.), cela pourrait être une bonne option. Si elle est sans état, vous pourriez également envisager de définir maxprocesses > 1 (un "jardin web"), ce qui, en théorie, multiplierait le temps avant l'échec par le nombre de processus de travail. (cela suppose que vous disposez de n * 2 Go de RAM à y consacrer)

Si c'est le cas, et que votre application a une durée de vie définie, mettre en place un intervalle de recyclage plus court que cela fonctionnerait (par exemple, recycler toutes les 1 heure).

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X