Question

J'ai développé un cadre qui est utilisé par plusieurs équipes de notre organisation. Ces "modules", développés au-dessus de ce cadre, peuvent se comporter de manière très différente, mais ils consomment tous assez de ressources, même si certains le sont plus que d'autres. Ils reçoivent tous des données en entrée, les analysent et / ou les transforment, puis les envoient plus loin.

Nous avions prévu d’acheter du nouveau matériel et mon supérieur hiérarchique m’a demandé de définir et de mettre en œuvre un point de repère basé sur les modules afin de comparer les différentes offres que nous avons reçues.

Mon idée est de simplement commencer séquentiellement chaque module avec un groupe de données bien choisi en entrée.

Avez-vous des conseils? Des remarques sur cette procédure simple?

Était-ce utile?

La solution

Votre question est assez large et ma réponse ne sera malheureusement pas très précise non plus.

Premièrement, le benchmarking est difficile. Ne sous-estimez pas l’effort nécessaire pour obtenir des résultats significatifs, reproductibles et hautement fiables.

Deuxièmement, quel est votre objectif de performance? Est-ce un débit (transaction ou opérations par seconde)? Est-ce la latence (temps nécessaire pour exécuter une transaction)? Vous souciez-vous de la performance moyenne? Est-ce que je me soucie de la performance dans le pire des cas? Est-ce que vous vous souciez du pire des cas ou si 90%, 95% ou un autre centile obtiennent des performances suffisantes?

En fonction de votre objectif, vous devez concevoir votre point de repère pour le comparer à cet objectif. Donc, si le débit vous intéresse, vous voudrez probablement envoyer des messages / transactions / entrées dans votre système à un débit prescrit et voir si le système se maintient.

Si la latence vous intéresse, vous devez envoyer des messages / transactions / entrées et mesurer le temps nécessaire au traitement de chacun.

