Pourquoi faire attention au volume du jeu de données en base

1. La source du problème

Lorsqu'on développe une application, pour gagner du temps on travaille souvent avec des jeux de données réduits.
En dehors de la question de pure "facilité", cela permet également de :

• réduire le temps d’exécution des requêtes SQL ;
• réduire le temps de chargement de la sauvegarde de la base ;
• avoir toute l'application sur son poste de travail ;

2. Ses conséquences

Malheureusement ce temps gagné peut être rapidement perdu si des tests avec une volumétrie proche de ce qu'il y aura en production ne sont pas exécutés au plus tôt. Car lorsque l'application n'est pas testée en amont avec une volumétrie réelle, on pourra se retrouver avec des nombreux problèmes de performance, non identifiés au préalable, et qui nécessiteront des retours à la case développement (et donc du temps et de l'argent).
Ces problèmes peuvent être :

• des problèmes de conception ;
• des problèmes d'architecture matériel et/ou logiciel ;
• des problèmes d'algorithme ;
• des problèmes de conception du schéma de base de données ;
• des problèmes de choix de composant ;
• des problèmes de paramétrage ;
• des problèmes de stabilités ;

Bien sûr ces problèmes peuvent aussi apparaître lors de la campagne de test de performance si le choix de la volumétrie n'a pas été bon.

3. Passons à la pratique

Voila quelques exemples pour illustrer ces problèmes.

3.1 Exemple 1

Pour notre premier exemple, regardons l'application de démonstration PlantsByWebSphere livré avec IBM WebSphere.

Voici la page de sélection d'un article avec la volumétrie de base.

Et son temps d'affichage.

Maintenant, utilisons Benerator afin d'augmenter la volumétrie.

On constate qu'il aurait été judicieux de limiter le nombre d'articles affichés par page.

Le temps d'affichage confirme que la page met quatre fois plus de temps et que cela devient un problème.

3.2 Exemple 2

Prenons un deuxième exemple.

Cette fois ci on va étudier l'impact de la volumétrie directement au niveau base de données.

Notre schéma sera le suivant.



Et son code SQL sera.

CREATE TABLE t_conducteur (
  id_conducteur INT NOT NULL,
  nom VARCHAR(64),
  prenom VARCHAR(64),
  email VARCHAR(64),
  PRIMARY KEY  (id_conducteur)
);
 
CREATE TABLE t_voiture (
  id_voiture INT NOT NULL,
  prix INT,
  couleur VARCHAR(64) NOT NULL,
  conducteur_fk INT NOT NULL,
  PRIMARY KEY  (id_voiture),
  CONSTRAINT t_voiture_conducteur_fk FOREIGN KEY (conducteur_fk) REFERENCES t_conducteur (id_conducteur)
);



Utilisons encore Benerator pour générer un petit volume de données.

<?xml version="1.0" encoding="iso-8859-1"?>
<setup 
	xmlns="http://databene.org/benerator/0.7.2"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://databene.org/benerator/0.7.2 http://databene.org/benerator-0.7.2.xsd">
 
	<import domains   = "person,net,address" />
	<import platforms = "db"/>
 
<database id="db" url="jdbc:postgresql://localhost:5432/postgres" driver="org.postgresql.Driver" catalog="postgres" schema="public" user="benerator" password="benerator" batch="true" fetchSize="1000"/>
 
 
<bean id="idGen" spec="new DBSeqHiLoGenerator('seq_pq_data_id_gen', 1, db)" />
 
 
<generate type="t_conducteur" count="1000" consumer="db" pageSize="1000" >
<variable name="individu" generator="org.databene.domain.person.PersonGenerator" dataset="FR" locale="fr"/>
	<id name="id_conducteur" generator="idGen" />
	<attribute name="prenom" script="individu.givenName" />
	<attribute name="nom" script="individu.familyName" />
	<attribute name="email" script="individu.email" />	
</generate>
 
<generate type="t_voiture" count="3000" consumer="db" pageSize="1000">
	<id name="id_voiture" generator="idGen" />
	<attribute name="prix" min="8000" max="200000" />
	<reference name="couleur" values="'rouge','verte','noir','blanche','jaune','orange','bleu','violette','grise','bleu ciel','gris clair'" />
	<reference name="conducteur_fk" targetType="t_conducteur" source="db" distribution="expand" cyclic="true" />
</generate>
 
</setup>



Utilisons JMeter pour exécuter mille fois cette requête.

SELECT * FROM t_conducteur 
LEFT JOIN t_voiture 
ON id_conducteur=conducteur_fk 
WHERE couleur = 'rouge'



Voila les résultats

 
Maintenant augmentons la volumétrie de 500 000 entrées par table et rejouons le même test.


 
Comme on peut le constater, les temps de réponse n'ont plus rien à voir.

4. Mon conseil

Mon conseil est de faire au plus tôt des tests (des POC pendant la phase de conception, des tests composites, des tests de charge pour valider l'architecture et la robustesse des couches applicatives ) avec une volumétrie la plus proche de la réalité afin de minimiser au maximum les risques liés au volume de données.