Comment interpréter les résultats de bancs Siege et Apache

Question

Nous avons un site MySQL qui permettra à l'occasion à des utilisateurs de 100K en 48 heures de se connecter au site et de faire des achats.

Nous essayons de simuler ce type de charge en utilisant des outils tels qu'Apache Bench and Siege. Bien que la mesure clé me ​​semble être le nombre d'utilisateurs simultanés, et nous avons les résultats de notre rapport, nous avons toujours l'impression d'être dans l'obscurité.

Ce que je veux demander est: Quel genre de choses devrions-nous tester pour anticiper ce type de trafic?

50 utilisateurs simultanés 1000 fois? 500 utilisateurs simultanés 10 fois?

Nous examinons les erreurs DB, les délais d'attente Apache et les temps de réponse. Que devrions-nous regarder d'autre?

C'est une question vague et je sais qu'il n'y a pas de "bonne" réponse, nous sommes juste à la recherche de quelques réflexions générales sur la façon de déterminer ce que notre infrastructure peut gérer de façon réaliste.

Merci d'avance!

Answer 1

Idéalement, vous allez vouloir modéliser votre utilisation de l'utilisateur, mais la création de sessions simultanées simulées pour les utilisateurs 100k n'est généralement pas facile. La meilleure source serait de vérifier vos journaux pour l'heure la plus occupée et essayer de trouver un moyen de modéliser ce niveau de charge.

La base de données est généralement un élément essentiel de l'infrastructure, donc je regarderais l'enregistrement du nombre et de la durée des attentes de verrouillage, ainsi que le nombre et la durée des instructions db.

Un autre élément clé à considérer est la longueur des files d'attente de disque.

Généralement, le processus consiste à rechercher des réponses lentes sur l'ensemble du site ou sur des pages spécifiques, puis à se concentrer sur la cause. Le plus gros problème pour les tests de charge est qu'il est assez difficile de tester votre réseau et si vous avez (comme la plupart des sites publics) une bande passante limitée via votre FAI, cela peut créer un problème de performance qui n'est pas reflété dans la charge tests.

Answer 2

Les utilisateurs simultanés sont certainement l'un des facteurs clés - en particulier pour les pools de connexions DB, etc. Mais vous voudrez également vérifier que le taux de pages (pages/sec) de vos tests est également dans la plage attendre. Si le temps de réflexion dans vos cas de test est trop long, vous pouvez accidentellement simuler un taux de page beaucoup plus élevé (ou plus bas) que votre trafic réel. Le temps de réflexion est la quantité de temps que l'utilisateur passe entre les demandes de page - lire la page, remplir un formulaire, etc.

Selon les autres informations que vous avez en main, cela peut vous aider à calculer le nombre d'utilisateurs simultanés à simuler: Virtual User Calculators

Le temps de chargement complet de la page vu par l'utilisateur final est généralement la mesure la plus importante pour évaluer les performances du système. Vous souhaiterez également rechercher les taux d'échec sur toutes les transactions. Vous devriez également être à l'affût des transactions qui ne se terminent jamais. Certains outils de test ne les signalent pas très bien, permettant aux utilisateurs simulés de rester indéfiniment bloqués lorsque le serveur ne répond pas ... et de ne pas signaler cette condition. Recherchez les outils qui indiquent le nombre d'utilisateurs en attente sur une page ou une transaction donnée et la durée moyenne d'attente de ces utilisateurs.

En ce qui concerne les statistiques côté serveur à rechercher, sur quelles autres technologies votre application est-elle basée? Vous voudrez regarder différentes choses pour une application .NET par rapport à une application PHP. Enfin, nous avons trouvé très utile de voir comment le système réagit à l'augmentation de la charge, plutôt que de regarder un seul niveau de charge. This article va plus en détail.