Si les performances dans le pire des cas vous intéressent, vous ajouterez de la charge au système jusqu’à ce que vous considérez comme "réaliste". (ou quoi que la conception du système indique qu'il devrait prendre en charge.)

Deuxièmement, vous ne dites pas si ces modules vont être liés au processeur, aux entrées / sorties, s'ils peuvent tirer parti de plusieurs processeurs / cœurs, etc. Lorsque vous essayez d'évaluer différentes solutions matérielles, vous constaterez peut-être que votre application bénéficie davantage d'un excellent sous-système d'E / S par rapport à un grand nombre de processeurs.

Troisièmement, le meilleur point de repère (et le plus difficile) est de placer une charge réaliste dans le système. Cela signifie que vous enregistrez des données à partir d'un environnement de production et que vous soumettez la nouvelle solution matérielle à ces données. Il est souvent plus difficile d’y parvenir. Cela implique souvent d’ajouter toutes sortes de points de mesure dans le système pour voir son comportement (si vous ne les avez pas déjà), modifier le système existant pour ajouter des capacités d’enregistrement / lecture, modifier la La lecture doit être exécutée à des vitesses différentes et obtenir un environnement de test réaliste (similaire à la production).

Autres conseils

La référence la plus significative est de mesurer les performances de votre code dans une utilisation quotidienne. Cela vous fournira évidemment les chiffres les plus réalistes.

Choisissez plusieurs ensembles de données de la vie réelle et soumettez-les aux mêmes processus que votre organisation utilise tous les jours. Pour obtenir un crédit supplémentaire, parlez aux personnes qui utilisent votre framework et demandez-leur de vous fournir les expressions "meilleur cas", "normal" et "pire des cas". Les données. Anonymisez les données s'il y a des problèmes de confidentialité, mais essayez de ne rien changer qui puisse affecter les performances.

N'oubliez pas que vous effectuez une analyse comparative et comparez deux ensembles de matériel, et non votre infrastructure. Traitez tous les logiciels comme une boîte noire et mesurez simplement les performances du matériel.

Enfin, envisagez de sauvegarder les ensembles de données et de les utiliser pour évaluer de la même manière toute modification ultérieure apportée au logiciel.

Si votre système est censé être capable de gérer plusieurs clients appelant tous en même temps, votre référence doit en tenir compte. Notez que certains appels ne joueront pas bien ensemble. Par exemple, si 25 threads publient le même bit d'information en même temps, cela peut entraîner un verrouillage du serveur, faussant ainsi les résultats.

D'un point de vue technique, j'ai utilisé Perl et son module de référence pour recueillir les informations qui me tiennent à cœur.

Si vous comparez des matériels différents, mesurer le coût par transaction vous donnera une bonne comparaison des compromis entre matériel et performances. Une configuration peut vous donner les meilleures performances, mais coûte trop cher. Une configuration moins coûteuse peut vous donner des performances suffisantes.

Il est important d'imiter le "pire des cas". ou " heure de pointe " de charge. Il est également important de tester avec "typique". les volumes. C’est un exercice d’équilibrage que d’obtenir une bonne utilisation du serveur, qui ne coûte pas trop cher, qui donne les performances requises.

Les tests sur différentes configurations matérielles deviennent rapidement coûteux. Une autre option viable consiste à mesurer d’abord la configuration que vous avez, puis à simuler ce comportement sur des systèmes virtuels à l’aide d’un modèle.

Si vous le pouvez, essayez d’enregistrer certaines opérations effectuées par les utilisateurs (ou processus) avec votre infrastructure, en utilisant idéalement un clone du système réel. Cela vous donne les données les plus réalistes. Points à considérer:

  1. Quelles sont les fonctions les plus utilisées?
  2. Quelle quantité de données est transférée?
  3. Ne supposez rien. Si vous pensez que cela va être rapide / lent, ne pariez pas dessus. Dans 9 cas sur 10, vous vous trompez.

Créez un top dix pour 1 + 2 et travaillez à partir de cela.

Cela dit: si vous remplacez l'ancien matériel par un nouveau, vous pouvez vous attendre à une exécution environ 10% plus rapide pour chaque année écoulée depuis l'achat du premier jeu (si les systèmes sont par ailleurs relativement égaux).

Si vous avez un système spécialisé, les chiffres peuvent être complètement différents, mais généralement, le nouveau matériel ne change pas beaucoup. Par exemple, l'ajout d'un index utile à une base de données peut réduire le temps d'exécution d'une requête de deux heures à deux secondes. Le matériel ne vous donnera jamais cela.

Selon moi, il existe deux types de points de repère en ce qui concerne les logiciels d'analyse comparative. Tout d’abord, les micro-repères, lorsque vous essayez d’évaluer un morceau de code de manière isolée ou la façon dont un système traite une charge de travail définie de manière étroite. Comparez deux algorithmes de tri écrits en Java. Comparez deux navigateurs Web à quelle vitesse chacun peut effectuer une opération de manipulation DOM. Deuxièmement, il existe des points de repère du système (je viens de nommer le nom) lorsque vous essayez d’évaluer un système logiciel avec une charge de travail réaliste. Comparez mon backend basé sur Python fonctionnant sur Google Compute Engine et sur Amazon AWS.

Lorsque vous utilisez Java, par exemple, gardez à l’esprit que la machine virtuelle doit s’échauffer avant de pouvoir vous donner des performances réalistes. Si vous mesurez le temps avec la commande time , le temps de démarrage de la machine virtuelle Java sera inclus. Vous voulez presque toujours ignorer l'heure de démarrage ou la suivre séparément.

Microbenchmarking

Lors de la première exécution, les caches de processeur sont remplis avec les données nécessaires. La même chose vaut pour les caches de disque. Au cours de quelques exécutions ultérieures, la VM continue de chauffer, ce qui signifie que JIT compile ce qu'il juge utile de compiler. Vous souhaitez ignorer ces exécutions et commencer à mesurer par la suite.

Faites beaucoup de mesures et calculez des statistiques. Moyenne, médiane, écart type, tracer un graphique. Regardez-le et voyez à quel point cela change. Les choses qui peuvent influer sur le résultat incluent les pauses GC dans la machine virtuelle, l’échelle de fréquence sur le CPU, un autre processus peut démarrer une tâche en arrière-plan (comme la recherche de virus), le système d’exploitation peut décider de déplacer le processus sur un autre cœur de processeur, si vous avoir une architecture NUMA , les résultats seront encore plus marqués.

Dans le cas des micro-repères, tout cela pose problème. Tuez ce que vous pouvez faire avant de commencer. Utilisez une bibliothèque d'analyse comparative qui peut en faire une partie pour vous. Comme https://github.com/google/caliper et ainsi de suite.

Analyse comparative du système

Dans le cas d’une analyse comparative d’un système soumis à une charge de travail réaliste, ces détails ne vous intéressent pas vraiment et votre problème n’est "que". savoir en quoi consiste une charge de travail réaliste, comment la générer et quelles données collecter. Il est toujours préférable de pouvoir instrumenter un système de production et y collecter des données. Vous pouvez généralement le faire, car vous mesurez les caractéristiques de l'utilisateur final (combien de temps une page Web a restituée) et celles-ci sont liées aux E / S afin que la collecte de code ne ralentisse pas le système. (La page doit être envoyée à l'utilisateur via le réseau. Peu importe si nous enregistrons également quelques numéros dans le processus.)

Soyez conscient de la différence entre le profilage et le benchmarking. L'analyse comparative peut vous donner le temps absolu passé à faire quelque chose, tandis que le profilage vous donne le temps relatif passé à faire quelque chose comparé à tout ce qui doit être fait. En effet, les profileurs exécutent des programmes fortement instrumentés (la technique courante consiste à arrêter le monde toutes les quelques centaines de millisecondes et à enregistrer une trace de pile) et que l'instrumentation ralentit considérablement le processus.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top