BenchMarkAbstraction

Un livre de Wikibooks.

Sections

[modifier] A propos des tests

Tests réalisés sur un Pentium 4 2.0Ghz sous Windows XP SP2, 760Mo de mémoire vive. Partitions en FAT32, MySQL 4.1.9, PHP 4.3.10 La table n'a pas été vidé entre chaque test, les tests ont été réalisés plusieurs fois, j'ai obtenu des temps d'exécution très proches et j'en ai fais la moyenne que j'ai mis dans le tableau en bas.

Si j'en ai le temps je mettrai une archive permettant de tester vous même. Si j'en ai le temps je ferai un bench en select et en update.

[modifier] Procédure de test QueryTool

   $dbDSN = 'mysql://root@localhost/test';
   class user extends DB_QueryTool
   {
       var $table =        "personne";
       var $primaryCol =   'prs_id';
   }
   $user = new user( $dbDSN );
   $start_time = microtime();
   var_dump($start_time);
   for ($a = 0; $a < 10000; $a++) {
     $data = array( 'prs_nom' => getname(rand(4,6)), 'prs_prenom' => getname(rand(4,6)), 'prs_cp' => getcp() );
     $fooBarId = $user->save($data);
   }
   $end_time = microtime();
   var_dump($end_time);
   print "temps d'execution";
   showtime($start_time, $end_time);

[modifier] Procédure de test Origin

 $db = new mySQL();
 $db->host   = "localhost";
 $db->user   = "root";
 $db->dbname = "test";
   $start_time = microtime();
   var_dump($start_time);
   for ($a = 0; $a < 10000; $a++) {
     $data = array( 'prs_nom' => getname(rand(4,6)), 'prs_prenom' => getname(rand(4,6)), 'prs_cp' => getcp() );
     $db->insert($data, "personne");
     $id = $db->lastId();
   }
   $end_time = microtime();
   var_dump($end_time);
   print "temps d'execution";
   showtime($start_time, $end_time);

[modifier] Procédure de test MySQL

 $link = mysql_connect("localhost", "root", "");
   $start_time = microtime();
   var_dump($start_time);
   for ($a = 0; $a < 10000; $a++) {
     mysql_query("INSERT INTO personne('prs_nom','prs_prenom','prs_cp') VALUES('".getname(rand(4,6))."','".getname(rand(4,6))."',".getcp().")");
     $id = mysql_insert_id();
   }
   $end_time = microtime();
   var_dump($end_time);
   print "temps d'execution";
   showtime($start_time, $end_time);

[modifier] Comparatif

Nb Requetes 1000 3000 5000 10000
QueryTool 2.4 7.15 12.1 24.15
Origin 0.77 2.38 3.98 7.8
mySQL 0.26 0.78 1.3 2.54

[modifier] Importance et pertinence des tests ?

En effet je me demande si ces benchs doivent vraiment nous faire peur ou pas. Nous n'aurons pas à faire 1000 insert à la suite. Nous ferons dans les 20 requetes insertion de logs grand maximum. Il faut tester les select surtout en réalité, car par contre pendant la phase d'archivage nous aurons vite à faire 200 ou plus de requetes de type select compliquées. Mais si je ne m'abuse ce qui prend du temps avec ces outils c'est bien juste la construction de la requete ? Cela devient juste pénalisant quand il y a beaucoup de requetes, et ce peu importe la lourdeur de ces requetes ? Si c'est bien cela, alors il faut voir car cela pourra poser problème éventuellement, mais à l'archivage, et non pendant l'enregistrement des logs, et il faut tester sur des SELECT surtout. J'attends ton bench la dessus. Egalement fais des tests avec jointure stp :)

on a pas 10000 insert à faire d'un coup mais on aura 200 à 300 connexions à gérer en même temps, chacune faisant 5 ou 6 inserts ... donc au final la le temps d'exécution sera du même ordre. Atomik 25 jul 2005 à 14:42 (UTC)


Autre : je me demande le comportement lorsque 1 même requete renvoie par exemple 1000 lignes. Le temps ne doit pas multiplié par 10 comme dans les tests ci dessus puisque la requête n'est pas construit 1000 fois je pense, mais 1 fois mais renvoie 1000 lignes donc il faut quand même appeler ce qui en mysql est la fonction mysql_query() 1000 fois. Quel est le comportemetn via query_tool ?

Merci d'augmenter la précision de tests et leur profondeur pour permettre de répondre à ces questions. Je continue d'y réfléchir mais il doit y avoir d'autres feintes comme celles ci je pense ? Matthieu

