Blog Aliecom

Aliecom au Breizhcamp 2012 !

Stéphane Chabrier — Mon, 07 May 2012 11:15:54 +0000

Le 14 et 15 Juin prochain se tiendra la Breizhcamp version 2012 avec au programme une multitude de sujets sur des technologies éprouvées, des méthodologies et des nouveaux outils.

A ce titre, Aliecom sera présent pour parler de la "mesure de la performance dans le milieu hostile du développement Java".

Antonio Gomes-Rodrigues, consultant expert justifiant de plusieurs années d'expérience sur les sujets gravitant autour de la performance, va nous apporter un peu de recul sur ce sujet extrêmement sensible et qui fait souvent défaut aux équipes d'intégration.

Un petit avant-goût du programme :

"Lors de mes missions d'audit de performance, je vois régulièrement de gros problèmes de performance qui auraient pu être anticipés par le développeur sur son environnement de travail local. Partant de ce constat nous prendrons comme contexte le poste de développement d’un ingénieur Java intégré dans une équipe qui ne prête pas particulièrement attention à la notion de performance. Nous démontrerons qu'il ne faut pas vouloir tout optimiser mais plutôt les 20% utiles. (loi de Pareto) Afin de cibler ces 20% nous aborderons en détail l'importance de la mesure de la performance. Puis nous finirons par la présentation d'un certain nombre d'outils et pratiques permettant ces mesures. "

Venez nombreux, il y a plein de sujets passionnants ... et en plus c'est pas cher !!

ContiPerf

Antonio Gomes-Rodrigues — Mon, 19 Mar 2012 21:34:09 +0000

1. Introduction

Lorsque l’on fait du développement Java, on ne se préoccupe pas toujours des problèmes de performance. Et lorsque la performance est une contrainte, on ne sait pas toujours comment la mesurer et avec quel outil.
Idéalement, cet outil s'intègrerait à notre environnement de développement et se lancerait automatiquement.

En somme, il nous faudrait un framework comme JUnit mais dédié à la performance.

2. Présentation de ContiPerf

Bonne nouvelle, cela existe et porte le nom de ContiPerf.

ContiPerf se présente comme une surcouche à JUnit 4 pour les tests de performances, avec toutes ces facilités et avantages :

configuration par annotations ;
intégration avec les IDE supportant JUnit 4 comme Eclipse, Netbeans... ;
intégration avec Apache Maven ;
aucune dépendance à part JUnit ;
export des résultats au format CSV et HTML ;
regroupement des tests en Test Suites.

Attention, ContiPerf ne remplace pas une bonne méthode de test de performance (avoir des résultats reproductibles, avoir les bons jeux de test...) et en particulier les tests de charge.
De plus, il n'est pas encore adapté au microbenchmarking.

Pour plus d'informations, le site officiel est très complet.

Avant de commencer à écrire des tests unitaires de performance, regardons comment intégrer ContiPerf à notre environnement de développement.

3. Intégration dans un IDE

Afin d'intégrer ContiPerf à votre IDE, il suffit d'ajouter la librairie contiperf.jar dans le Classpath.

Puis afin de lancer le test, on fait comme pour JUnit.

Par exemple avec Netbeans.

4. Intégration avec Maven

L'intégration à Maven est tout aussi simple.

 
> 
>org.junit> 
>com.springsource.org.junit> 
>4.7.0> 
>test> 
> 
 
    > 
      >org.databene> 
      >contiperf> 
      >2.0.0> 
      >test> 
    >

5. Go pour la pratique

