Discussion :

[LEK]

Bonjour,
je dispose d'un site asp.net (framework 2.0/windows serveur 2003) pour lequel j'effectue des tests de performance. J'ai utilisé Jmeter pour simuler la charge utilisateur sur un scénario basique.
Le problème que j'ai est le suivant : il me semble que le délai d'exécution des requêtes http se met à exploser dès que j'ai plus de 8 utilisateurs simultanés.
J'utilise perfmon pour visualiser mes résultats.
Comment déterminer la cause du problème ?
Est ce qu'un mémory leak peut produire des temps de réponses de plus en plus long ? ou bien dois-je cherché un "lock" de process (a noter que je ne vois aucune requêtes dans la file d'attente de l'application).
Peut être que je soumet mon serveur à un stress trop intensif : dois-je mettre des pauses entre chaque requêtes ?

Merci pour toutes réponses sur le sujet.
Lek.

[cybermaxs]

Salut,

Vaste sujet que les performances d'un site ASPNET... Tout dépend du site, des pages et de la manière de coder. Tu ne donnes pas beaucoup d'informations.
Optimiser les perfs, c'est toujours comme une chasse aux trésors : il faut tester certaines parties de site, monitorer, changer, ... c'est un travail minutieux.
Comme se comporte ton site avec un utilisateur ? utilise les traces du site pour voir les temps de réponses. Par exemple, 10 secondes pour te renvoyer une page déjà compilée lorsque tu es tout seul, c'est pas terrible et ça ne va pas s'améliorer avec plus d'utilisateurs... Qui est responsable des lenteurs, le serveur ou le client ? si tu utilises beaucoup de javascript dans des grosses pages, le serveur n'est pas responsable.
Travailles tu avec des fichiers ? Les écritures sus disques peuvent être aussi une cause de lenteurs.
La mémoire ne posera problème qu'au bout d'un certains temps ; ça ne va pas influencer les temps de réponse lors des tests surtout avec 8 utilisateurs en même temps.

Bref, l'optimisation n'est pas un science exacte. Il faut te fixer des limites en temps de réponse et surtout s'assurer que tes méthodes d'estimations sont fiables.

[Nicolas Esprit]

Bonjour,




Je rejoins cybermaxs dans ses propos, sans plus de détails sur ton architecture difficile de t'aider plus. Comme il l'a souligné, il faut déjà cerner où ça coince :

• Est-ce niveau serveur ? Si oui à quel endroit, pour quelles ressources ?
• Est-ce niveau client ? Trop de javascript, taille du ViewState ou des images trop importante ? (un petit coup de YSlow devrait t'aider pour optimiser ta page d'un point de vue client)
• Est-ce niveau transport ? Utilises-tu un hébergeur ou bien le réseau de ton entreprise ?
• Est-ce niveau physique ? Quelle est la consommation CPU ou mémoire sur ton serveur ? Tu pourrais utiliser les Performance Counters ASP.NET par exemple
• Est-ce niveau SGBD ? Requêtes qui prennent trop de temps, mauvaise utilisation des index ou mauvais schéma relationnel ?

Bref, il faut déjà analyser à quel endroit il y a un problème, puis on pourra t'aider à déterminer la cause voire trouver une solution ou te guider avec des propositions d'optimisation.

En espérant t'avoir aidé.

[LEK]

Merci messieurs, voici des précisions :
tous les temps mesurés sont fait sous Jmeter donc je ne mesure que le temps de réponse du serveur web (je ne tient actuellement pas compte du temps d'affichage/fichiers javascript...)
Mon site web est une appli asp.net qui sert de front-end à un ensemble de services web eux-mêmes pluggués sur une base oracle 10g.
Le site asp et les services web sont sur une seule machine (iis 6/windows 2003). La base et sur une autre machine. Les mesures sont faites directement sur le serveur IIS (donc pas de délai réseau particulier).

-> J'ai effectué des mesures avec un seul utilisateur loggué qui réexécute en boucle un scénario simple.
Pour cela je n'ai pas de dégradation des temps de réponses.
Au niveau mémoire consommée par le processus, je n'ai pas de pics et une consommation stable en ligne continue.
Pas de requêtes dans la file d'attente de l'application ou des services web.
Au niveau temps de processus quelque pic mais moins de 50% du temps de process utilisé en moyenne.
-> J'ai effectué les mêmes mesures avec plusieurs utilisateurs concurrents : là je commence à voir des temps de réponses de plus en plus long.
Pas de requêtes dans la file d'attente de l'application ou des services web.
Au niveau consommation mémoire : cela reste stable et sans augmentation remarquable.
Au niveau temps de process pas de changement par rapport au cas nominal.

Le temps d'exécution des pages est la seule mesure qui semble aller en augmentant : lorsque le temps d'exécution d'une page asp croit, je vois que le temps d'exécution des services web varie aussi mais dans une mesure beaucoup moindre.
Il faut aussi savoir que l'ensemble des appels au services web sont synchrones (c'est partant de là que j'ai voulu mesurer ce qu'il pouvait y avoir dans la file d'attente).

Merci encore de votre aide,
Lek

[Nicolas Esprit]

LEK,

Pour résumer un peu, ton application Web utilise des WebServices connectés à une base Oracle. Si tu augementes le nombre d'utilisateurs simultanés, le temps de rendu de ta page ASPX croît anormalement alors que le temps de requêtage des WebServices lui reste correct. C'est bien ça ? De même, il n'y a pas d'utilisateur bloqué en file d'attente pour accéder aux WebServices.

Il faudrait nous expliquer à quoi correspondent ces appels aux WebServices dans tes pages. Est-ce pour alimenter une GridView ou un autre contrôle ? La sérialisation en XML des réponses des WebServices peuvent (temporairement) consommer énormément de mémoire. D'un autre côté, tu as parlé d'une consommation stable... On pourrait donc logiquement écarter, dans ce cas, les WebServices et la base Oracle.
Cependant, pense aussi à regarder la consommation CPU et mémoire globale du serveur Web et pas uniquement des process qui t'intéressent.

Tes scénarios se déroulent sur la même page ? Ou plusieurs ? Utilises-tu une ressource commune, ou stockes-tu des données dans l'objet Session ou Application ?

[LEK]

Salut,
pardon pour le délai de réponse. J'ai finalement trouvé que le problème majeur se faisait lors de certaine requêtes en base. Ce qui est assez étonnant c'est qu'il devait donc y avoir une queue sur les connexions en base alors que seulement 7 connexions simultanées étaient ouvertes : le pool de connexion aurait du me permettre d'ouvrir davantage de connexion simultanées (100 max par défaut suivant la spec MS) => je creuse donc actuellement sur la gestion du pooling et l'amélioration des requêtes.

Merci encore.