Bonjour, Il y a le Web application stress tool de Microsoft qui est un outil utile pour effectuer des tests de base de performance. Plus d'informations ici : http://www.microsoft.com/downloads/details.aspx?FamilyID=E2C0585A-062A-439E-A67D-75A89AA36495&displaylang=en Si vous travaillez dans le monde Windows, cet outil couplé a des logs créés avec le Performance monitor (sur Windows Server) peuvent effectuer de très bons tests de performances. On peut aussi trouver des memory leak et autres problèmes d'applications avec ces outils. Il y a des suites d'outils de tests qui sont plus complets, mais ils coûtent très chers. Je ne connais pas des équivalences dans le monde open source, mais sûrement qu'il y en a. Pour ce qui est des éléments qui devront faire parties des audits comme tel. Cela dépendera du site / application Web (du type d'information, utilisateurs, etc) 8 secondes peut être correct pour certains sites d'autres type de site Web peuvent être téléchargés en plus de temps. C'est important de regarder ce qui se passe du côté du(des) serveur(s) aussi. (Avec le performance monitor, entre autres). La bande passante est un autre élément important à considérer, on l'oublie souvent. Sur un réseau local, on a beaucoup plus de bande passante que sur une connexion Internet (en général...) Le tuyau de bande passante peut mourrir bien avant un serveur. L'idéal est de configurer un routeur entre les clients et le serveur de test pour simuler la réelle bande passante disponible. Quand on teste la performance, on teste aussi la robustesse du site. Pour faire une petite conclusion, voici des choses (il y en a certainement d'autres, cela dépend des spécifications de votre site Web) à regarder pour ce type d'audit : La lourdeur des pages Web (en kilooctets) ( + temps de téléchargement selon le type de connexion Internet)
Le maximum d'utilisateurs concurrents avant que le serveur ne puisse plus répondre (plusieurs tests doivent être faits ici, selon des configurations différentes de postes clients virtuels)
S'assurer qu'il n'y ait pas de memory leak ou autres crash d'applications causés par un nombre élevé d'utilisateurs (threading, pool de connexion BD, etc)
S'assurer que la bande passante disponible soit suffisante pour le nombre d'utilisateur maximum
On peut aussi auditer les technologies et architectures utilisés pour une application. Certains choix technologiques et designs d'application peuvent tuer la performance. C'est ce qui me passe par la tête sur le sujet ce soir... En espérant avoir été utile, Une chose est certaine, si la performance est un élément important d'un site / application, il faut y penser dès le départ et effectuer des tests de performances (simples) tout au long du développement. -Benoit Piette Nicolas St-Laurent a écrit : >Le 05-12-28 à 17:06, Annie Huard-Langlois a écrit :
>
> >
>>Bonjour,
>>
>>
>>
>>Je fais appel à vous car je n’ai pas trouvé ce que je cherche après >>de nombreuses recherches. Je sais que ma question ne touche pas >>aux principaux points d'intérêts de W3Qc mais avec votre communauté >>d’experts, j’ai peut-être des chances... Si vous voulez, vous >>pouvez me répondre off liste pour ne pas l’encombrer avec ce sujet >>moins à propos.
>>
>>
>>
>>Je cherche à connaître les éléments-clés qui doivent faire partie >>d'un audit de performance sur un site web ?
>>
>>
>>
>>Par exemple, combien d'usagers simultanés peuvent naviguer sur le >>site tout en ayant des temps réponse sous les 8 secondes >>standard ? Je ne sais pas si ceci pourrait en être un, d’après moi >>oui.
>>
>>
>>
>>Merci de votre aide !
>>
>>
>>
>>Annie
>> >>
>Bonjour Annie,
>
>Je n'ai jamais fait d'audit de performance. Par contre, je peux te >suggérer un ouvrage que j'ai lu récemment : Web Site Measurement >Hacks (http://www.oreilly.com/catalog/webmeasurehks/). Bien que cet >ouvrage soit plus orienté vers la pratique et ne se limite pas qu'à >la performance, il présente différentes approches d'analyse et >démystifie les notions (voir Hack #1).
>
>Les rapports produits par les outils d'analyse tels que Gomez (http:// >www.gomez.com/web_monitoring.html) et Symphoniq (http:// >www.symphoniq.com/) peuvent également te donner une idée des >éléments à considérer.
>
>En espérant t'avoir été d'une quelconque aide,
>
>Nicolas St-Laurent
>Développeur
>LAMP-DAMP-Oracle-Java-Web
>stlaurent.nicolas at gmail.com
>www.nist.ca
>
>
>
>_______________________________________________
>Liste de discussion public
>public at lists.w3qc.org
>http://lists.w3qc.org/listinfo.cgi/public-w3qc.org
>
>
>
> >