Maintenant que vous êtes entièrement convaincu (enfin j'espère !), regardons d'un peu plus près comment écrire un test de performance ContiPerf.

Pour ceux qui n'ont pas l'habitude de JUnit, je leur conseille de l'étudier avant.

6. Écrire un test ContiPerf

Pour un test, il nous faut :

un objet ContiPerfRule et son annotation @Rule ;
un protocole de test (nombre d'itération, nombre de thread, durée du test) défini à l'aide de l'annotation @PerfTest ;
des critères d'acceptance (moyenne / médian / max / percentiles / durée totale / throughput / temps de réponses) définis à l'aide de l'annotation @Required ;
du code métier.

Le tout aura la forme suivante

  import org.junit.*; 
  import org.databene.contiperf.*; 
 
  public class SimpleTest { 
 
      @Rule 
      public ContiPerfRule i = new ContiPerfRule(); 
 
      @Test 
      @PerfTest(invocations = 1000, threads = 20) 
      @Required(max = 1200, average = 250, median = 300) 
      public void testCodeMetier() throws Exception { 
          // code metier a tester 
      } 
 
  }

Si l'on veut que ContiPerf génère aussi les rapports, il faut remplacer la ligne

      @Rule 
      public ContiPerfRule i = new ContiPerfRule();

par

    @Rule 
    public ContiPerfRule rule = new ContiPerfRule( 
            new HtmlReportModule(), 
            new CSVSummaryReportModule(), 
            new CSVInvocationReportModule(), 
            new CSVLatencyReportModule());

7. Exemple 1 : maximum 15ms avec une moyenne inférieure à 10ms

Nous allons écrire des tests ContiPerf pour l'application Spring PetClinic.

Dans un premier temps, nous allons tester la class org.springframework.samples.petclinic.Pet

Testons la création (new Pet) de 100 chiens prénommés Medor (setName).

@Rule 
    public ContiPerfRule i = new ContiPerfRule(); 
 
    @Test 
    @PerfTest(invocations = 100, threads = 100) 
    @Required(max = 15, average = 10) 
    public void testsetName() { 
        Pet monChien = new Pet(); 
        monChien.setName("Medor"); 
    }

Dans ce test, on crée 100 chiens (invocations = 100) en parallèle (1 par thread) et on veut qu'une création dure au maximum 15ms (max) avec une moyenne (average) inférieure à 10ms.

8. Exemple 2 : maximum 15ms avec une moyenne inférieure à 10ms

Reprenons le même exemple, mais cette fois ci pour certaines raisons (par exemple un pool), on sait qu'il n'y aura jamais plus de 10 créations de chien en même temps.

L'exemple devient.

    @Rule 
    public ContiPerfRule i = new ContiPerfRule(); 
 
    @Test 
    @PerfTest(invocations = 100, threads = 10) 
    @Required(max = 15, average = 10) 
    public void testsetName() { 
        Pet monChien = new Pet(); 
        monChien.setName("Medor"); 
    }

Ici chaque thread va créer 10 chiens (invocations/threads) pour un total de 100 chiens.

9. Exemple 3 : throughput au minimum de 400

Toujours avec le même exemple mais maintenant on veut que le throughput soit au minimum de 400 invocations par seconde.

    @Rule 
    public ContiPerfRule i = new ContiPerfRule(); 
 
    @Test 
    @PerfTest(duration = 100000, threads = 10) 
    @Required(throughput = 400) 
    public void testsetName() { 
        Pet monChien = new Pet(); 
        monChien.setName("Medor"); 
    }

Ici le test dure 100s.

10. Exemple 4 : percentil

Enfin, pour ceux qui trouvent que l'utilisation du percentil est plus intéressante que la moyenne, il suffit de modifier le test de l'exemple 2 en remplaçant average par percentile99.

Par exemple, si on veut que 99% des exécutions ne durent pas plus de 6ms, l'exemple devient.

    @Rule 
    public ContiPerfRule i = new ContiPerfRule(); 
 
    @Test 
    @PerfTest(invocations = 100, threads = 10) 
    @Required(max = 10, percentile99 = 6) 
    public void testsetName() { 
        Pet monChien = new Pet(); 
        monChien.setName("Medor"); 
    }

11. Exemple 5 : mutualisation des critères d'acceptance

Continuons avec la class org.springframework.samples.petclinic.Pet

Ajoutons le test de la fonction setType

    @Test 
    @PerfTest(invocations = 100, threads = 10) 
    @Required(max = 10, percentile99 = 5) 
    public void testsetType() { 
        PetType bulldog = new PetType(); 
        bulldog.setName("bulldog"); 
        Pet monChien = new Pet(); 
        monChien.setType(bulldog); 
    }

Lorsqu'on a plusieurs tests pour une classe, on peut regrouper le protocole de test (@PerfTest) et les critères d'acceptance (@Required) au niveau de la classe et plus au niveau des fonctions.

Par exemple, pour mettre en commun notre protocole de test pour les deux tests ContiPerf, il suffit d'écrire le test de la manière suivante.

@PerfTest(invocations = 100, threads = 10) 
public class PetTestsPerf { 
 
    @Rule 
    public ContiPerfRule i = new ContiPerfRule(); 
 
    public PetTestsPerf() { 
    } 
 
    @Test 
    @Required(max = 10, percentile99 = 6) 
    public void testsetName() { 
        Pet monChien = new Pet(); 
        monChien.setName("Medor"); 
    } 
 
    @Test 
    @Required(max = 10, percentile99 = 5) 
    public void testsetType() { 
        PetType bulldog = new PetType(); 
        bulldog.setName("bulldog"); 
        Pet monChien = new Pet(); 
        monChien.setType(bulldog); 
    } 
}

12. Exemple 6

Poursuivons avec un test plus complexe de la classe org.springframework.samples.petclinic.web.VisitsAtomView.

Pour cela, nous allons reprendre le test unitaire qui existe déjà et le transformer en test ContiPerf.

package org.springframework.samples.petclinic.web;
 
import com.sun.syndication.feed.atom.Entry;
import com.sun.syndication.feed.atom.Feed;
import java.util.*;
import org.databene.contiperf.PerfTest;
import org.databene.contiperf.Required;
import org.junit.Before;
import org.junit.Test;
import org.springframework.samples.petclinic.Pet;
import org.springframework.samples.petclinic.PetType;
import org.springframework.samples.petclinic.Visit;
 
@PerfTest(invocations = 100, threads = 10)
public class VisitsAtomViewTestsPerf {
 
    @Rule
    public ContiPerfRule i = new ContiPerfRule();
    private VisitsAtomView visitView;
    private Map<String, Object> model;
    private Feed feed;
 
    @Before
    public void setUp() {
        visitView = new VisitsAtomView();
        PetType dog = new PetType();
        dog.setName("dog");
        Pet bello = new Pet();
        bello.setName("Bello");
        bello.setType(dog);
        Visit belloVisit = new Visit();
        belloVisit.setPet(bello);
        belloVisit.setDate(new Date(2009, 0, 1));
        belloVisit.setDescription("Bello visit");
        Pet wodan = new Pet();
        wodan.setName("Wodan");
        wodan.setType(dog);
        Visit wodanVisit = new Visit();
        wodanVisit.setPet(wodan);
        wodanVisit.setDate(new Date(2009, 0, 2));
        wodanVisit.setDescription("Wodan visit");
        List<Visit> visits = new ArrayList<Visit>();
        visits.add(belloVisit);
        visits.add(wodanVisit);
 
        model = new HashMap<String, Object>();
        model.put("visits", visits);
        feed = new Feed();
 
    }
 
    @Test
    @Required(max = 30, percentile99 = 7)
    public void buildFeedMetadata() {
        visitView.buildFeedMetadata(model, feed, null);
    }
 
    @Test
    @Required(max = 80, percentile99 = 42)
    public void buildFeedEntries() throws Exception {
        List<Entry> entries = visitView.buildFeedEntries(model, null, null);
    }
}

13. Performance Test Suites

Bien sûr, on peut regrouper plusieurs tests ContiPerf dans une Test Suite.

Pour cela, il faut utiliser ces deux annotations.

@RunWith(ContiPerfSuiteRunner.class)
@Suite.SuiteClasses({liste des classes à tester})

Dans notre exemple on aura.

package org.springframework.samples.petclinic; 
 
import org.databene.contiperf.junit.ContiPerfSuiteRunner; 
import org.junit.After; 
import org.junit.AfterClass; 
import org.junit.Before; 
import org.junit.BeforeClass; 
import org.junit.runner.RunWith; 
import org.junit.runners.Suite; 
 
 
@RunWith(ContiPerfSuiteRunner.class) 
@Suite.SuiteClasses({org.springframework.samples.petclinic.PetTestsPerf.class, org.springframework.samples.petclinic.OwnerTestsPerf.class}) 
public class PetclinicTestSuite { 
 
    @BeforeClass 
    public static void setUpClass() throws Exception { 
    } 
 
    @AfterClass 
    public static void tearDownClass() throws Exception { 
    } 
 
    @Before 
    public void setUp() throws Exception { 
    } 
 
    @After 
    public void tearDown() throws Exception { 
    } 
 
}

14 Rapports

Penchons nous un peu plus sur les rapports générés par ContiPerf.

Avec la version 2.0.1, deux formats d'exports sont possibles.

Le format HTML.

Pour avoir ce rapport (fichier index.html) il faut utiliser public ContiPerfRule i = new ContiPerfRule(); ou public ContiPerfRule i = new ContiPerfRule(new HtmlReportModule());

Le format CSV.

Comme on peut le voir, on générer jusqu’à trois fichiers CSV.

summary.csv

Fichier contenant le résumé du test ContiPerf

serviceId,startTime,duration,invocations,min,average,median,90%,95%,99%,max 
org.springframework.samples.petclinic.OwnerTestsPerf.testHasPet,1329047753040,78,1000,0,0.8,0,0,0,24,67

Pour l'obternir, il faut utiliser public ContiPerfRule i = new ContiPerfRule(new CSVSummaryReportModule());

org.springframework.samples.petclinic.OwnerTestsPerf.testHasPet.inv.csv

Fichier contenant le temps de réponse de chaque itération.

latency,startTimeNanos 
67,9452032779934 
63,9452036182461 
0,9452100152044 
0,9452100162800 
0,9452100186266 
0,9452100197511 
0,9452100212177 
0,9452100223492 
62,9452037698296 
62,9452037612671 
64,9452035922372 
67,9452033027032 
59,9452040662290 
59,9452040958767 
59,9452041381935 
61,9452038566633

Pour l’obtenir il faut utiliser public ContiPerfRule i = new ContiPerfRule(new CSVInvocationReportModule());

org.springframework.samples.petclinic.OwnerTestsPerf.testHasPet.stat.csv

Fichier contenant la répartition des temps de réponse. Par exemple, ici on voit qu'il y a eu une réponse avec un temps de réponse de 9ms, neuf cent soixante dix neuf réponses avec un temps de réponse de 0ms, ...

latency,sampleCount 
0,979 
1,0 
2,2 
3,0 
4,2 
5,0 
6,0 
7,0 
8,0 
9,1 
10,0 
11,0

Pour l’obtenir, il faut utiliser public ContiPerfRule i = new ContiPerfRule(new CSVLatencyReportModule());

Comme on peut le voir, on peut faire des choses intéressantes avec les rapports standards (surtout avec les fichiers CSV). Si cela n'est pas suffisant, ContiPerf étant opensource et libre, on peut ajouter facilement enrichir des rapports et des métrics.

Supposons que nous voulions ajouter une metric dans le rapport HTML.

Pour cela nous devons modifier/utiliser trois fichiers sources :

HtmlReportModule : code générant le rapport HTML ;
LatencyCounter : code calculant les metrics de base ;
PerformanceRequirement : code contenant les critères d'acceptance.

Dans le cas de mon besoin initial, les metrics présentés suffisent largement. Celà dit, je reste curieux de vos remarques et des évolutions que vous aurez pu opérer en fonction des votres.

Présentation de l’outil de génération de jeux de données Benerator

Antonio Gomes-Rodrigues — Wed, 15 Feb 2012 13:03:32 +0000

Afin qu'une campagne de tirs de charges soit la plus utile possible, il est souvent nécessaire d'avoir un jeu de données conséquent et réaliste. Pour cela plusieurs solutions existent :

importation des données de la base de données de production ;
création du jeu de données à l'aide d'outils maison ;
utilisation d'ETL ;
utilisation de l’outil de test de charge et/ou de test fonctionnel afin d’exécuter des scripts qui vont remplir la base ;
utilisation d'outil de création de données.

Nous allons nous focaliser sur la dernière solution avec l'utilisation de l'outil Benerator qui couvre largement ce besoin.

1. Un peu de théorie

Pour la partie théorique et quelques exemples, je vous laisse aller sur le site officiel et sur mon précédent article sur developpez.com.

2. Passons à la pratique

2.1 Présentation du cas de test

Dans cet article nous allons nous pencher sur la création de plusieurs jeux de données pour l'application démo PlantsByWebSphere livré avec IBM WebSphere 8. Nous utiliserons une base de données MySQL en remplacement de Derby.

PlantsByWebSphere est une démonstration de boutique en ligne comme vous pouvez le voir sur cette capture d'écran.

On remarque que :

les produits sont divisés en 4 catégories (Flowers, Fruits & Vegetables, Trees et Accessories) ;
l'application gère des comptes clients ;
l'application gère un panier d'achats.

Regardons d'un peu plus près le schéma de la base de données.

Et son code SQL.

CREATE TABLE CUSTOMER
  	 (  CUSTOMERID VARCHAR(250) NOT NULL,
   	 PASSWORD VARCHAR(250),
   	 FIRSTNAME VARCHAR(250),
   	 LASTNAME VARCHAR(250),
   	 ADDR1 VARCHAR(250),
   	 ADDR2 VARCHAR(250),
   	 ADDRCITY VARCHAR(250),
   	 ADDRSTATE VARCHAR(250),
   	 ADDRZIP VARCHAR(250),
   	 PHONE VARCHAR(250));
 
 
 
	ALTER TABLE CUSTOMER
  	    ADD CONSTRAINT PK_CUSTOMER PRIMARY KEY (CUSTOMERID);
 
	CREATE TABLE INVENTORY
  	 (  INVENTORYID VARCHAR(250) NOT NULL,
   	 NAME VARCHAR(250),
   	 HEADING VARCHAR(250),
   	 DESCRIPTION VARCHAR(250),
   	 PKGINFO VARCHAR(250),
   	 IMAGE VARCHAR(250),
       IMGBYTES LONG BIT VARYING,
   	 PRICE REAL,
   	 COST REAL,
       CATEGORY INTEGER,
   	 QUANTITY INTEGER,
	    NOTES VARCHAR(250),
   	 ISPUBLIC INTEGER,
       MINTHRESHOLD INTEGER NOT NULL,
       MAXTHRESHOLD INTEGER NOT NULL);
 
	ALTER TABLE INVENTORY
  	    ADD CONSTRAINT PK_INVENTORY PRIMARY KEY (INVENTORYID);
 
   CREATE TABLE ORDER1
    (  ORDERID VARCHAR(250) NOT NULL,
       SELLDATE VARCHAR(250),
       BILLNAME VARCHAR(250),
       BILLADDR1 VARCHAR(250),
       BILLADDR2 VARCHAR(250),
       BILLCITY VARCHAR(250),
       BILLSTATE VARCHAR(250),
       BILLZIP VARCHAR(250),
       BILLPHONE VARCHAR(250),
       SHIPNAME VARCHAR(250),
       SHIPADDR1 VARCHAR(250),
       SHIPADDR2 VARCHAR(250),
       SHIPCITY VARCHAR(250),
       SHIPSTATE VARCHAR(250),
       SHIPZIP VARCHAR(250),
       SHIPPHONE VARCHAR(250),
       CREDITCARD VARCHAR(250),
       CCNUM VARCHAR(250),
       CCEXPIREMONTH VARCHAR(250),
       CCEXPIREYEAR VARCHAR(250),
       CARDHOLDER VARCHAR(250),
       SHIPPINGMETHOD INTEGER NOT NULL,
       PROFIT REAL NOT NULL,
       CUSTOMERID VARCHAR(250));
 
   ALTER TABLE ORDER1
       ADD CONSTRAINT PK_ORDER1 PRIMARY KEY (ORDERID);
 
   CREATE TABLE ORDERITEM
    (  INVENTORYID VARCHAR(250) NOT NULL,
       NAME VARCHAR(250),
       PKGINFO VARCHAR(250),
       PRICE REAL NOT NULL,
       COST REAL NOT NULL,
       CATEGORY INTEGER NOT NULL,
       QUANTITY INTEGER NOT NULL,
       SELLDATE VARCHAR(250),
       ORDER_ORDERID VARCHAR(250) NOT NULL);
 
   ALTER TABLE ORDERITEM
       ADD CONSTRAINT PK_ORDERITEM PRIMARY KEY (INVENTORYID, ORDER_ORDERID);
 
   CREATE TABLE IDGENERATOR
    (  IDNAME VARCHAR(250) NOT NULL,
       IDVALUE INTEGER NOT NULL);
 
   ALTER TABLE IDGENERATOR
       ADD CONSTRAINT PK_IDGENERATOR PRIMARY KEY (IDNAME);
 
   CREATE TABLE BACKORDER
    (  BACKORDERID VARCHAR(250) NOT NULL,
       INVENTORYID VARCHAR(250),
       QUANTITY INTEGER NOT NULL,
       STATUS VARCHAR(250),
       LOWDATE BIGINT NOT NULL,
       ORDERDATE BIGINT NOT NULL,
       SUPPLIERORDERID VARCHAR(250) NULL);
 
   ALTER TABLE BACKORDER
       ADD CONSTRAINT PK_BACKORDER PRIMARY KEY (BACKORDERID);
 
   CREATE TABLE SUPPLIER
    (  SUPPLIERID VARCHAR(250) NOT NULL,
       NAME VARCHAR(250),
       STREET VARCHAR(250),
       CITY VARCHAR(250),
       USSTATE VARCHAR(250),
       ZIP VARCHAR(250),
       PHONE VARCHAR(250),
       URL VARCHAR(250));
 
   ALTER TABLE SUPPLIER
       ADD CONSTRAINT PK_SUPPLIER PRIMARY KEY (SUPPLIERID);

Comme on peut le voir, le schéma de la base de données n'est pas ce qui se fait de mieux mais nous permettra d'avoir une bonne vision de l'utilisation de Benerator.

Après la découverte du schéma de la base de données et du fonctionnement Benerator, regardons comment créer le fichier XML de description du projet.

2.2 Paramétrage de la base de données cible et de la volumétrie du jeu de données

Mais avant cela, nous allons créer deux fichiers properties afin de regrouper les informations sur :

la base de données ;
la volumétrie cible.

Les informations sur la base de données seront dans le fichier mysql\PlantsByWebSphere.mysql.properties

bddUrl=jdbc:mysql://localhost:3306/test
bddDriver=com.mysql.jdbc.Driver
bddCatalog=test
bddUser=root
bddPassword=mysql

Les informations sur les volumétries cibles seront dans les fichiers de type PlantsByWebSphere.{volumetrie}.properties

Par exemple pour un poste de développement, le fichier se nommera PlantsByWebSphere.development.properties

taillePaquet=10
customer_count=10
inventory_cat0_count=10
inventory_cat1_count=3
inventory_cat2_count=2
inventory_cat3_count=5
supplier_count=1
order_count=60
items_per_order=3

2.3 Création du fichier de description de Benerator

Commençons par l'entête du fichier.

 version="1.0" encoding="iso-8859-1"?>
 
	xmlns="http://databene.org/benerator/0.7.5"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://databene.org/benerator/0.7.5 http://databene.org/benerator-0.7.5.xsd">
>

Importons les domaines nécessaires et la bonne plate-forme.

 domains   = "person,net,address,finance" />
 platforms = "db,csv"/>

Définissons des valeurs par défaut pour le type de volumétrie et le type de base de données cible.

>Valeur par défaut>
 name="volumetrie" default="development" />
 name="database" default="mysql" />

Chargeons les deux fichiers properties que l'on a créés.

>Récupération des valeurs pour la volumétrie et la base de données cible>
 uri="{ftl:${database}/PlantsByWebSphere.${database}.properties}" />
 uri="{ftl:PlantsByWebSphere.${volumetrie}.properties}" />

Définissons l'URL de la base de données (ne pas oublier d'ajouter les drivers dans le classpath si nécessaire).

 id="db" url="{bddUrl}" driver="{bddDriver}" 
  user="{bddUser}" password="{bddPassword}" catalog="{bddCatalog}" batch="true" fetchSize="1000" />

Afin d'éviter les mauvaises surprises, partons d'une base vide (drop + create) à l'aide de 2 scripts SQL.

>Drop des tables avant leurs créations>
 uri="{ftl:${database}/drop_tables_${database}.sql}"   target="db" onError="ignore" />
 uri="{ftl:${database}/create_tables_${database}.sql}" target="db" />

Créons deux générateurs de nombre auto incrémenté pour les utiliser comme clé primaire.

 id="idGen" spec="new IncrementGenerator(1)" />
 id="idOrderGen" spec="new IncrementGenerator(1)" />

Maintenant, en fonction de ce que l'on veut tester, il nous reste plusieurs choix possibles comme :

simuler des tests avec un catalogue de produits plus grand que celui défini par défaut ;
simuler des tests à l'ouverture de la boutique en ligne ;
simuler des tests après plusieurs jours de fonctionnement (ce qui correspond à avoir déjà des clients et des commandes en base de données) ;
simuler plusieurs combinaisons des cas précédents.

Ces choix impacteront le volume et la répartition des données en base et donc les résultats des tests.

Dans notre cas, nous allons regarder comment créer des données pour chaque table.

Commençons par ajouter des articles en base (table INVENTORY).

Chargeons les images des articles en mémoire afin de pouvoir remplir le champ IMGBYTES.
L'objectif du jeu de données étant une campagne de test de charge, nous ne nous soucierons pas de la correspondance entre l'image et le produit.

 id="pictures_files" class="org.databene.benerator.file.BinaryFileContentGenerator">
     name="uri" value="images" />
     name="filter" value=".*\.jpg" />
>

Afin de contrôler le plus finement possible la répartition des articles, nous les traiterons catégorie par catégorie (champ CATEGORY)

Chaque catégorie sera générée de cette façon (ici pour la catégorie des Flowers).

generate type="INVENTORY" count="{inventory_cat0_count}" consumer="db" pageSize="{taillePaquet}" >
	 name="INVENTORYID" generator="idGen" />
	 name="NAME" values="'Petunia','African Orchid','Baby Breath','Black-eyed Susan','Coleus','Yellow Shasta Daisy','Perennial Foxglove','Geranium','Goodnight Moon Iris','Impatiens','Lily','Pansy','Primrose','Red Poinsettia','Red Rose','Sparkler Celosia','Tulip','White Poinsettia','White Rose','Zinnia'" />
	 name="HEADING" values="'Striped Brightness','Rare Delicate Beauty','Colorful Accent','Charming Simple Beauty','Tangerine Dream','Autumn Mix','Seasonal Beauty','Always in Bloom','Seasonal Simplicity','A Classic Beauty'" />
	 name="DESCRIPTION"  />
	 name="PKGINFO" values="'4 plants'" />
	 name="IMAGE"  values="'flower_petunias.jpg','flower_african_orchid.jpg','flower_bbreath.jpg','flower_black-eyed_susan.jpg','flower_coleus.jpg','flower_daisies.jpg','flower_foxglove.jpg','flower_geranium.jpg','flower_goodnight_moon_iris.jpg','flower_impatiens.jpg','flower_lily.jpg','flower_pansies.jpg','flower_primrose.jpg','flower_red_poinsettia.jpg','flower_red_rose.jpg','flower_sparkler_celosia.jpg','flower_tulips.jpg','flower_white_poinsettia.jpg','flower_white_rose.jpg','flower_zinnia.jpg'" />
	 name="IMGBYTES" generator="pictures_files" />
	 name="PRICE" min="10" max="45" />
	 name="COST" min="1" max="9" />
	 name="CATEGORY" values="0" />	
	 name="QUANTITY" values="10000" />
	 name="NOTES" values="'NOTES and stuff'" />
	 name="ISPUBLIC" values="1" />
	 name="MINTHRESHOLD" values="50" />
	 name="MAXTHRESHOLD" values="200" />
>

En fonction de la catégorie et de l'objectif du test, on pourra modifier les paramètres suivants :

count ;
QUANTITY ;
ISPUBLIC.

Je vous laisse créer les autres articles pour les 3 catégories restantes (CATEGORY aura pour valeurs : 1, 2 et 3).

Créons à l'identique de l'original la table SUPPLIER.

   type="SUPPLIER" count="{supplier_count}" consumer="db" pageSize="{taillePaquet}" >
  	 name="individu" generator="org.databene.domain.person.PersonGenerator" dataset="US" locale="en"/>
  	 name="adresse" generator="org.databene.domain.address.AddressGenerator" dataset="US" locale="en"/>
    	 name="SUPPLIERID" script="individu.email" unique="true" />
  	 name="NAME" script="individu.givenName" />
  	 name="STREET" script="adresse.houseNumber + ' ' + adresse.street" />
  	 name="CITY" script="adresse.city" />
  	 name="USSTATE" script="adresse.state.id" />
  	 name="ZIP" script="adresse.postalCode" />
    	 name="PHONE" script="adresse.mobilePhone" />
    	 name="URL" values="'http://localhost:9080/OrderProcessorEJB/services/FrontGate?wsdl'" />	
  >

Créons des comptes clients (table CUSTOMER).

 type="CUSTOMER" count="{customer_count}" consumer="db" pageSize="{taillePaquet}" >
     name="individu" generator="org.databene.domain.person.PersonGenerator" dataset="US" locale="en"/>
     name="adresse" generator="org.databene.domain.address.AddressGenerator" dataset="US" locale="en"/>
     name="CUSTOMERID" script="individu.email" unique="true" />
     name="PASSWORD" minLength="6" maxLength="10" />
     name="FIRSTNAME" script="individu.givenName" />
     name="LASTNAME" script="individu.familyName" />
     name="ADDR1" script="adresse.houseNumber + ' ' + adresse.street" />
     name="ADDR2" maxLength="20" />
     name="ADDRCITY" script="adresse.city" />
     name="ADDRSTATE" script="adresse.state.id" />
     name="ADDRZIP" script="adresse.postalCode" />
     name="PHONE" script="adresse.privatePhone" />
>

Comme on peut le voir, on utilise les domaines Person et Address afin d'avoir des données réalistes.

Il nous reste à créer des commandes clients (tables ORDER1, ORDERITEM et IDGENERATOR).

Remplissons la table ORDER1.

   type="ORDER1" count="{order_count}" consumer="db" pageSize="{taillePaquet}" >
  	 name="ORDERID" generator="idOrderGen" />
  	 name="SELLDATE" type="date" min="2009-01-01" max="2011-08-01" converter="org.databene.commons.converter.ToStringConverter" />
  	 name="CUSTOMERID" source="db" selector="select CUSTOMERID from CUSTOMER" cyclic="true" />	
    	 name="BILLNAME" source="db" subSelector="{{'select LASTNAME from CUSTOMER where CUSTOMERID = \'' + this.CUSTOMERID + '\''}}" />
    	 name="BILLADDR1" source="db" subSelector="{{'select ADDR1 from CUSTOMER where CUSTOMERID = \'' + this.CUSTOMERID + '\''}}" />
    	 name="BILLADDR2" source="db" subSelector="{{'select ADDR2 from CUSTOMER where CUSTOMERID = \'' + this.CUSTOMERID + '\''}}" />
    	 name="BILLCITY" source="db" subSelector="{{'select ADDRCITY from CUSTOMER where CUSTOMERID = \'' + this.CUSTOMERID + '\''}}" />
    	 name="BILLSTATE" source="db" subSelector="{{'select ADDRSTATE from CUSTOMER where CUSTOMERID = \'' + this.CUSTOMERID + '\''}}" />
    	 name="BILLZIP" source="db" subSelector="{{'select ADDRZIP from CUSTOMER where CUSTOMERID = \'' + this.CUSTOMERID + '\''}}" />
    	 name="BILLPHONE" source="db" subSelector="{{'select PHONE from CUSTOMER where CUSTOMERID = \'' + this.CUSTOMERID + '\''}}" />     
  	 name="SHIPNAME" script="this.BILLNAME" />
  	 name="SHIPADDR1" script="this.BILLADDR1" />
  	 name="SHIPADDR2" script="this.BILLADDR2" />
  	 name="SHIPCITY" script="this.BILLCITY" />
  	 name="SHIPSTATE" script="this.BILLSTATE" />
  	 name="SHIPZIP" script="this.BILLZIP" />
  	 name="SHIPPHONE" script="this.BILLPHONE" />	
  	 name="CREDITCARD" pattern="(Visa|Master Card|American Express)" />
  	 name="CCNUM" generator="org.databene.domain.finance.CreditCardNumberGenerator" />
  	 name="CCEXPIREMONTH" type="int" min="01" max="12" converter="org.databene.commons.converter.ToStringConverter" />
  	 name="CCEXPIREYEAR" type="int" min="2013" max="2016" converter="org.databene.commons.converter.ToStringConverter" />
  	 name="SHIPPINGMETHOD" min="0" max="2" />
  	 name="CARDHOLDER" script="this.BILLNAME" />
  	 name="PROFIT" type="double" values="1.0" />
  >

Nous utilisons ici les commandes this et subSelector nous permettant d'être cohérent sur les données de l'acheteur par rapport à la table CUSTOMER.

Puis la table ORDERITEM.

   type="dummy" count="{order_count}" pageSize="{taillePaquet}" >
     name="x" source="db" selector="select ORDERID from ORDER1" distribution="increment" unique="true" />
     type="ORDERITEM" count="{items_per_order}" consumer="db">
       name="y" source="db" selector="select INVENTORYID from INVENTORY" distribution="random" unique="true" />
       name="INVENTORYID" script="y"/>
       name="ORDER_ORDERID" script="x"/>
       name="NAME" source="db" subSelector="{{'select NAME from INVENTORY where INVENTORYID = \'' + this.INVENTORYID + '\''}}" />
       name="PKGINFO" source="db" subSelector="{{'select PKGINFO from INVENTORY where INVENTORYID = \'' + this.INVENTORYID + '\''}}" />
       name="PRICE" source="db" subSelector="{{'select PRICE from INVENTORY where INVENTORYID = \'' + this.INVENTORYID + '\''}}" />
       name="COST" source="db" subSelector="{{'select COST from INVENTORY where INVENTORYID = \'' + this.INVENTORYID + '\''}}" />
       name="CATEGORY" source="db" subSelector="{{'select CATEGORY from INVENTORY where INVENTORYID = \'' + this.INVENTORYID + '\''}}" />
       name="QUANTITY" min="1" max="20" />
       name="SELLDATE" source="db" subSelector="{{'select SELLDATE from ORDER1 where ORDERID = \'' + this.ORDER_ORDERID + '\''}}" />
    >
  >

Ici on doit utiliser deux boucles imbriquées afin de garantir l'unicité de la clé primaire composée de deux champs (INVENTORYID,ORDERITEM).

Mettons à jour le prix de chaque commande (champ PROFIT de la table ORDER1).

   type="ORDER1" source="db" consumer="db.updater()"> 
       name="PROFIT" source="db"
          selector="{{ftl:select IFNULL(SUM((PRICE - COST)*QUANTITY), 0) from ORDERITEM where ORDER_ORDERID = '${ORDER1.ORDERID}' }}" cyclic="true"/>
  >

On utilise la fonction SQL IFNULL de MySQL afin d'être sûr de mettre une valeur non null dans le champ PROFIT.

Une autre solution est d'utiliser un subSelector à la place de la combinaison de selector et cyclic="true".

 type="ORDER1" source="db" consumer="db.updater()">
   name="PROFIT" source="db" subSelector="{{ftl:select IFNULL(SUM((PRICE - COST)*QUANTITY), 0) from test.ORDERITEM where ORDER_ORDERID = '${ORDER1.ORDERID}' }}" />
>

Pour la dernière table IDGENERATOR, on va utiliser les capacités de Benerator a importer des fichiers CSV.

Importons le fichier CSV idgenerator.import.csv.

 type="IDGENERATOR" source="idgenerator.import.csv" encoding="utf-8" consumer="db" />

Puis mettons à jour la valeur du champ IDVALUE.

   type="IDGENERATOR" source="db" consumer="db.updater()"> 
       name="IDVALUE" source="db" 
        selector="{{ftl:select 1+${order_count}*50 from IDGENERATOR where IDNAME = 'ORDER' }}" cyclic="true"/>  
  >

Une autre solution est de tout faire lors de l'importation du fichier csv à l'aide du mot clé condition.

   type="IDGENERATOR"  name="idg" source="idgenerator.import.csv" encoding="utf-8" consumer="db" >
     name="IDVALUE" condition="idg.IDNAME == 'ORDER'" script="1+order_count*50"/>     
  >

Il ne reste plus qu'à exécuter Benerator pour générer notre jeu de données.

Notre fichier XML de description est prêt et je vous laisse le paramétrer au mieux pour l'objectif de vos tests.

Ma conclusion sur cet outil est toujours la même :

il est pratique ;
pilotable en ligne de commande et donc très flexible pour son intégration dans un processus ;
larges possibilitées :

générer un jeu de données à partir de rien ;
anonymiser un jeu de données ;
traitement de données existantes comme pour un ETL ;
création de fichier d'entrée pour un test de charge (création de login/password, ...) ;

possibilité d'utiliser le même fichier XML de configuration de Benerator pour divers environnements (test, développement, pré production...) à l'aide de fichiers properties;
documentation complète ;
développement actif ;
gratuit ;
open source ;
support par le développeur ;
extensible.

Pourquoi il est dangereux d’utiliser System.gc()

Antonio Gomes-Rodrigues — Tue, 07 Feb 2012 07:30:33 +0000

En java, la gestion de la mémoire est réalisée par la JVM, en particulier par le Garbage Collector (ramasse miettes). Or, si l'on regarde d'un peu plus près, on remarque que l'on peut appeler le GC par l'instruction System.gc().
On se dit que cela pourrait être utile afin de libérer un maximum de mémoire avant certains traitements. Cette démarche est fortement déconseillé car c'est une "fausse bonne idée" comme nous allons le démontrer par la suite.

1. Un Peu de théorie

Regardons la Javadoc.

    /**
     * Runs the garbage collector.
     * <p>
     * Calling the <code>gc</code> method suggests that the Java Virtual
     * Machine expend effort toward recycling unused objects in order to
     * make the memory they currently occupy available for quick reuse.
     * When control returns from the method call, the Java Virtual
     * Machine has made a best effort to reclaim space from all discarded
     * objects.
     * <p>
     * The call <code>System.gc()</code> is effectively equivalent to the
     * call:
     * Runtime.getRuntime().gc()
     *
     * @see     java.lang.Runtime#gc()
     */

Première mauvaise nouvelle, System.gc() ne réalise pas forcement un GC (il peut ne rien faire) et surtout on se sait pas quand.

On a des chances de se retrouver dans ce cas.

Supposons que la JVM réagisse comme on le souhaite (le GC est bien exécuté), le GC ne s'exécutera pas forcement au meilleur moment par rapport à l'état de la JVM. Le tout en gardant le coût d'un GC (qui en fonction d'un certain nombre de paramètres peut aller jusqu'à plusieurs secondes).

2. Passons à la pratique

Afin de tester notre hypothèse (ne pas utiliser de System.gc()) modifions l'application Spring Pet Clinic en lui ajoutant un appel au GC.
Créons un scénario JMeter afin de simuler de l'activité.

2.1 Exécutons notre scénario avec un seul utilisateur.

On remarque que l'activité GC est énorme (plus de 10%) pour la charge.

La Heap est stable (bien trop stable par rapport au test exécuté).

En regardant d'un peu plus près l'activité du GC dans la partie de la mémoire appelée Old Generation, on remarque qu'il y a beaucoup trop d'activité.

De même, les temps de réponse ne sont pas extraordinaires.

A ce stade on peut faire un focus sur l'activité du GC ne semble pas normale.

2.2 Augmentons la charge en simulant 100 utilisateurs.

Le taux d'activité GC passe de 10% à 40%.

De même le nombre de GC dans la Old Generation augmente fortement.

Les temps de réponse se dégradent fortement.

Sans parler de leurs stabilités qui nous confortent dans l'idée qu'il y a un gros problème.

En plus de montrer l'utilité d'un test de charge, toute illusion de passer l'application en production s'évapore.

2.3 Trouvons la source du problème

Afin de détecter si System.gc() est appelé, nous allons instrumenter le bytecode (pratique si l’on n'a pas le code source) de l'application afin qu'il nous l'indique avec le message « System.gc() est appelé » lors de chaque appel.

Bingo, on obtient rapidement la confirmation.

System.gc() est appelé
System.gc() est appelé
System.gc() est appelé
System.gc() est appelé
System.gc() est appelé
System.gc() est appelé
System.gc() est appelé
System.gc() est appelé
System.gc() est appelé
System.gc() est appelé
System.gc() est appelé

Modifions un peu notre script d'instrumentation afin d'avoir la stacktrace lors d'un appel de System.gc().
On obtient.

System.gc() est appelé
StackTrace :
--------------------------------
java.lang.System.gc(System.java)
org.springframework.samples.petclinic.web.FindOwnersForm.processSubmit(FindOwnersForm.java:50)
sun.reflect.GeneratedMethodAccessor82.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.springframework.web.bind.annotation.support.HandlerMethodInvoker.doInvokeMethod(HandlerMethodInvoker.java:710)
org.springframework.web.bind.annotation.support.HandlerMethodInvoker.invokeHandlerMethod(HandlerMethodInvoker.java:167)
org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.invokeHandlerMethod(AnnotationMethodHandlerAdapter.java:414)
org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.handle(AnnotationMethodHandlerAdapter.java:402)
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:771)
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:716)
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:647)
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:552)
javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:71)
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164)
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:399)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:317)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:204)
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:311)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
java.lang.Thread.run(Thread.java:662)

