Discussion :

[safisafi]

Bonjour,

j'ai un site web développé en ASP.net 1.1 qui tourne sous un serveur windows 2003, j'ai intallé le Framework 2.0 sur ce serveur.
c'est quoi le plus performant : garder mon application en exécution sous 1.1 ou l'exécuter sous 2.0 ?

Merci d'avance

[Louis-Guillaume Morand]

aucun des deux, ca sert à rien

[safisafi]

je comprends de ça qu'il n 'ya pas de différence ?

[lutecefalco]

Ton appli en 1.1 tournera pas si tu l'exécutes en 2.0

[Louis-Guillaume Morand]

Ton appli en 1.1 tournera pas si tu l'exécutes en 2.0

t'es sûr?
pour moi elle tournera puisqu'il y a compatibilité ascendante. Tout objet du 1.1 existe dans le 2.0, meme les deprecated, justement pour ce cas de figure.

[lutecefalco]

t'es sûr?
pour moi elle tournera puisqu'il y a compatibilité ascendante. Tout objet du 1.1 existe dans le 2.0, meme les deprecated, justement pour ce cas de figure.

Hmmm, à vérifier

[safisafi]

si mon 1.1 appli marche très bien sur le 2.0 (j'ai dû modifier quelques trucs pour la rendre compatible avec 1.1 et 2.0 surtout l'appellation des contrôles, sous 1.1 c'est '_ctl0_NomControle' alors que sur 2.0 c'est 'ctl00_NomControle' j'ai remplacé ceci par NomControl.ClientID ...)
ma question était plutôt du côté performance, est ce que le fait de l'exécuter sous 2.0 ne diminue pas les performances de l'appli ?

[Louis-Guillaume Morand]

j'ai remplacé ceci par NomControl.ClientID ...)

oui c'est ce qu'il faut toujours faire.

est ce que le fait de l'exécuter sous 2.0 ne diminue pas les performances de l'appli ?

non, il n'y a pas de raison.

de toute façon, tu peux facilement tester et faire tes benchmarks si vraiment tu tiens à être 100% sûr.

Pourquoi le mettre sous 2.0 si c'est du 1.1 surtout?

[safisafi]

Oui bonne question
ils m'ont demandé de l'exécuter sous 2.0 c'est pour cela j'ai posé la question ... je pense il vaudrait mieux que l'appli tourne sous 1.1 tant que IIS supporte la coexistence de plusieurs versions de Framework, je pense qu'il suffit de séparer les pool de chacune des versions.

[Louis-Guillaume Morand]

Oui bonne question
ils m'ont demandé de l'exécuter sous 2.0 c'est pour cela j'ai posé la question ... je pense il vaudrait mieux que l'appli tourne sous 1.1 tant que IIS supporte la coexistence de plusieurs versions de Framework, je pense qu'il suffit de séparer les pool de chacune des versions.

tutafé. les pools d'application servent justement à cela. d'autant plus que si une appli crash le pool, les autres applis ne sont pas touchées. (mais faut pas non plus faire autant de pools que d'applis)

[lutecefalco]

(mais faut pas non plus faire autant de pools que d'applis)

Ah?
C'est ce qu'on fait chez nous.
Où est le pb?

[Bluedeep]

Ah?
C'est ce qu'on fait chez nous.
Où est le pb?

ben, une des idées du concept de pool est justement de grouper des paramètres techniques et de sécurité s'appliquant à un jeu d'appli inter-dépendantes entre elles (ou non d'ailleurs) pour précisément éviter de faire un set pour chaque appli.

En faire un par appli est assez antinomique avec le concept.

[Louis-Guillaume Morand]

ben, une des idées du concept de pool est justement de grouper des paramètres techniques et de sécurité s'appliquant à un jeu d'appli inter-dépendantes entre elles (ou non d'ailleurs) pour précisément éviter de faire un set pour chaque appli.

En faire un par appli est assez antinomique avec le concept.

Voilà.

En fait, si tu fais un pool par appli, tu as plein de désavantages
- un micro coup de perfs
- l'administration séparée alors que parfois il serait plus simple dans le cas de pool basiques d'avoir un pool partagé
etc etc

flemme de traduire ca

A lot of the articles online are very loyal to a configuration that suits their needs.

There are definitely many pros and cons. It is true that each application pool has a minimum footprint because it has to load it's own EXE and DLL's. I had a link once for the size of that footprint and couldn't find it. If I do I'll post it.

Multiple application pools only causes a performance penalty if your server is memory bound. In other words if you are using most of the server memory because not much is installed or there is high session consumption. If your server is CPU bound, more application pools can actually help. There is less thread collisions over multiple processes.

Ultimately more application pools can give you more control. For example, you could set CPU and memory boundaries to ensure a mission critical application gets the greatest share of resources. You would set memory and CPU maximums for the application pools that are low priority and no limits for the most important one.

Sometimes I use a separate application pool for a misbehaving application that leaks memory. I can cap it and control it more precisely. Another problem is a web application that doesn't trap all exceptions. The decay can cause issues with all applications that use the same pool.

Finally each application pool can use a different identity. For example, let's say you use a proxy server to expose a web site on an internal server. ISA 2006 is an excellent choice for this task. However, you might then use an application pool with weak guest permissions for the internet web application while you use a domain identity account an intranet application that isn't exposed.

au final, une des bonnes solutions est
-un pool 1.1 pour les applis 1.1 stables et non sensibles
- un pool 2.0 pour "" """ """"
- un pool pour chaque appli compliquée, potentiellement risqué (consommation mémoire) ou critique (disponibilité)