3. Le Linux Benchmarking Toolkit (LBT)

Contenu de cette section

Je propose ici un ensemble d'outils pour l'évaluation de performances sous Linux. C'est la version préliminaire d'un vaste environnement d'évaluation de performances pour Linux, il est destiné à être amélioré et à voir ses fonctionnalités étendues. Prenez le pour ce qu'il vaut, c'est-à-dire une proposition. Si vous pensez que cette suite de test n'est pas valable, prenez la liberté de m'envoyer (ndt : à l'auteur et non au traducteur, merci :-) vos critiques par e-mail et soyez sûrs que je serai heureux d'intégrer les changements que vous aurez suggéré dans la mesure du possible. Avant d'entamer une polémique, lisez ce HOWTO et les documents cités en référence : les critiques informés sont les bienvenus, les critiques stériles ne le sont pas.

3.1 Motivations

Elles sont dictées par le bon sens, tout simplement :

  1. Cette suite ne doit pas nécessiter plus d'une journée de durée d'exécution. En matière de benchmarks comparatifs (diverses exécutions), personne ne veut passer des jours à essayer de trouver la configuration matérielle le plus rapide pour un système donné. Idéalement, l'ensemble de la suite devrait pouvoir tourner en 15 minutes sur une machine moyenne.
  2. Tout le code source doit être disponible librement sur le Net, pour des raisons évidentes.
  3. Les benchmarks devraient fournir des chiffres simples et reflétant la performance mesurée.
  4. Il devait y avoir un mélange de benchmarks synthétiques et de benchmarks applicatifs.
  5. Chacun des benchmarks synthétiques devrait pousser un sous-système particulier à ses limites.
  6. Les résultats des benchmarks synthétiques ne devraient pas être combinés par le biais d'une moyenne afin d'en extraire un facteur de mérite global (cela va à l'encontre du principe fondateur des benchmarks synthétiques et conduit à une perte d'information considérable).
  7. Les benchmarks applicatifs devraient être représentatifs de tâches couramment exécutées sur des systèmes Linux.

3.2 Sélection des benchmarks