La source du problème est détectée dans la fonction : org.springframework.samples.petclinic.web.FindOwnersForm.processSubmit(FindOwnersForm.java:50)

Il ne reste plus qu'à corriger le problème. Pour cela plusieurs solutions sont possibles :

Modifier directement la fonction org.springframework.samples.petclinic.web.FindOwnersForm.processSubmit
Utiliser Findbugs pour détecter les appels à System.gc()
Utiliser l'option -XX:DisableExplicitGC de la JVM

Dans notre cas, nous allons directement corriger le code source car nous savons exactement où se trouve le problème.

2.4 Relançons nos tests de charge avec 100 utilisateurs

Nous pouvons constater la différence et confirmer notre hypothèse.

Le temps de réponse de la transaction fautive est même divisé par dix.

3. Mon conseil

Mon conseil est de ne pas utiliser de System.gc().

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

Antonio Gomes-Rodrigues — Wed, 25 Jan 2012 07:30:41 +0000

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.

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

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.

Analyse système et réseau : généralités – Part 2

Stéphane Chabrier — Thu, 19 Jan 2012 09:00:09 +0000

Après avoir vu comment superviser la partie processeur et mémoire, attardons nous maintenant sur les accès disques et les connexions réseaux.

Monitoring Disk and Network

Cette commande fournit des informations à propos de l'ensemble des périphériques d'entrée et sortie : les disques, le ou les terminaux, les autres périphériques séries.

