Existe-t-il un moyen de tester les performances du site sous charge
9
J'ai créé un site Web Asp.net MVC et l'ai hébergé sur un fournisseur d'hébergement partagé. Étant donné que mon site Web entoure une idée très générique, il pourrait avoir un certain nombre d'utilisateurs simultanés à l'avenir.
Donc, je pensais à un moyen de tester mon site Web pour les performances en charge. Comme la performance du site lorsque 100 ou 1000 utilisateurs sont en ligne en même temps et naviguent sur le site. Cela me permettra également de comprendre si mes requêtes LINQ sont bien écrites ou non.
Tout d'abord, le terme approprié est test de résistance . Il existe de nombreuses solutions pour les tests de résistance des sites Web, une solution hébergée que je recommanderais est loadimpact . Ce qu'ils font, c'est bombarder votre site avec les demandes de divers serveurs du monde entier et vous donner un rapport analytique sur la façon dont votre site a géré le stress. Ils ont un test gratuit, où vous pouvez avoir une idée générale, mais pour plus, vous devrez payer des frais d'abonnement.
Ces types de tests ne tester que le site des visiteurs point de vue, pour plus d'informations spécifiques que vous devez profiler votre application localement, et je n'ai pas vraiment plus rien à ajouter aux réponses précédentes, j'utilise Apache JMeter ainsi .
Et, enfin, en tant que développeur Web soucieux de performances, vous devriez jeter un œil à YSlow :
YSlow analyse les performances des pages Web en examinant tous les composants de la page, y compris les composants créés dynamiquement à l'aide de JavaScript. Il mesure les performances de la page et propose des suggestions d'amélioration.
YSlow pour Firefox est intégré à l'outil de développement Web Firebug pour Firefox.
Plus souvent qu'autrement, je trouve que Javascript est le véritable goulot d'étranglement et non le code back end ou la base de données. Bien sûr, les requêtes mal écrites peuvent être une pénalité de performance majeure, mais après avoir traité celles-ci, exécutez toujours YSlow et suivez ses suggestions, c'est un épargnant de vie.
Explorez d'autres solutions avant de payer les frais d'abonnement de loadimpact, bien sûr. Il existe plusieurs solutions similaires. J'adore ça, mais le travail a payé les frais pas moi :)
yannis
Je vais utiliser le test gratuit .... je ne veux pas de tests rigoureux pour l'instant, car cela n'a aucun sens pour le moment .... je veux juste avoir l'idée :-)
Pankaj Upadhyay
7
Vous êtes sur l'hébergement mutualisé, il est donc peu probable que vous puissiez exécuter des tests qui indiquent correctement les performances, car il n'y a aucune garantie du niveau de ressources auquel votre application aura accès à un moment donné.
Cependant, ce que je ferais dans cette situation, c'est de commencer par exécuter un test de manière isolée sur une boîte dédiée (cela peut être votre propre ordinateur portable); utiliser un outil comme la suite de tests de charge Visual Studio ou JMeter (que je ne peux personnellement pas supporter), et créer un ensemble de tests qui représentent un chemin d'accès typique à travers votre application (vous devriez pouvoir obtenir des informations sur un chemin d'accès typique à travers l'utilisation de Google Analytics. Si ce n'est pas disponible, vous pouvez simplement en utiliser un qui vous semble probable, mais n'oubliez pas que cela ne donnera pas une référence aussi précise). Faites ensuite un test de montée en puissance, commencez par 1 utilisateur, puis ajoutez lentement des utilisateurs jusqu'à ce que vous atteigniez votre charge de pointe estimée. Cela devrait vous montrer à quel point votre système résiste bien dans son ensemble (j'aime personnellement aller un peu plus loin pour m'assurer d'avoir de la marge).
La dernière chose que vous voudrez faire est d'exécuter un outil de profilage comme ANTS performance profiler lors de l'exécution du test (sachez que cela ajoute un peu de surcharge). Cela vous permettra d'identifier les requêtes et les méthodes de longue durée, vous donnant des indications sur l'endroit où votre application est vraiment lente (une astuce: elle n'est presque jamais réellement là où vous pensez qu'elle sera).
Le principal problème que vous rencontrez est, comme je l'ai dit en premier, que vous êtes sur l'hébergement mutualisé, il sera donc presque impossible d'obtenir une émulation réaliste de l'environnement en direct. Cependant, si votre application a une marge de sécurité décente dans un environnement similaire à vos ressources promises, vous devriez avoir une certaine confiance que le code peut tenir dans votre hébergement, même si vous atteignez les limites de votre environnement avant de vous y attendre.
Je n'ai utilisé que JMeter jusqu'à présent, c'est un outil graphique qui vous permet de créer des plans de test assez facilement. Vous pouvez simuler plusieurs utilisateurs avec plusieurs threads. Vous pouvez également enregistrer les utilisations typiques de votre site en reliant votre navigateur à un proxy JMeter et en effectuant le travail réel, vous n'avez donc pas besoin d'écrire les demandes à partir de zéro vous-même. Le Grinder est basé sur un script si je me souviens bien, pourrait également convenir.
J'aime aussi Loadimpact pour les tests de résistance. Une chose que j'ai tendance à utiliser pour des vérifications rapides sur mon site est Apache Bench. Lorsque je veux effectuer des tests finaux, je vais me tourner vers un service payant.
Mon travail a également investi dans WebLoads, ce qui est très coûteux mais nous permet de tester tous nos sites en interne. Je ne le recommande cependant pas.
Je ne pense pas que les tests de charge puissent être effectués manuellement car cela prendra plus de temps que prévu et sera une tâche fastidieuse. Vous pouvez probablement opter pour Load Runner qui peut aller pour de nombreux utilisateurs.
Un script Autohotkey (AHK) peut simuler un utilisateur humain. Laissez-le fonctionner toute la journée.
Vous pouvez le laisser s'exécuter sur plusieurs cases pour simuler quelques utilisateurs. La bonne chose est que le style de test est entièrement sous votre contrôle. Vous pouvez avoir 1 script AHK spammant une fonctionnalité de rapport et voir si cela affecte les utilisateurs d'autres fonctionnalités.
Bien que je ne sois pas familier avec les capacités de filetage d'AHK, il peut être difficile de simuler des milliers d'utilisateurs. Vous pouvez être lié par le nombre d'ordinateurs dont vous disposez.
Vous êtes sur l'hébergement mutualisé, il est donc peu probable que vous puissiez exécuter des tests qui indiquent correctement les performances, car il n'y a aucune garantie du niveau de ressources auquel votre application aura accès à un moment donné.
Cependant, ce que je ferais dans cette situation, c'est de commencer par exécuter un test de manière isolée sur une boîte dédiée (cela peut être votre propre ordinateur portable); utiliser un outil comme la suite de tests de charge Visual Studio ou JMeter (que je ne peux personnellement pas supporter), et créer un ensemble de tests qui représentent un chemin d'accès typique à travers votre application (vous devriez pouvoir obtenir des informations sur un chemin d'accès typique à travers l'utilisation de Google Analytics. Si ce n'est pas disponible, vous pouvez simplement en utiliser un qui vous semble probable, mais n'oubliez pas que cela ne donnera pas une référence aussi précise). Faites ensuite un test de montée en puissance, commencez par 1 utilisateur, puis ajoutez lentement des utilisateurs jusqu'à ce que vous atteigniez votre charge de pointe estimée. Cela devrait vous montrer à quel point votre système résiste bien dans son ensemble (j'aime personnellement aller un peu plus loin pour m'assurer d'avoir de la marge).
La dernière chose que vous voudrez faire est d'exécuter un outil de profilage comme ANTS performance profiler lors de l'exécution du test (sachez que cela ajoute un peu de surcharge). Cela vous permettra d'identifier les requêtes et les méthodes de longue durée, vous donnant des indications sur l'endroit où votre application est vraiment lente (une astuce: elle n'est presque jamais réellement là où vous pensez qu'elle sera).
Le principal problème que vous rencontrez est, comme je l'ai dit en premier, que vous êtes sur l'hébergement mutualisé, il sera donc presque impossible d'obtenir une émulation réaliste de l'environnement en direct. Cependant, si votre application a une marge de sécurité décente dans un environnement similaire à vos ressources promises, vous devriez avoir une certaine confiance que le code peut tenir dans votre hébergement, même si vous atteignez les limites de votre environnement avant de vous y attendre.
la source
Vous pouvez consulter des outils comme JMeter ou The Grinder .
Je n'ai utilisé que JMeter jusqu'à présent, c'est un outil graphique qui vous permet de créer des plans de test assez facilement. Vous pouvez simuler plusieurs utilisateurs avec plusieurs threads. Vous pouvez également enregistrer les utilisations typiques de votre site en reliant votre navigateur à un proxy JMeter et en effectuant le travail réel, vous n'avez donc pas besoin d'écrire les demandes à partir de zéro vous-même. Le Grinder est basé sur un script si je me souviens bien, pourrait également convenir.
la source
J'aime aussi Loadimpact pour les tests de résistance. Une chose que j'ai tendance à utiliser pour des vérifications rapides sur mon site est Apache Bench. Lorsque je veux effectuer des tests finaux, je vais me tourner vers un service payant.
Mon travail a également investi dans WebLoads, ce qui est très coûteux mais nous permet de tester tous nos sites en interne. Je ne le recommande cependant pas.
la source
Je ne pense pas que les tests de charge puissent être effectués manuellement car cela prendra plus de temps que prévu et sera une tâche fastidieuse. Vous pouvez probablement opter pour Load Runner qui peut aller pour de nombreux utilisateurs.
la source
Un script Autohotkey (AHK) peut simuler un utilisateur humain. Laissez-le fonctionner toute la journée.
Vous pouvez le laisser s'exécuter sur plusieurs cases pour simuler quelques utilisateurs. La bonne chose est que le style de test est entièrement sous votre contrôle. Vous pouvez avoir 1 script AHK spammant une fonctionnalité de rapport et voir si cela affecte les utilisateurs d'autres fonctionnalités.
Bien que je ne sois pas familier avec les capacités de filetage d'AHK, il peut être difficile de simuler des milliers d'utilisateurs. Vous pouvez être lié par le nombre d'ordinateurs dont vous disposez.
la source