J'ai sélectionné 5 suites des benchmarks différentes en évitant autant que possible les recouvrements dans les tests :

  1. Compilation du noyau 2.0.0 (configuration par défaut) avec gcc.
  2. Whetstone version 10/03/97 (la version la plus récente de Roy Longbottom).
  3. xbench-0.2 (avec les paramètres d'exécution rapide).
  4. Les benchmarks UnixBench version 4.01 (résultats partiels).
  5. Les benchmarks de la suite BYTEmark du magazine BYTE beta release 2 (résultats partiels).

Pour les tests 4 et 5, "(résultats partiels)" signifie qu'une partie seulement des résultats produits est prise en compte.

3.3 Durée des tests

  1. Compilation du noyau 2.0.0 : 5 - 30 minutes, selon la performance réelle de votre machine.
  2. Whetstone : 100 secondes.
  3. Xbench-0.2 : < 1 heure.
  4. Les benchmarks d'UnixBench version 4.01 : environs 15 minutes.
  5. Les benchmarks de la suite BYTEmark du magazine BYTE : environs 10 minutes.

3.4 Commentaires

Compilation du noyau 2.0.0

La suite Whetstone

Xbench-0.2

UnixBench version 4.01

(ndt : la moyenne géométrique se définit comme la racine n-ième du produit des n termes considérés)

Les benchmarks Bytemark du magazine BYTE

3.5 Améliorations possibles

La suite de benchmarks idéale tournerait en quelques minutes, comprendrait des benchmarks synthétiques testant chaque sous-système séparément et des benchmarks applicatifs fournissant des résultats pour différentes applications. Elle produirait aussi automatiquement un rapport complet et éventuellement l'enverrait par e-mail à une base de données centrale sur le Web.

La portabilité n'est pas vraiment notre souci premier dans cette affaire. Pourtant, une telle suite devrait tourner au moins sur toutes les versions (> 2.0.0) du noyau Linux, et ce dans toutes leurs déclinaisons possibles (i386, Alpha, Sparc...).

Si quelqu'un a la moindre idée concernant l'évaluation de performances réseau au moyen d'un test à la fois simple, facile d'emploi, fiable, et dont la mise en oeuvre prendrait moins de 30 minutes (configuration et exécution), s'il vous plait contactez-moi.

3.6 Formulaire de rapport LBT

Au-delà des tests, la procédure d'évaluation de performances n'aurait pas été complète sans un formulaire décrivant la configuration matérielle utilisée lors de leur exécution. Le voici donc : (il se conforme aux directives prescrites dans la FAQ de comp.benchmarks) :

(ndt : le formulaire en question n'a délibérément pas été traduit, de façon à ce que l'auteur de ce HOWTO puisse automatiser leur traitement en vue de maintenir une base de données de résultats. Voir la section 4 pour un exemple de formulaire correctement rempli).

______________________________________________________________________
LINUX BENCHMARKING TOOLKIT REPORT FORM
______________________________________________________________________

______________________________________________________________________
CPU
==
Vendor:
Model:
Core clock:
Motherboard vendor:
Mbd. model:
Mbd. chipset:
Bus type:
Bus clock:
Cache total:
Cache type/speed:
SMP (number of processors):
______________________________________________________________________

______________________________________________________________________
RAM
====
Total:
Type:
Speed:
______________________________________________________________________

______________________________________________________________________
Disk
====
Vendor:
Model:
Size:
Interface:
Driver/Settings:
______________________________________________________________________

______________________________________________________________________
Video board
===========
Vendor:
Model:
Bus:
Video RAM type:
Video RAM total:
X server vendor:
X server version:
X server chipset choice:
Resolution/vert. refresh rate:
Color depth:
______________________________________________________________________

______________________________________________________________________
Kernel
=====
Version:
Swap size:
______________________________________________________________________

______________________________________________________________________
gcc
===
Version:
Options:
libc version:
______________________________________________________________________

______________________________________________________________________
Test notes
==========
______________________________________________________________________

______________________________________________________________________
RESULTS
========
Linux kernel 2.0.0 Compilation Time: (minutes and seconds)
Whetstones: results are in MWIPS.
Xbench: results are in xstones.
Unixbench Benchmarks 4.01 system INDEX:
BYTEmark integer INDEX:
BYTEmark memory INDEX:
______________________________________________________________________

______________________________________________________________________
Comments*
=========
* Ce champ n'est present dans ce formulaire que pour de possibles
interpretations des resultats, et tant que tel, il est optionnel.
Il pourrait cependant constituer la partie la plus importante de votre
compte-rendu, tout particulierement si vous faites de l'evaluation
de performances comparative.
______________________________________________________________________

3.7 Test de performances réseau

Le test des performances réseau est un véritable défi en soi puisqu'il implique au moins deux machines: un serveur et une machine cliente. Pour cette raison ce genre de test nécessite deux fois plus de temps pour être mis en place, il y a plus de variables à contrôler, etc... Sur un réseau Ethernet, il me semble votre meilleure option est le paquetage ttcp. (à developper)

3.8 Les tests SMP

Les tests SMP sont un autre défi, et tout test conçu spécifiquement pour un environnement SMP aura des difficultés à s'avérer valide dans des conditions d'utilisation réelles parce que les algorithmes qui tirent parti du SMP sont difficiles à développer. Il semble que les versions du noyau Linux les plus récentes (> 2.1.30 ou pas loin) feront du scheduling (ndt : ordonnancement de thread ou de processus) à grain fin ; je n'ai pas plus d'information que ça pour le moment.

Selon David Niemi, "... shell8 de la suite Unixbench 4.01 fait du bon travail en matière de comparaison de matériel/SE similaires en mode SMP et en mode UP."

(ndt : SMP = Symetric Multi-Processing, UP = Uni-Processor)


Chapitre suivant, Chapitre Précédent

Table des matières de ce chapitre, Table des matières générale

Début du document, Début de ce chapitre