1. La commande Iostat (ou sar -d)

La syntaxe de base est la suivante :

iostat interval count

exemple : iostat -xtc 5 2
avg-cpu:  %user   %nice    %sys %iowait   %idle
           0.01    0.00    0.01    0.04   99.93
                      extended device statistics                    tty         cpu
device    r/s    w/s   kr/s   kw/s wait actv  svc_t  %w  %b  tin tout  us sy wt id
cmdk0     1.0    2.3   10.9   19.4  0.0  0.0    5.4   0   1    0   59  13  3  0 84
fd0       0.0    0.0    0.0    0.0  0.0  0.0  986.3   0   0
sd0       0.0    0.0    0.0    0.0  0.0  0.0    0.0   0   0
sd1       0.0    0.0    0.0    0.0  0.0  0.0    0.0   0   0 

		     extended device statistics                    tty         cpu
device    r/s    w/s   kr/s   kw/s wait actv  svc_t  %w  %b  tin tout  us sy wt id
cmdk0     0.0    9.3    0.0   35.3  0.0  0.0    3.5   0   3    0    0   7  2  0 90
fd0       0.0    0.0    0.0    0.0  0.0  0.0    0.0   0   0
sd0       0.0    0.0    0.0    0.0  0.0  0.0    0.0   0   0
sd1       0.0    0.0    0.0    0.0  0.0  0.0    0.0   0   0

