Forum général.général Informations pertinentes pour un banc d'essai ?

Posté par  .
Étiquettes : aucune
-1
2
juin
2011

Bonjour.
Je cherche à faire un banc d'essai de plusieurs wrappers à Pacman, sous Archlinux, afin de me faire une idée précise loin des trolls des forums et de irc, dans la mesure du possible, chaque wrapper possédant certaines fonctions propres.
Cependant, je me pose la question des informations pertinentes à mesurer, et dans quel contexte.
Tout d'abord, une mise à jour complète du système avec les paquets AUR me semble pertinente, mais comment garder les mêmes conditions de test ? (chroot dans un système constant ?)
L'installation d'un programme venant de AUR semble plus facile à faire dans des conditions constantes, mais le second problème est quoi mesurer ?
Voici une petite liste: temps réel écoulé, nombre total de secondes-CPU passe par le processus en mode noyau, nombre total de secondes-CPU passe par le processus en mode utilisateur, pourcentage de CPU obtenu par la tache, taille maximale du processus en mémoire physique durant son exécution, nombre de lecture dans les fichiers, et nombre d'écriture dans les fichiers.
Est ce suffisant ? Il y a-t-il des choses inutiles, à vos yeux ?
Ces valeurs seraient mesurées par time(1).
Merci d'avance pour vos réponses.

  • # ben je crois que tu as tout dit

    Posté par  . Évalué à 3.

    pour pouvoir comparer il faut evidemment partir d'un etat connu.
    ca peut etre un chroot archivé, que tu restaures entre chaque test

    ca peut aussi etre une machine physique que tu reinstalles entre chaque test.

    Ensuite les tests doivent etre les memes si le but est de comparer les wrappers.
    mais il faut aussi que la source des mises à jours soient la meme (idealement un mirroir que tu maitrises)

    ainsi tu peux faire les tests suiants :
    - mise à jour de l'OS
    - installation d'un paquet donné (sans dependance)
    - installation d'un paquet et de ses dependances
    - deinstallation d'un paquet
    - deinstallation d'un paquet et de ses dependance

    • [^] # Re: ben je crois que tu as tout dit

      Posté par  . Évalué à 1.

      Merci pour l'idée du miroir, je vais en faire un local sur mon disque dur. Je vais créer une image d'un système avec les wrappers que je veux tester, et je chrooterais dans quelques jours, le temps que cette image ne soit plus à jour.
      Sinon, pour le test en lui même, une moyenne sur dix occurrences de la même commande est elle suffisante ?
      Je pense écrire au fur et à mesure les données dans un fichier .csv pour le traiter avec Libreoffice par exemple, mais pour les graphiques, cela me semble fastidieux. Un programme en console serait le bienvenue, si quelqu'un a une idée…
      En tout cas, merci !

      • [^] # Re: ben je crois que tu as tout dit

        Posté par  . Évalué à 1.

        Pour le nombre d’occurences N. L’idéal est de calculer l’écart-type σ non-biaisé, la plupart des logiciels ou langages numériques ont une fonction « std ». La moyenne aura une écart-type ν=σ/√N. L’idéal est de donner l’erreur qui vous commettez sur la moyenne, qui sera en théorie : ε=3ν.

        Ensuite à vous d’augmenter ou réduire N en fonction de l’erreur ε acceptable. Si la mesure n’est faite qu’un petit nombre de fois ce n’est pas très rigoureux, mais au moins ça donne un ordre de grandeur, et ce sera infiniment mieux que n’importe quel benchmark informatique !

        Pour le script, en python ça donnerait un truc comme ça, disons un fichier ASCII avec m colonnes (pour différentes mesures) et n échantillons. Attention a bien avoir des réels en entrée, avec des entiers ça peut poser problème.

        from numpy import *
        from matplotlib import *
        tab = loadtxt('fichier.dat')
        moyenne = []
        error = []
        for i in range(m):
          moyenne.append(mean(tab[:,i]))
          error.append(3*std(tab[:,i], ddof=1)/sqrt(len(tab[:,i])))
        errorbar(range(m), moyenne, error)
        

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.