Serveur de développement de tests de stress/serveur de production

Question

Je suis très nouveau dans les tests de stress et j'essaie juste d'apprendre les ficelles du métier. Mes questions sont les suivantes:

1. Si j'ai un serveur de développement qui, en termes de logiciel est identique, mais en termes de matériel a une spécification beaucoup plus faible que le serveur de production, est-il le stress intéressant de tester le serveur de développement pour identifier défauts logiciels évidents? Comment tester au mieux un serveur de production en direct sans risquer de mettre en péril l'expérience de vos utilisateurs? Ou faut-il éviter les tests de stress sur un serveur de production en direct?

Answer 1

Voici différentes conseils/suggestions:

• Si votre application est nouveau, donc vous ne savez pas si elle peut gérer la charge qu'il aura dans la production, alors vous devez faire « capacité » essai. Vous devriez faire vos tests de capacité sur votre matériel de production, qui, comme il n'a pas encore été "en ligne", n'affectera pas les utilisateurs. Si votre application est déjà une application déjà déployée en production, ce que vous devez faire est un test de "régression de performance". Un test de régression de performance consiste à effectuer un test de contrainte de toutes les «caractéristiques» individuelles (quel que soit le moyen utilisé pour votre application) sur votre serveur de développement pour mesurer sa performance. Vous conservez un enregistrement des résultats en tant que «référence». Lorsque vous apportez des modifications à votre application, réexécutez vos tests de régression des performances pour voir si les résultats ont changé de manière significative par rapport à la référence (et enregistrez les nouveaux numéros comme nouvelle référence). Si les résultats de la régression de performance sur votre serveur de développement n'ont pas beaucoup changé par rapport à la référence, vous devriez pouvoir les déployer en production sans que votre utilisation du serveur ne change (c'est-à-dire être surchargée).

Answer 2

Je pense que vous devriez éviter tout travail, y compris les tests de stress sur les machines de production, à moins que vous savez que vous avez un problème que vous ne pouvez pas reproduire dans votre environnement de test - qui dit que vous savez peut-être vos utilisateurs ne sont pas utiliser le système pendant la nuit? Si les tests ne sont pas intrusifs/en lecture seule, je dirais que c'est une option supplémentaire. En ce qui concerne les performances d'analyse sur une machine Weekly, ce n'est pas si mal - la plupart des goulots d'étranglement sont causés par une mauvaise architecture de votre système et doivent être visibles sur différentes configurations matérielles, selon différents scénarios de charge. les problèmes sur une machine de week-end donc je dirais stress test et optimiser sur votre système de développement et vous saurez que, au moins théoriquement, votre système de production devrait être encore mieux.