wait : le nombre moyen de transactions en attente d'être traitées
actv : le nombre moyen de transactions en cours de traitement (elles ne sont plus dans la queue mais ne sont pas pour autant terminées)
svc _t : le temps moyen de traitement
%w : le pourcentage du temps durant lequel des transactions sont en attente d'un traitement
%b : pourcentage du temps durant lequel le disque est occupé

Les colonnes r/s, w/s, kr/s, et kw/s montrent respectivement les read et write par secondes en octets et kilo-octets.

Le temps de traitement et le temps d'occupation donnent une bonne impression sur l'état des entrées / sorties d'un disque. Un taux d'occupation de plus de deux-tiers (%b) et un temps de traitement de plus de 50 millisecondes (svc_t) sont les indicateurs d'un goulot d'étranglement.

Conseils et optimisations :

répartir la charge sur plusieurs disques en utilisant un meilleur partitionnement, et en distribuant le swap (pagination) sur plusieurs disques.
augmenter la RAM pour diminuer la pagination; c'est le cas par exemple lors de l'utilisation de SGBD qui sont très gourmands en ressource mémoire, mais peu demandeurs de capacités de traitement rapides par le processeur.
utiliser autant que faire se peut les ressources en cache des applications développées. Les architectures techniques intègrent de plus en plus de serveurs de cache qui ne sollicitent que la mémoire et une faible charge de CPU. Optimiser les requêtes SQL pour optimiser les coûts de ressource CPU.
si le disque est utilisé à 100%, on peut répartir le système de fichier sur plusieurs disques en utilisant un SAN ou plusieurs NAS;