Ces tests ne me parraissent pas pertinents en l'état (je précise bien, en l'état) car ils manquent cruellement d'informations ! type de machine (processeur, disque dur, mémoire), etat de la machine (type de partition, O/S, fragmentation disque ou partition), base de données (version, etat des tables avant chaque insert, ...). De surcroit, tu utilises des fonctions rand() qui sont gourmandes en terme de temps (qui peut en plus différent suivant la plateforme et le type de processeur), et il manque quelques bouts de code, ainsi que les versions des bibliohtèques que tu utilises... Ce Wiki pourrait cependant devenir interesant en proposant un script complet, à exécuter sur l'environnement du lecteur, qui produirait un résultat intégrable à grande échelle pour faire des stats...
Qu'en penses tu ?--Demzed 22 jul 2005 à 08:40 (UTC)
je suis pas sur que toutes les informations sur l'état de la machine qui a éxécuté les tests soients si important, au final c'est surtout une histoire de ratio entre les différents temps de traitement. Il faut retenir que DB prends 10x plus de temps qu'un mysql brut et ce quelquesoit le nombre de requêtes.
par contre je suis d'accord que pour se donner un ordre d'idées sur les temps de réponses attendu lorsque l'on développe il est intéressant de savoir à peu près à quoi s'attendre.
je pense aussi qu'il serait interressant de proposer un bench distribuable et exécutable sur les machines du lecteur.
Atomik 25 jul 2005 à 14:42 (UTC)


[modifier] Deuxième série de tests

Cet après-midi on s'est amusé à faire de nouveaux tests de couches d'abstractions Les concurrents étaient : mysql natif , Adodb , AdodbLite et Pear::DB

[modifier] Conditions de test

- Serveur Athlon XP 1700+ - Memoire 256 Mo - Apache 2.0.54 - PHP 5.0.4

[modifier] Protocole

Vous trouverez tous les scripts de tests dans une archive téléchargeable : ici et sinon, les tests sont consultables en ligne sur : mon serveur

4 tests ont été effectués:

  1. "SELECT id, prenom, nom, cp FROM personne LIMIT $limit" appelé Select base
  2. "SELECT personne.id, prenom, nom, cp, data1, data2, data3 FROM personne, datas WHERE personne.id = datas.personne_id LIMIT $limit"
  3. "INSERT INTO personne(prenom,nom,cp) VALUES('".getString()."','".getString()."','".getString()."')"
  4. Et la derniere qui est une combinaison de la precedente et de: "INSERT INTO datas (personne_id, data1, data2, data3) VALUES ($id, '" .getString()."','".getString()."','".getString()."')"

Chaque mesure a été prise 10 fois , voila les resultats qui sont récuperables en pdf ici


Moyenne de 10 mesures effectuées

Select Base

Mysql

Adodb Lite

Ratio

Adodb

Ratio

PearDB

Ratio

100

0,002665209770

0,005527544022

2,07

0,006073069572

2,28

0,010822582245

4,06

1000

0,016507816315

0,040828752518

2,47

0,041392731667

2,51

0,092168879509

5,58

10000

0,157842969894

0,396399712563

2,51

0,403436660767

2,56

0,903160452843

5,72

Select complexe

Mysql

Adodb Lite

Ratio

Adodb

Ratio

PearDB

Ratio

100

0,004509878159

0,007393956184

1,64

0,007629513741

1,69

0,014100003242

3,13

1000

0,032515478134

0,058722567558

1,81

0,058887505531

1,81

0,107894778252

3,32

10000

0,316154789925

0,580163574219

1,84

0,579060173035

1,83

1,062700080872

3,36

Insert base

Mysql

Adodb Lite

Ratio

Adodb

Ratio

PearDB

Ratio

100

0,056891727448

0,088535737991

1,56

0,171604251862

3,02

0,199182701111

3,5

1000

0,572428703308

0,870286822319

1,52

1,709198999405

2,99

1,945038819313

3,4

10000

5,728188300133

8,815959715843

1,54

17,380733299255

3,03

19,659129166603

3,43

Insert complexe

Mysql

Adodb Lite

Ratio

Adodb

Ratio

PearDB

Ratio

100

0,119825267792

0,180384135246

1,51

0,263805937767

2,20

0,300176525116

2,51

1000

1,198239421845

1,822519397736

1,52

2,625509977341

2,19

3,017036652565

2,52

10000

12,076713681221

18,516474580765

1,53

26,223340129852

2,17

30,594590067863

2,53

En resumé il en ressort que la couche d'abstraction Adodb Lite est une plutôt bonne concurrente a mysql natif, et qui autorise (ce qui ne gache rien) une portabilité sur une bonne 10aine de SGBD

Adodb Lite étant un subset des fonctionnalités de la librairie Adodb, il est parfaitement envisageable de pouvoir coder la partie Stockage des stats avec la Lite afin de pouvoir absorber la charge que ca peut occasionner, et parallellement, utiliser Adodb Standard pour coder la partie Backoffice / archivage qui elle sera forcement moins gourmande en charge.

Récupérée de « http://fr.wikibooks.org/wiki/BenchMarkAbstraction »