2. La commande Netstat

C'est l'incontournable des indicateurs réseaux. En règle générale, on retrouve au moins trois ou quatre options communes aux différents OS.

-a montre l'état de tous les sockets
-r montre les tables de routage du système

$ netstat -i

Name  Mtu Net/Dest  Address    Ipkts  Ierrs  Opkts  Oerrs  Collis Queue
lo0  8232 loopback localhost   77814  0      77814    0         0   0
hme0 1500 server1  server1  10658566  3    4832511    0    279257   0

Les valeurs importantes à noter sont :

collisions (Collis)
les paquets envoyés (Opkts)
les paquets reçus (Ipkts)
les paquets erronés (Ierrs)

Conseils et optimisations :

(Collis+Ierrs+Oerrs)/(Ipkts+Opkts) > 2% peut indiquer un problème physique dans le réseau;
(Collis/Opkts) > 10% indique que l'interface réseau est surchargée et qu'il faut redistribuer les charges;
(Ierrs/Ipkts) > 25% montre un gros nombre de paquets abandonnés en raison d'un réseau surchargé;
s'il y a plus de 120 collisions par secondes, le réseau est surchargé;
si la somme des paquets entrants et des paquets sortants est supérieure à 600 pour une interface de 10-Mbs et à 6000 pour une interface de 100-Mbs, le segment est trop chargé et une redistribution du réseau s'impose;
un nombre important d'erreurs dans les colonnes "Ierrs" et "Oerrs" indique un problème de transmission et/ou de réception. Il se peut que la source et la destination aient des réglages différents comme full-duplex d'un côté et half-duplex de l'autre.

#netstat -nar -p tcp

Local Address Remote Address Swind    Send-Q Rwind  Recv-Q State
*.*           *.*            0        0      24576  0     IDLE
*.22          *.*            0        0      24576  0     LISTEN
*.32775       *.*            0        0      24576  0     LISTEN
*.32776       *.*            0        0      24576  0     LISTEN
*.*           *.*            0        0      24576  0     IDLE
192.168.1.184.22 192.168.1.186.56806 38912 0 24616  0     ESTABLISHED
192.168.1.184.22 192.168.1.183.58672 18048 0 24616  0     ESTABLISHED

Les valeurs importantes à noter sont :

CLOSED : fermé le socket n'est pas utilisé
LISTEN : à l'écoute de connexions entrantes
SYN_SENT : essai d'établir une connexion
SYN_RECEIVED : synchronisation initiale de la connexion en cours
ESTABLISHED : connexion établie
CLOSE_WAIT : fermeture à distance (côté serveur par exemple); en attente de fermeture du socket
FIN_WAIT_1 : socket fermé terminaison de la connexion
CLOSING : fermé, puis fermeture à distance; attente d'accusé de réception
LAST_ACK : terminaison à distance puis fermeture; attente d'accusé de réception
FIN_WAIT_2 : socket fermée; en attente de terminaison de la part du pair distant
TIME_WAIT : en attente après fermeture pour la retransmission de la terminaison distante

Conseils et optimisations :

Trop de connexions avec un état FIN_WAIT signifie généralement qu'il faut modifier le paramétrage TCP/IP car les connexions ne sont pas terminées (en tout cas terminées proprement d'après les séquences prévues) et des connexions inactives s'accumulent.

Cela peut conduire à un épuisement des ressources système. Le mieux est de contrôler le TCP "timeout" qui ferme au bout d'un certain nombre de secondes une connexion inutilisée.

Le pool peut ainsi être utilisé par de nouvelles connexions.

Pourquoi désactiver les plugins du navigateur Web lors de l’enregistrement d’un scénario ?

Antonio Gomes-Rodrigues — Wed, 18 Jan 2012 08:00:06 +0000

Dans la majorité des outils de test de charge (HP LoadRunner, Apache JMeter, Microfocus SilkPerformer...) l'enregistrement des scripts est réalisé à l'aide d'un proxy. Toutes les requêtes qui passent par ce proxy sont enregistrées et l'on peut donc se retrouver avec des requêtes qui n'ont rien à faire dans notre script, en particulier si certains plugins sont installés dans le navigateur Web utilisé pour notre enregistrement.

Ces requêtes inutiles vont faire appel à des environnements externes à celui qu'on teste et vont poser un certain nombre de problèmes comme :

avoir des temps de réponse faussés, dû à l'attente d’acquittement des sites externes ;
se faire black-lister par l'environnement externe ;

Par exemple dans ce script JMeter il y a un appel à toolbarqueries.clients.google.com qui a été enregistré.

On lance un test sans rien changer pour obtenir ces temps de réponse catastrophiques.

Supprimons maintenant cette requête, le but du test n'étant pas de faire un test de charge sur toolbarqueries.clients.google.com

Rejouons le test et regardons ce que l'on obtient.

Voila qui est beaucoup mieux (il y a un gain de performance assez conséquent car cette requête posait d'autre problèmes dans l'environnement de test).

Un autre exemple avec Mozilla Firefox qui cherche des mise à jour pour un flux RSS.

Conseil « après l'enregistrement d'un script, penser à bien vérifier les appels d'Urls externes ».

Optimiser Tomcat : les bests practices – Part 2

Stéphane Chabrier — Sun, 15 Jan 2012 11:37:43 +0000

Après avoir abordé les problématiques liées à la gestion de la Heap et des threads, voici une liste des paramètres principaux restants à aborder. (liste non-exhaustive évidemment !)

Le Tuning HTTP et TCP

Avant de s’attaquer à ces améliorations, il est important de comprendre et d'agir en fonction des connectors utilisés par votre serveur :

Blocking IO Connector

La majorité du contenu est dynamique
Keep-Alive n’est pas important
La fiabilité est une priorité

Apache Portable Runtime/APR Connector

La majorité du contenu est dynamique
Keep-Alive n’est pas important
La fiabilité est une priorité

NIO Connector

Connecteur non bloquant comme l’APR connector
A la différence de l’APR connector qui nécessite la librairie native APR, le NIO connecteur est portable sur toutes les plateformes
Le NIO connector ne bénéficie par de l’optimisation SSL apportée par Open SSL

AJP Connector

Déconseillé, il n’est pas plus performant que les connecteurs HTTP et est en revanche difficile à diagnostiquer en cas d'anomalies.

Les principaux paramètres de connecteurs à configurer :

maxKeepAliveRequests : représente le nombre de requêtes HTTP que peut gérer une connexion TCP. Généralement entre 100 et 200 (SSL, APR / NIO connector) ou 1 pour désactiver « Keep Alive » (pas de SSL, BIO connector, très forte concurrence).
acceptCount (stack de threads - backlog TCP) : typiquement entre 50 et 300.
connectionTimeout : le temps maximum entre deux paquets TCP, suite à une demande de requête HTTP : entre 2000 à 3000 ms est souvent optimal, même en activant Keep Alive (valeur par défaut de 60000)

1.Gestion des pool de connexion DB

Trois paramètres parmis une liste plus complète, permettent d'influencer la gestion du nombre de connexions dans le pool :

maxActive : le nombre maximum de connexions qui peuvent être allouées depuis le pool. Sa valeur par défaut est 8, une valeur de 0 indique "sans limite". En règle générale, une valeur de 30 maxActive devrait permettre de supporter une charge conséquente sur une application Web grand public, sous réserve de requêtes optimisées). Il faut également vérifier que la base de données autorisera de son côté ce nombre de connexions.
maxIdle : le nombre maximum de connexions inactives qui peuvent être dans le pool. Sa valeur par défaut est de 8, une valeur de 0 indique "sans limite"
maxWait : le temps d'attente maximum en millisecondes pour l'obtention d'une connexion. Passé ce délai, une exception est levée. Sa valeur par défaut est -1 qui correspond à un temps infini

L'utilisation de JDBC pouvant vite devenir complexe, il arrive que l'on oublie de fermer une connexion. Cette connexion ne revient donc pas dans le pool, on parle alors de "fuite du pool de connexion" (pool leaking). Ce phénomène peut aboutir à un blocage de l'application web par manque de connexions disponibles.

On peut configurer Tomcat pour qu'il récupère ces connexions et laisse une stack du code qui a ouvert la connexion et ne l'a jamais fermée. Par défaut cette fonction n'est pas activée. Si vous l'activez, Tomcat effectue cette recherche quand le nombre de connexions inactives (disponible dans le pool) est inférieur à 2. Les paramètres sont :

removeAbandoned : par défaut à false, c'est lui qui permet l'activation de cette fonction. Si on le met à true, une connexion est considérée comme abandonnée et éligible à la récupération si elle est inactive depuis plus longtemps que le removeAbandonedTimeout.
removeAbandonedTimeout : C'est le temps en secondes (par défaut 300), avant qu'une connexion inactive soit considérée comme abandonnée.
logAbandoned : par défaut à false. Si positionné à true, Tomcat ajoute une trace de la pile de l'application qui a abandonné la connexion.

En règle générale, un pool de connexion doit rester optimisé : un nombre de connexions limités, avec une performance de la base de données (et des requêtes SQL) permettant l'utilisation très rapide de ces connexions. Vous le comprendrez, rien ne sert de chercher à optimiser un pool de connexion pour des requêtes SQL qui mettront plusieurs secondes alors qu'elles devraient s'exécuter en quelques millisecondes ....

2.La compression et la gestion des caches

Objectif : optimiser la gestion des contenus statiques

Les connecteurs APR et NIO offrent l’optimisation SEND_FILE, utilisant des background threads.
Tomcat offre un cache du contenu statique. Cependant, cette fonctionnalité ne rivalise pas avec un proxy cache comme Squid ou mod_cache )
exemple :
```
<Context cacheMaxSize="40250"
             cacheTTL="40000" cacheAllowed="true"/>
```

La compression des flux http se fait avec les options suivantes (/conf/server.xml)

<Connector port="8080" maxHttpHeaderSize="8192" 
maxThreads="150" minSpareThreads="25" maxSpareThreads="75" 
acceptCount="100" disableUploadTimeout="true"
compression="on" compressionMinSize="2048" 
noCompressionUserAgents="gozilla, traviata" 
compressableMimeType="text/html,text/xml"/>

3.La gestion des écritures de logs

Par défaut, toutes les logs sont traçées dans le sdtout et les fichiers de logs sans réel gestion de l'overflow. De plus, les contraintes d'I/O disk se répercutent directement sur la performance du système, et donc de l'application.

Bien penser à supprimer les écritures dupliquées (souvent le cas quand on crée des fichiers de logs fonctionnels, techniques, etc... )

Pour éviter l'overflow, mettre en place le système de logs circulaires via une classe "maison" implémentant FileHandler (max 5 fichiers de 20 à 50Mo).

exemple dans logging.properties :

1catalina.java.util.logging.FileHandler.pattern = 
     ${catalina.base}/logs/catalina.%g.log 
1catalina.java.util.logging.FileHandler.limit = 20000000
1catalina.java.util.logging.FileHandler.count = 5

Enfin pour optimiser les écritures et donc les accès I/O, privilégier les écritures en mode asynchrone grâce à l'implémentation maison de classe de gestion de log. Cela permettra ainsi d'éviter des OutOfMemoryError à cause d'overflow d'enregistrements de logs :
```
handlers = 1catalina.my.custom.AsyncFileHandler
```

Pourquoi tester les résultats de chaque requête dans un script de test de charge ?

Antonio Gomes-Rodrigues — Wed, 11 Jan 2012 08:00:13 +0000

Il peut être tentant dans un script de test de charge de ne pas tester le résultat de chaque requête. Mais en faisant cela, on s'expose à de graves problèmes pouvant fausser les résultats.

Car si le résultat de la requête n'est pas testé, on ne sait pas si elle s'exécute avec succès et donc le résultat final du tir de charge proposera des moyennes de valeurs complètement faussées.

Cela revient à additionner des patates avec des carottes et comme nous l'ont appris nos professeurs, cela n'a aucun sens.

Voici un exemple de script JMeter qui simule des visiteurs sur l'application PlantsByWebSphere livré avec WebSphere. (détaillé dans notre article précédent)

La transaction Selection_item est défectueuse et à la place d'afficher l'item choisi, elle ré-affiche la liste d'item (la source du problème est une variable mal corrélée).

Exécutons le script.

Comme on peut le voir, aucune erreur n'est détectée. Ce qui est normal car le serveur envoie une réponse valide (HTTP 200) malgré le fait que le résultat attendu ne soit pas le bon. Donc on se retrouve avec des résultats qui ne veulent rien dire.

Maintenant ajoutons un test au résultat de la requête.

Rejouons le script.

On voit bien que toutes les transactions Selection_item échouent.

Corrigeons le problème et rejouons le test.

Comme on peut le voir, il n'y a plus d'erreur, et les résultats deviennent pertinents.

Mon conseil est « de bien tester les retours des transactions afin de ne pas avoir de mauvaise surprise ».

Nouveaux locaux

Éric Phélippeau — Fri, 06 Jan 2012 14:04:56 +0000

Pour faire face à sa croissance et en vue de ses prévisions de recrutements en 2012 Aliecom a emménagé le 6 janvier 2012 dans de nouveaux locaux plus spacieux à Paris :

ALIECOM
75 B rue des Plantes
75014 PARIS

Nos coordonnées téléphoniques et fax restent inchangées :

Tél. : +33 (0)1 45 22 72 55
Fax : +33 (0)1 78 41 67 53