Les objectifs:

1. Monter un environnement opérationnel en moins de 2 minutes
2. Tour d’horizon de Cloudera en 1 minute
3. Tester quelques commandes HDFS en 1 minute
4. Tester un Map Reduce en 1 minute

Monter un environnement opérationnel en 2 minutes

30 secondes pour parler de Cloudera

Apache distribue une version packagée de l’écosystème complet Hadoop. Cette version s’appelle Cloudera: Cloudera’s Distribution for Apache Hadoop (CDH).
Elle est basée sur les dernières versions stables de Hadoop, contient également des patchs additionels. La bonne nouvelle est que Cloudera fournie même une VM, il n’y a donc rien à installer…

Voici son contenu:

• HDFS – Le système de fichier distribué de Hadoop
• MapReduce – Le framework de parallelisation des traitements
• Hadoop Common – Un ensemble d’utilitaire qui supportent les sous projets de Hadoop
• HBase – La base de donnée NoSQL de Hadoop
• Hive – Une surcouche au MapReduce offrant un pseudo language SQL pour interagir avec le HDFS
• Pig – Un language d’analyse des données
• Oozie – Un système de workflow pour gérer les jobs interdépendant
• Sqoop – Framework d’intégration des bases de données avec Hadoop
• Flume – Un système de streaming très efficaces
• Zookeeper – Un système de coordination des configigurations et des services en environnement distribué
• Hue – Une interface utilisateur pour gérer les application Hadoop

1 minute 30 pour l’installation

Télécharger  de la VM ici: http://cloudera-vm.s3.amazonaws.com/cloudera-training-0.3.3.tar.bz2?downloads
Detarrer le tout et lancer la VM avec le player VMWare (accessible ici si vous ne l’avez pas encore: http://downloads.vmware.com/d/info/desktop_downloads/vmware_player/3_0)
Attention: VMWare Fusion est payant sous Mac.

On démarre la VM et hop c’est magique nous avons un Ubuntu avec tout l’écosystème Hadoop prêt à l’emploi.

Tour d’horizon de Cloudera en 1 minute

Lorsque l’on démarre la VM, on peut voir le kit de base pour commencer avec Hadoop:

• un navigateur

• un Eclipse

• un terminal

• un répertoire contenant des instructions

Navigateur

Commençons par ouvrir le navigateur. On peut voir l’interface d’administration web de Hadoop. Cette interface va nous permettre:

- de surveiller les jobs (en cours, terminés, échoué, ..)

- de naviguer dans le système de fichier HDFS

Eclipse

En ouvrant Eclipse, on peut voir qu’un workspace est déja chargé avec un ensemble de projets exemples.

Instructions

Enfin nous pouvons ouvrir le répertoire qui se trouve sur le bureau. On voit que ce répertoire contient un ensemble de tutoriaux et d’exercices pour appréhender le framework.

Tester quelques commandes HDFS en 1 minute

Il est temps de manipuler un peu le système de fichier HDFS. Pour cela, ouvrons un terminal. Commençons par taper  hadoop pour voir l’ensemble des commandes disponibles.

Nous allons utiliser la commande fs qui permet de manipuler le file système: hadoop fs -<commande>

Nous allons pousser un fichier dans le HDFS avec la commande: hadood fs -put README /README

Vérifions maintenant que le fichier est bien présent avec la commande: hadoop fs -ls /

Lisons le contenu du fichier : hadoop fs -tail /README

-> les commandes fs reprennent la syntaxe des commandes shell et pour avoir un détail sur ces commandes, je vous invite à lire la très bonne page man ou d’aller sur la page http://hadoop.apache.org/common/docs/r0.19.2/hdfs_shell.html

Tester un Map Reduce en 1 minute

Passons maintenant au Map Reduce. Pour ça direction Eclipse pour voir si nous trouvons un exemple de MapReduce à tester. Nous pouvons voir que Cloudera nous fourni un ensemble très complet d’exemples. Nous allons donc pouvoir exporter un jar pour le tester directement dans un terminal sur le fichier que nous avons poussé.

Petite note sous Eclipse. Il existe un bug lié à la librairie d’affichage d’Eclipse que les utilisateurs Ubuntu connaissent bien. La parade ? Il suffit de se créer un petit script de lancement:

export GDK_NATIVE_WINDOWS=true

./eclipse

Parmi les exemples exportons le fameux exemple WordCount sous forme de jar executable et lançons le en lui donnant en paramètre un fichier en entrée et une destination en sortie:

Avec la commande hadoop fs -put toto.txt /input/toto, poussons un fichier exemple toto.txt contenant:

a b a

a b b

b c c c

Lançons ensuite notre job:

java -jar sample.jar /user/training/input/toto /output

Et nous obtenons le résultat suivant:

a 3

b 3

c 3

Conclusion

Dans ce post nous sommes passé un peu à la pratique. Nous avons pu faire ça très rapidement grâce à la distribution Cloudera qui permet de démarrer très vite. Pour aller plus loin, je vous conseille de lire les tutoriaux proposés et de regarder les exemples proposés. Dans un prochain post, nous verrons en détail implémentation d’un Map Reduce.

Objectifs

• Comprendre les grands concepts de Hadoop
• Comprendre le HDFS et le mécanisme de Map/Reduce

2 minutes 30 pour comprendre les grands concepts

Hadoop est un projet Open Source écrit en java, distribué par la fondation Apache. Ce framework est adapté dans le stockage et le traitement par lots de très grandes quantités de données (à partir du pétaoctet). Il a été mis en avant par des grands noms du web comme Yahoo! ou Facebook.
Son système de fichiers HDFS permet  de distribuer le stockage des données et de faire des analyses très performantes sur ces données grâce au modèle MapReduce permettant de distribuer une opération sur plusieurs nœuds dans le but de paralléliser leur exécution.

Le HDFS

Le HDFS est le système de fichiers utilisé par Hadoop. C’est un système de fichiers distribués où les blocs d’informations sont répartis et répliqués sur les différents nœuds du cluster. Cette réplication est configurable.
Pour plus d’informations sur l’architecture et la configuration du HDFS vous pouvez consultez la très bonne documentation de Hadoop: http://hadoop.apache.org/hdfs/

Il est important de savoir qu’un ensemble de commandes est mis à disposition pour interagir avec ce système.

Il suffit d’invoquer la commande: hadoop fs  -<commande>. La syntaxe est très proche du shell et l’on retrouve les commandes standards( ls, cp, mv, rm, cat, tail ..)

Voici quelques exemples de commandes utiles:

• Upload un fichier dans le file système: hadoop fs -put logs/ hdfs://localhost:8022/input
• Download un fichier à partir du file système: hadoop fs -get hdfs://localhost:8022/input logs/
• Parcourir le HDFS: hadoop fs -ls hdfs://localhost:8022/input

L’ensemble des commandes est documenté ici: http://hadoop.apache.org/common/docs/r0.18.3/hdfs_shell.html

Le Map Reduce

Ce fonctionnement consiste en deux étapes de traitement, chacune parallélisable sur un ensemble de nœuds : le Mapping et le Reducing.

Le Mapping est une fonction parallélisable dispatchée sur l’ensemble des noeuds d’un cluster. Elle s’applique à une liste fournie en entrée (input list fournie par le HDFS) et dont le résultat est mis à disposition dans une nouvelle liste (output list) stockée sur le HDFS.

Le Reducing est une fonction également dispatchable sur un ensemble de nœuds. Elle consiste à agréger les résulats sous forme clés/valeurs de la liste mise à disposition par la fonction de Mapping (output list).

2 minutes 30 pour comprendre un cas pratique

Prenons un exemple pour illustrer ce mécanisme. Celui qui revient le plus souvent dans la littérature est le use case Word Count consistant à comptabiliser le nombre de mots contenus dans un fichier stocké dans le HDFS.

Etudions en détail les différentes étapes.

1- Stockage du fichier dans le HDFS:

Nous décidons d’envoyer un livre monLivre.txt dans le HDFS à l’emplacement input/books

Voici la commande: hadoop fs -put monLivre.txt hdfs://localhost:8022/input/books

>On peut voir sur le schéma que le fichier est découpé en blocs contenant chacun une partie du fichier et réparti sur un ensemble de nœuds du cluster HDFS en fonction de la configuration. 

2- Comptage des mots en Map Reduce:

L’opération de comptage des mots serait très longue si notre traitement se faisait directement sur le livre. L’interêt du Map Reduce est de paralleliser les traitement sur l’ensemble des noeuds du HDFS.

Dans le schéma ci-dessous, on peut voir les différentes étapes:

1 le fichier est découpé en différents blocs répartir sur les différents noeuds comme nous l’avons vu précédemment

2 le mapping consiste à envoyer le traitement de comptage sur chacun de ces blocs et d’effectuer le processing

3 le shuffling consiste à trier ces informations

4 le reducing est l’opération qui consiste à agréger les informations récupérée

Conclusion

Ce post a permis de vous donner un aperçu rapide du système de fichier distribué HDFS  et du mécanisme de MapReduce.

Pour aller plus loin, je vous invite à jeter un oeil sur la documentation officielle de Hadoop:

HDFS: http://hadoop.apache.org/hdfs/docs/r0.21.0/

MapReduce: http://hadoop.apache.org/mapreduce/docs/r0.21.0/

Maintenant que vous maîtriser les concepts et s’il vous reste 5 minutes, rendez-vous ici pour pour voir comment monter monter un environnement en moins de 5 minutes: http://www.opensides.fr/2011/03/14/installer-hadoop-en-moins-de-5-minutes

Quelques rappels

Un serveur http a pour vocation de servir du contenu en fonction des requêtes clientes. Ce contenu est distribué via le protocole http et peut être statique (images, css, javascript, …) ou dynamique (php, java, .net, …).

Le plus connu de ces serveurs, est Apache. C’est un serveur web dit synchrone, il va affecter un processus fils à chaque requête. Il est stable, efficace, facile à installer et son initiale va bien entre le L et le M de la stack LAMP.

Limitations des serveurs web traditionnels

Le mécanisme d’attribution de processus à chaque requête se révèle très consommateur de RAM et confie le multiplexage temporel des tâches au système d’exploitation ce qui n’est pas toujours optimisé pour traiter le changement d’état des requêtes.

Une nouvelle génération de serveurs

Pour ces raisons une nouvelle génération de serveurs a vu le jour depuis quelques années, les serveurs web asynchrones. On peut en citer quelques uns Mina, Lighthttp,  Nginx. Ce dernier est selon moi le plus performant et le plus aboutit.  Son mécanisme consiste à diviser chaque requêtes en micros tâches qui seront multiplexées en même temps que traitées afin d’optimiser les ressources et les temps de latence cpu. Ce choix d’architecture offre des performances très élevées avec un consommation des ressources optimisée. Nginx fait ses preuves auprès de différentes

Il a été utilisé depuis plusieurs années sur des sites russes à fort trafic tel que Rambler, avant d’être plus largement répandu aujourd’hui : WordPress.com, hulu, Gravatar, Kongregate, userscripts.org et même … YouPorn ; )

Voici un petit bench comparatif des temps de réponses Apache v/s Nginx tiré du site http://www.joeandmotorboat.com/2008/02/28/apache-vs-nginx-web-server-performance-deathmatch/:

Quelques benchs par ici :

http://www.first-world.info/apache-vs-lighttpd-vs-nginx.html

http://www.joeandmotorboat.com/2008/02/28/apache-vs-nginx-web-server-performance-deathmatch/

Installation de Nginx sous Ubuntu

Nginx est maintenant disponible sur les dépôts, un petit apt-get fera donc l’affaire…

sudo apt-get install nginx

Configuration de Nginx

Fichier de configuration: /etc/nginx/sites-available/default

Une simple modification va consister à modifier le port d’écoute de 80 vers 81.

ajeanson@www:/etc/nginx$ sudo vi sites-available/default

# You may add here your
# You may add here your
# server {
#       …
# }
# statements for each of your virtual hosts

server {
listen   81;
server_name  localhost;

access_log  /var/log/nginx/localhost.access.log;

location / {
root   /var/www/nginx-default;
index  index.html index.htm;
}

location /doc {
root   /usr/share;
autoindex on;
allow 127.0.0.1;
deny all;
}

location /images {
root   /usr/share;
autoindex on;
}

…

Démarrage de Nginx

sudo /etc/init.d/nginx start

Le résultat est visible ici:

http://www.opensides.fr:81/

Conclusion

Nous avons vu que l’installation de Nginx était très simple. Nous verrons dans de prochains articles comment utiliser au mieux les différents modules de Nginx pour doper les performances de votre site web.

Tout le monde connaît Memcached ? Non ?

Memcached est un cache Open Source distribué et non répliqué. Cela veut dire que que nous pouvons utiliser plusieurs instances de Memcached mais que chaque instance est autonome. Si l’une d’elle tombe, ses données seront donc perdues (pas de réplication entre instance).

Pour aller plus loin, je vous conseille le wiki de Memcached: http://memcached.org/

Nous allons voir maintenant comment l’installer sur un unix:

Installation de libEvent (une dépendance de Memcached)

1. Vérifier que libEvent ne soit pas déja installé en tapant la commande whereis libevent dons votre terminal
2. S’il n’est pas déja installé, vous pouvez le récupérer à l’adresse suivante: http://monkey.org/~provos/libevent/
3. Décompresser l’archive sur votre disque
4. Dans un terminal taper les commandes suivantes:

./configure
make
sudo make install

Installation de Memcached

1. Vous pouvez le récupérer à l’adresse suivante: http://memcached.org/
2. Décompresser l’archive sur votre disque
3. Dans un terminal taper les commandes suivantes:

./configure
make
sudo make install
sudo ln -s /usr/local/lib/libevent-1.4.so.2 /usr/lib

Démarrer MemCached

memcached -p 11111

Tester MemCached avec telnet

$ telnet localhost 11211
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
get foo
VALUE foo 0 2
hi
END
stats
STAT pid 8861
(etc)

Tester MemCached en Java

Il faut d’abord choisir un connecteur. A la lecture de ce benchmark (cf. http://xmemcached.googlecode.com/svn/trunk/benchmark/benchmark.html), il semble que spyMemCached soit le plus performant.

Crééer un projet Maven en configurant votre pom de la façon suivante:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <groupId>fr.opensides</groupId>
 <artifactId>Memcached</artifactId>
 <version>0.0.1-SNAPSHOT</version>

 <repositories>
 <repository>
 <id>spy</id>
 <name>Spy Repository</name>
 <layout>default</layout>
 <url>http://bleu.west.spy.net/~dustin/m2repo/</url>
 <snapshots>
 <enabled>false</enabled>
 </snapshots>
 </repository>
 </repositories>

 <dependencies>
 <dependency>
 <groupId>spy</groupId>
 <artifactId>memcached</artifactId>
 <version>2.4rc1</version>
 </dependency>
 </dependencies>

</project>

Ensuite crééer une classe Main en codant un simple ajout / recupération de clé dans un serveur MemCached

package fr.opensides.memcached;

import java.io.IOException;

public class Main { 

private static final String hostName = "localhost";

private static final int portNum = 11111;

public static void main(String[] args) throws IOException {

// Get a memcached client connected to several servers

MemcachedClient cache = new MemcachedClient(AddrUtil.getAddresses(hostName+":"+portNum));

// Store a value (async) for one hour

cache.set("myKey", 3600, new String("myValue"));

// Retrieve a value (synchronously).

Object myObject = cache.get("myKey");

System.out.println(myObject);

}

}

Le tour est joué, nous avons maitnenant un serveur MemCached démarré en écoute sur le port 11111 avec un exemple de programme faisant une opération d’ajout / récupération de données dans le cache.

Je vous conseille de poursuivre votre lecture dans la doc de MemCached et de l’api SpyMemCached pour aller plus loin.

Quelques définitions

Haute disponibilité (cf. wikipedia)

La haute disponibilité est un terme souvent utilisé en informatique, à propos d’architecture de système ou d’un service pour désigner le fait que cette architecture ou ce service a un taux de disponibilité convenable.

La disponibilité est aujourd’hui un enjeu important des infrastructures informatiques. On estime aujourd’hui que la non-disponibilité d’un service informatique peut avoir des coûts se chiffrant en millions, particulièrement dans le domaine de l’industrie où l’arrêt d’une chaîne de production peut avoir un effet dévastateur.

HAProxy (cf.wikipedia)

HAProxy est un logiciel libre de répartition de charge écrit par Willy Tarreau. Il est disponible sous Unix (on trouve très facilement des binaires précompilés pour LinuxSolaris). et

HAProxy peut aider à mettre en place des solutions de hautes disponibilités, de répartition de charge et de proxy pour tous les types de protocole (TCP ou HTTP). Il est particulièrement bien adapté pour la gestion des très fortes charges sur un site Web tout en gérant la notion de persistance ou la manipulation des données de la couche 7 du Modèle OSI.

Description de l’application

Pour l’exemple, nous allons developper le classique HelloWorld, un WS-* dont le rôle va être de saluer l’internaute qui aura indiqué son nom en paramètre.

Voici la PI:

-> ajoutons une petite spécificité au service de façon à ce qu’il renvoie le port de l’instance qui va traiter la demande de façon à déterminer facilement quel serveur aura traité la requête lorsque nous ferons un déploiement sur plusieurs instances.

ex: « (8080) – Hello John »

Mise en place de HAProxy

Voila le service est maintenant opérationnel. A ce stade, il fonctionne mais si le serveur tombe le service ne fonctionne plus. C’est là que HAProxy va intervenir. Nous allons deployer ce service sur plusieurs serveur et le rôle de HAProxy va être de jouer un peu le chef d’orchestre en:

- assurant une distribution des requêtes sur les différents serveurs (LOADBALANCING)

- Évincer une instance DOWN en transférant la charge sur les serveurs UP (FAILOVER)

Installation & configuration

Installation sur Mac

sudo port install haproxy

Installation sur Ubuntu

sudo apt-get install haproxy

Récupérer un exemple de fichier de configuration basic

wget http://layer1.rack911.com/haproxy/haproxy-standard.cfg haproxy.cfg

Editer le fichier de config:

global
 maxconn     4096 # Total Max Connections. This is dependent on ulimit
 daemon
 nbproc      4 # Number of processing cores. Dual Dual-core Opteron is 4 cores for example.
 defaults
 mode        http
 clitimeout  60000
 srvtimeout  30000
 contimeout  4000
 option      httpclose # Disable Keepalive

listen  http_proxy 127.0.0.1:9999
 balance roundrobin # Load Balancing algorithm
 option httpchk
 option forwardfor # This sets X-Forwarded-For

## Define your servers to balance
 server server1 127.0.0.1:8080 weight 1 maxconn 512 check
 server server2 127.0.0.1:8181 weight 1 maxconn 512 check

Démarrer HaProxy

haproxy -f haproxy.cfg

Valider que la solution fonctionne

Maintenant HAProxy est démarré. Il écoute les requetes sur le port 9999 et les redirige sur les 2 instances Tomcat 8080 et 81818.

Il suffit maintenant de lancer des requêtes sur les le port 9999 et observons que HAProxy redispacth bien les requêtes sur les 2 instances:

(8080) - Hello John (#287)
 1 oct. 2010 10:28:33 org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromClass
 INFO: Creating Service {http://pi.opensides.fr/}MyServiceService from class fr.opensides.pi.MyService
 (8080) - Hello John (#288)
 1 oct. 2010 10:28:33 org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromClass
 INFO: Creating Service {http://pi.opensides.fr/}MyServiceService from class fr.opensides.pi.MyService
 (8181) - Hello John (#252)
 1 oct. 2010 10:28:33 org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromClass
 INFO: Creating Service {http://pi.opensides.fr/}MyServiceService from class fr.opensides.pi.MyService
 1 oct. 2010 10:28:33 org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromClass
 INFO: Creating Service {http://pi.opensides.fr/}MyServiceService from class fr.opensides.pi.MyService
 (8181) - Hello John (#253)
 (8181) - Hello John (#254)
 1 oct. 2010 10:28:33 org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromClass
 INFO: Creating Service {http://pi.opensides.fr/}MyServiceService from class fr.opensides.pi.MyService
 (8080) - Hello John (#289)
 1 oct. 2010 10:28:33 org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromClass
 INFO: Creating Service {http://pi.opensides.fr/}MyServiceService from class fr.opensides.pi.MyService
 (8181) - Hello John (#255)

Nous pouvons observer les stats de l’interface d’amin HAProxy:

Conclusion

Nous avons vu comment installer et configurer HAProxy pour assurer Loadbalacong et failover sur un WS-*. Nous pouvons observer la puissance et la simplicité de l’outil.

Pour plus d’informations rendez-vous sur le site de l’éditeur http://haproxy.1wt.eu/

Parlons un peu de SEDA…

Bon encore un vague acronyme…Ça veut dire quoi au fait ? Staged Event Driven Architecture.

OK, encore un nouveau paradigme dans la mouvance DDD, TDD, MDA  … ? Ben pas vraiment nouveau en fait, ça fait 10 ans que ça existe et c’est Matt Welsh qui lance le mouvement dans la année 2000 avec une publication (cf. http://www.eecs.harvard.edu/~mdw/papers/events.pdf).

Heu en 2 mots c’est quoi le principe ? Bon l’idée c’est de créer des architectures scalables. OK…comment ?

C’est la que ça devient intéressant …

Le principe est distinguer des « étapes ». Basiquement, on peut imaginer ces étapes comme étant les couches de notre architectures… Le principe est de faire communiquer ces couches de façon non-bloquantes en les faisant communiquer par des canaux dans lesquelles on publie des messages. De cette façon celui qui publie le message n’attend pas le retour et peut continuer son travail il sera avertit lorsque la réponse sera prête.

Comment ça marche ?

Dans les architectures en couches, chacune des couches délèguent aux couches inférieures un certain nombre de traitements. Dans une architectures synchrone le demandeur (stage 1) attend la réponse de l’exécuteur (stage 2) avant de continuer son travail. Ici les choses sont différentes, le demandeur envoie des demandes d’exécutions à l’exécuteur qui va les traiter à son rythme pendant que le demandeur poursuivra son travail en parallèle le temps d’obtenir d’obtenir la réponse demandée. C’est le concept présenté par le pattern request-reply des EAI (cf. http://www.eaipatterns.com/RequestReply.html).

Voyons cela en image:

Architecture synchrone

Ici, lorsque la couche A fait un appel à la couche B,  celle-ce reste bloquée en attente de réponse.

Architecture asynchrone

Ici, la couche A publie une requête dans une canal de requête (request) et continue son cycle de vie pendant que la couche B traite en parallèle la requête. Une fois le traitement terminé, la couche B va publier la réponse dans un canal de réponse (reply). Le canal peut être une file d’attente JMS, une queue, une base de donnée, etc…

Les principaux intérêt de ce pattern résident dans la possibilité d’exécuter des tâches en parallèle et d’adapter facilement les producteurs/consommateurs en fonction de l’état des files d’attentes ce qui rend ce type d’architecture hautement scalable:

La pratique

Aujourd’hui de nombreux acteurs proposent des implémentations de ce concept (Mule, Spring Integration, service Mix, …).

Je propose une petite librairie qui utilise des bloquing queue pour établir ses canaux de communication. C’est une classe abstraite qu’il suffit d’étendre pour permettre de paralléliser de façon asynchrone un traitement synchrone.

Exemple d’un appel synchrone

Prenons l’exemple d’une classe SampleSynchone qui fait appel à un service VeryLongLegacyProcess donnant la météo en fonction du jour passé en paramètre. Le temps d’exécution du service est de 5 secondes.

La classe appelante choisi de prendre un parapluie ou une casquette en fonction du temps. Une première implémentation donnerait le code suivant:

La classe SampleSynchone:

public class SampleSynchrone {

 VeryLongLegacyProcess veryLongProcess = new VeryLongLegacyProcess();

 public void howDoIDress(EDay day) throws InterruptedException{
 EWeather weather = veryLongProcess.whatTheWeather(day); //1 seconde
 String clothe = "";
 if (EWeather.RAINNY.equals(weather)){
 clothe = "umbrella";
 }else{
 clothe = "cap";
 }
 System.out.println(day+" I will take my "+clothe);
 }
}

La classe Main qui va appeler le traitement:

public class Main {

 public static void main (String[] args){
 System.out.println("current time:"+System.currentTimeMillis());

 LayerA layerA = new LayerA();
 layerA.howDoIDress(EDay.MONDAY);
 layerA.howDoIDress(EDay.TUESDAY);
 layerA.howDoIDress(EDay.WEDNESDAY);
 layerA.howDoIDress(EDay.THURSDAY);
 layerA.howDoIDress(EDay.FRIDAY);

}

Execution

current time:1272183941674
MONDAY I will take my umbrella(current time:1272183946682)
TUESDAY I will take my cap(current time:1272183951682)
WEDNESDAY I will take my umbrella(current time:1272183956683)
THURSDAY I will take my cap(current time:1272183961683)
FRIDAY I will take my umbrella(current time:1272183966683)

job execution: 25 009 ms

=> L’exécution du traitement pour chacun des jours de la semaine prend 25 secondes (5 fois 5 secondes).

Exemple Asynchrone

Nous allons maintenant essayer de réduire la fenêtre temporelle de la classe main en parallélisant les appels au service en étendant la classe Parallelizable.

La classe parallelisable:

public class Sample extends Parallelizable<EDay, EWeather>{

 VeryLongLegacyProcess veryLongLegacyProcess = new VeryLongLegacyProcess();

 public Sample(int nbExecutors) throws InstantiationException,
 IllegalAccessException, IllegalArgumentException,
 SecurityException, InvocationTargetException, NoSuchMethodException {
 super(nbExecutors);
 }

 @Override
 public void callback(Reply<EDay, EWeather> reply) {
 String clothe = "";
 if (EWeather.RAINNY.equals(reply.getOut())){//using results for next process
 clothe = "umbrella";
 }else{
 clothe = "cap";
 }
 System.out.println(reply.getIn()+" I will take my "+clothe);//using input parameters        
 }

 @Override
 public EWeather processRequest(EDay in) throws InterruptedException {
 return veryLongLegacyProcess.whatTheWeather((EDay)in);
 }

}

La classe Main qui va appeler le traitement:

public class Main {
 public static void main (String[] args){

 System.out.println("current time:"+System.currentTimeMillis());

 Sample sample = new Sample(5);

 sample.request(EDay.MONDAY);

 sample.request(EDay.TUESDAY);

 sample.request(EDay.WEDNESDAY);

 sample.request(EDay.THURSDAY);

 sample.request(EDay.FRIDAY);

}}

Execution

current time:1272184056048
WEDNESDAY I will take my umbrella(current time:1272184061059)
FRIDAY I will take my umbrella(current time:1272184061059)
THURSDAY I will take my cap(current time:1272184061059)
TUESDAY I will take my cap(current time:1272184061059)
MONDAY I will take my umbrella(current time:1272184061059)
job execution: 5 011 ms

La classe Parallelizable va créer un pool de threads exécuteurs, donnée en paramètre au niveau du constructeur (Sample sample = new Sample(5);). Ces threads seront mis en écoute à la première requête publiée dans le canal de requête (avec la méthode request (sample.request(EDay.MONDAY)). Chacun des thread va dépiler les messages envoyés et les traiter. La réponse sera ensuite publiée dans un canal de réponse, dépilée et envoyée dans la méthode callback qui permettra de terminer le traitement en choisissant le vêtement approprié.

=> L’exécution du traitement pour chacun des jours de la semaine prend cette fois 5 secondes du fait de leur exécution parallèle.

L’exemple, la librairie et les sources sont publiés sous la licence Apache V2 sur Source Forge https://sourceforge.net/projects/parallelizable/

C’est quoi la PermGen ?

La PermGen est un segment de mémoire dans laquelle sont stockés le bytecode et les type primitifs lors chargement de l’application. Cette zone mémoire contient donc l’ensemble des classes permettant à la JVM de créer les instances à partir de ces classes. (la voici tout à gauche sur le schéma).

Cette zone est donc chargée une fois lors du déploiement de l’application, c’est ensuite la Heap (Young et Old) qui seront sollicité pendant le cycle de vie de l’application.

C’est quoi un OutOfMemory error ?

A chaque nouveau déploiement, les nouvelles classes sont chargées dans la PermGen et il arrive parfois (souvent ?) que cette zone mémoire sature en nous affichant alors le message bien connu:

java.lang.OutOfMemoryError: PermGen space

Comment résoudre ce problème ?

Une première optimisation consisterait à augmenter la taille de cette zone:

-XX:PermSize=128m

C’est très pratique mais ça ne fait que repousser le problème

Nous avons vu que le garbage Collector n’intervient que sur le tas (la Heap) mais jamais sur la zone PermGen. Voici donc 2 options qui permettent d’activer le Garbage sur la heap en cas de saturation mémoire.

-XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

Je n’ai rien trouvé dans la doc officielle de Sun sur l’explication précise de ces options,  juste des votes pour qu’elles soit intégrées par défaut dans les prochaines version de la JVM (peut être dans la Dolphin): http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6329603

Une architecture SOA a pour principe d’exposer un ensemble de services à destination des utilisateurs. Ces services peuvent éventuellement être relayés par ces mêmes utilisateurs qui peuvent les décorer de nouvelles fonctionnalités. Un des facteurs critique de ce genre d’architecture est la «scalabilité». C’est à dire que le système doit pouvoir répondre linéairement à une charge de requêtes croissante.

Pour garantir une bonne scalabilité, l’enjeu est d’optimiser les ressources matérielles (calcul, mémoire, i/o) de façon à servir toutes les requêtes.

Conséquence d’une mauvaise gestion des ressources:

• dégradation des temps de réponses
• rejet des requêtes utilisateur
• effondrement du serveur par manque de mémoire (il faudra alors l’intervention manuelle des nos amis les administrateurs IT pour les redémarrer).

Objectif

Cet article a pour objectif de montrer comment optimiser les performances de notre service en donnant quelques pistes pour une bonne gestion des ressources au sein de notre architecture.

Petite piqûre de rappel

Rendez-vous aux pages suivantes pour un rappel sur les ressources matérielles: http://www.opensides.fr/?p=293

Et sur le fonctionnement d’une JVM (hotspot): http://www.opensides.fr/?p=271

Maintenant que nous maîtrisons ces bases, voyons comment ces ressources sont sollicitées aux travers d’un cas pratique.

Cas pratique

Pour illustrer la gestion des ressources, nous allons prendre l’exemple d’un musée. Ce musée représentera notre application. Des visiteurs formeront une file d’attente à l’entrée pour acheter leur ticket. Il représenteront les requêtes utilisateurs qui attendent d’acquérir une connexion au système. Lorsqu’un visiteur achètera son ticket, un agent lui préparera un casque d’écoute. Ce casque représentera l’accès à un service externe et la préparation par l’agent, l’acquisition de cette ressource. Le visiteur pourra alors faire sa visite avec son casque.

Voici le déroulement de la séquence:

1. les visiteurs forment une file d’attente à l’entrée du musée (> requête au système)
2. le visiteur  arrive au guichet, il achète son ticket (> connexion au serveur, le processeur (guichet) est sollicité et le visiteur entre dans le musée donc la mémoire est consommée)
3. le guichet prend alors un casque dans un sac (> récupération de la ressource à partir de la mémoire morte, le sac peut être une base de donnée par exemple)
4. le guichet initialise et le donne au visiteur (> la processeur est sollicité pour initialise un Web Service et utilise les I/O pour l’acquisition de la connexion)
5. le client possède son casque et peut donc faire sa visite guidée pour une durée aléatoire (> utilisation du service)
6. il interrompt ensuite sa visite mais ne sort pas du musée et ne rend pas son casque (pas bien…)

Précisions:

• le musée ne possède qu’un seul guichet qui est en charge de délivrer les tickets et de distribuer les casques aux visiteurs (> un thread gérant une fille d’attente)
• la récupération du casque oblige le guichetier à fouiller dans un sac et représente donc une opération longue  (1 minute) (>occupation du thread pour acquérir la connexion à la base de donnée)
• l’initialisation du casque est aussi une opération longue (2 minute) pendant laquelle le guichet ne peut servir les autres visiteurs (>occupation du thread pour acquérir la connexion au WS externe)
• un casque coûte 10$ (>  empreinte mémoire de l’objet (1024*1024 byte))
• chaque client ne rend pas systématiquement son casque à la sortie,  il le laisse dans une salle du musée  (> non relâchement des objets,  fuite mémoire)
• le musée possède 1000 casques (>taille de la zone Eden dans la JVM)
• le musé à une capacité d’accueil de 1000 visiteurs simultanés (>capacité mémoire du système)

Limites du système actuel

• pour chaque visiteur le guichet doit prendre un casque dans un sac ce qui fait perdre 1 minute à l’ensemble des visiteurs
• le guichet initialise ensuite le casque ce qui fait à nouveau perdre 2 minutes à l’ensemble de la file d’attente
• les visteurs ne ressortent pas du musée (>fuite mémoire potentielle)
• les visteurs ne rendent ps leur casque (>fuite mémoire potentielle)

Passons à la pratique

Lançons l’application pour en observer le fonctionnement:

[0 ms] Le visiteur #1  achète un ticket
[3 ms] Le guichetier récupère le casque #1 ...
[1000 ms] Le guichetier initialise le casque #1 ...
[2001 ms] Le visiteur #1  prend le casque le casque #1
[0 ms] Le visiteur #1 entre dans le musée
[1 ms] Le visiteur #2  achète un ticket
[0 ms] Le visiteur #1  commence sa visite ...
[3 ms] Le guichetier récupère le casque #2 ...
[1000 ms] Le guichetier initialise le casque #2 ...
[2000 ms] Le visiteur #2  prend le casque le casque #2
[0 ms] Le visiteur #2 entre dans le musée
[0 ms] Le visiteur #3  achète un ticket
[1 ms] Le visiteur #2  commence sa visite ...
[1 ms] Le guichetier récupère le casque #3 ...
[1000 ms] Le guichetier initialise le casque #3 ...
[2000 ms] Le visiteur #3  prend le casque le casque #3
[1 ms] Le visiteur #3 entre dans le musée
[0 ms] Le visiteur #3  commence sa visite ...
[0 ms] Le visiteur #4  achète un ticket
[707 ms] Le visiteur #2  arrête sa viste
...
[1001 ms] Le guichetier initialise le casque #79 ...
[1000 ms] Le visiteur #79  prend le casque le casque #79
[0 ms] Le visiteur #79 entre dans le musée
[0 ms] Le visiteur #79  commence sa visite ...
[0 ms] Le visiteur #80  achète un ticket
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
 at fr.opensides.lab.musee1.Guichetier.accueilVisiteur(Guichetier.java:16)
 at fr.opensides.lab.musee1.Main.main(Main.java:11)
[322 ms] Le visiteur #75  arrête sa viste
[3248 ms] Le visiteur #79  arrête sa viste
[3 ms] Le visiteur #77  arrête sa viste
[1527 ms] Le visiteur #78  arrête sa viste

On remarque sans surprise que l’initialisation des casques est très coûteuse ( 1 seconde pour la récupération / 2 secondes pour l’initialisation) et surtout systématique. Elle pénalise donc l’ensemble de la file d’attente.

Penchons nous maintenant sur la mémoire. Pour cela, ouvrons un VisualVM et regardons la gestion de la heap. (cf. ci-dessous)

On observe que les Garbage Collector (GC) représenté sur le graph par des creux sont réguliers, ce qui est normal mais ne sont pas profond, ce qui l’est moins… Cela indique que le GC est inefficace car il ne parvient pas à récupérer de la mémoire.

Conséquences

>Le musée est saturé à 80 visiteurs et nous renvoie l'erreur ci-dessous:
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
 at fr.opensides.lab.musee1.Guichetier.accueilVisiteur(Guichetier.java:16)
 at fr.opensides.lab.musee1.Main.main(Main.java:11)

Explication: qu’est ce qu’une fuite mémoire ?

C’est le pattern typique d’une fuite mémoire, la JVM ne parvient pas à relâcher les objets car ils sont référencés (en référence forte) par les visiteurs. La mémoire va donc se remplir jusqu’à saturation( palier en haut de la courbe), ce qui se traduit par le message ci-dessus.

Dans notre exemple, le gardien du musée (la JVM) interrompt le travail du guichetier pour aller chercher les casques dans le musée (Garbage Collector).
Le problème c’est que lorsqu’il trouve un casque il n’a aucun moyen de savoir si le casque est en cours d’utilisation par un visiteur. Dans le doute, il ne peut pas le récupérer car le casque appartient au visiteur (référence forte), il le laisse donc à sa place et les casques s’accumulent dans le musée.

1 ère optimisation: relâcher les objets

Quels sont les objet qui encombrent le musée ? Les casques et les visiteurs. Il faut donc les faire sortir pour corriger notre fuite mémoire.

Cela nous semble logique dans un cas de la vie réel mais étrangement cela parait beaucoup moins intuitif en programmation..

Comment faire ?

A la fin de la visite, nous allons simplement demander au visiteur de :

1/ rendre leur casque:

–> en pratique on remet le casque à null

2/ de sortir du musée:

-> en pratique ils se supprime de la map « Musée » au niveau de la méthode « interrupt » du thread visteur:

getMusee().remove(this.getId());//le visiteur sort du musée

Conséquence:
La fuite mémoire est corrigée, le musée ne sature plus.

2 ème optimisation: préparation des casques (mise en place d’un mécanisme de cache)

Il reste un problème de lenteur au niveau de la récupération l’initialisation des casque. Pour réduire ce temps d’attente des visiteurs, l’agent peut sortir à l’avance un ensemble de casques de son sac, les initialiser et les disposer sur un présentoir de façon à les distribuer plus rapidement.

• Utilisation d’un présentoir (cache en SoftReference)
• Le visiteur remet son casque sur le présentoir (cache en SoftReference)

Conséquence:

L’utilisation du présentoir permet de réduire considérablement les temps d’attentes des visteurs. Malgré le fait que les visteurs ne renden pas relement leur casque car ils sont référencés dans le cache, le cache en SoftRéférence permet de relâcher les objets lorsque la mémoire sature.

Le guichetier prend un casque sur son présentoir [0 ms]
[0 ms] Le visiteur #244  prend le casque le casque #244
[0 ms] Le visiteur #243  commence sa visite ...
[0 ms] Le visiteur #244 entre dans le musée
[0 ms] Le visiteur #245  achète un ticket
Le guichetier prend un casque sur son présentoir [0 ms]
[1 ms] Le visiteur #245  prend le casque le casque #245
[0 ms] Le visiteur #244  commence sa visite ...
[1 ms] Le visiteur #245 entre dans le musée
[0 ms] Le visiteur #246  achète un ticket
Le guichetier prend un casque sur son présentoir [0 ms]
[1 ms] Le visiteur #246  prend le casque le casque #246
[0 ms] Le visiteur #245  commence sa visite ...
[1 ms] Le visiteur #246 entre dans le musée
[0 ms] Le visiteur #247  achète un ticket
Le guichetier prend un casque sur son présentoir [0 ms]
[2 ms] Le visiteur #247  prend le casque le casque #247
[1 ms] Le visiteur #246  commence sa visite ...
[3 ms] Le visiteur #247 entre dans le musée
[0 ms] Le visiteur #248  achète un ticket
[0 ms] Le visiteur #247  commence sa visite ...
[0 ms] Le visiteur #240  commence sa visite ...
[51 ms] Le visiteur #238  rend dépose le casque sur le présentoir
[64 ms] Le visiteur #198  rend dépose le casque sur le présentoir

>L’application tourne en continue sans saturation

Mémoire

On observe que la heap se remplie jusqu’à atteindre son seuil max. Proche du max, les SoftReference joue leur rôle en permettant à la JVM de libérer les objets au lieu d’atteindre le max (générant une OOME).

cpu

On voit que ce mécanisme à un coût en terme de GC (en bleu l’activité cpu liée au GC).

thread

Au bout de 14 minutes, 10377 threads on pu être traités par l’application. Soit autant de visiteurs on pu visiter le musée.

Remarques:
On remarque une augmentation de la heap jusqu’à se rapprocher du max. C’est la SoftReference qui fait bien son job en permettant de relacher les objets quand la mémoire sature.
Il est important de noter que ce fonctionnement a un cout. Cette fois c’est la processeur
qui travaille en déplaçant les objets de la heap vers la perm et en relaçhant les objets (cf. cpu)

Explication

Cette opération consiste à utiliser un pool (ou cache) représenté par le comptoir qui permet d’éviter de répéter les opérations coûteuses de connexion à la base de donnée. On parle dans ce cas de « cacher » les informations pour les rendre accessible plus rapidement lors des prochaines utilisations. Dans notre exemple, le présentoir aura une capacité limité à 100 casques. Ce qui implique que le guichetier devra nettoyer régulièrement son présentoir.

Il devra donc gérer les problématiques suivantes:

• lorsque les visteurs auront pris l’ensemble des casques il devra à nouveau récupérer les casques dans le sac et les initialiser
• lorsque un visiteur quittera le musée rendra son casque sur la table il pourra le redistribuer à un autre visiteur
• lorsque la table sera pleine de casque les anciens casques présents sur la table seront remis dans le sac

La technique que nous utiliserons pour implémenter cet exemple est un pool qui aura pour caractéristique de libérer les ressources les moins récemment utilisées. Ce type d’algorithme de relâchement des ressources est appellé LRU pour Last Recently Used (cf. http://fr.wikipedia.org/wiki/Algorithmes_de_remplacement_des_lignes_de_cache#LRU_.28Least_Recently_Used.29).

Les références Java pour les nuls

Il existes différents types de références selon leur degrés d’attachement (ici classés du plus fort au moins fort) (cf. http://blog.developpez.com/adiguba/p2107/java/comprendre-les-references-en-java/):

• les références fortes (strong reference): C’est la référence par défaut. L’objet est lié fortement à l’autre comme c’est le cas actuellement avec nos casques du fait que le visteur paye la location de son casque il ya une notion d’appartenance au moment de la visite. Le guichetier à ce titre ne peut pas décider de récupérer le casque qu’il trouve car il pénaliserait le visteur si celui-ci l’utilise encore
• les références douces (soft reference, cf. SoftReference): une référence douce indique à la jvm que celle-ci peut supprimer l’objet si le besoin s’en fait sentir. Dans notre exemple cela s’apparenterait au fait de prêter le casque au lieu de le louer. Dans ce cas l’utilisation du casque n’est pas nominative, les casques sont laissés dans le musée (seulement) lorsque le guichetier n’a plus de casque disponible il peut récupérer sans remord l’ensemble des casques présents dans le musée partant du principe qu’ils n’appartienne pas aux viseurs.
• les références faible (weak reference, cf. WeakReference): une référence faible permet de stocker une référence, mais ne permettent pas d’assurer a elle seule que l’objet stocké sera conservé en mémoire. Les références faibles permettent ainsi de faire dépendre la durée de vie d’un objet par rapport à la validité d’un autre objet. Dans notre exemple, lorsque le visiteur n’est plus présent, le casque est automatiquement récupéré par le guichetier.
• les références fantômes (phantom reference, cf. PhantomReference): les références fantômes sont un peu particulières dans le sens où leur méthode get() renverra toujours null. En effet l’objectif des références fantômes est d’être avertis de la suppression complète d’un objet par le GC. En effet, contrairement aux WeakReference et SoftReference qui sont « invalidées » dès que commence le processus de libération les PhantomReferences ne sont ajoutées à la ReferenceQueue associée que lorsque l’objet référencé est complètement supprimé de la mémoire (cela permet d’éviter des « résurrections obscures » d’objets dans la méthode finalize()). Bon il va falloir un peu d’imagination pour intégrer ce type de référence dans notre exemple mais pour le moment elle ne nous sera pas utile.

Nous avons vu que le cache en SoftReference permettait de libérer les objets lorsque la mémoire sature. Cette solution est pratique car elle évite les OOME mais n’est pas optimale puisqu’elle génére une forte activité de Garbage Collection pour libérer les ressources.

3 ème optimisation: rendre les casques à la fin de la visite (retour des objets dans le pool)

Nous avons pu constater plus haut une ofrte activité du GC pour libérer les ressources du pool. Pour éviter ce problème il suffit de retourner les objets dans le pool en demandant aux visteurs de reposer leur casque sur le présentoir à la fin de la visite.

//On remet le casque dans le pool pour éviter un overhead cpu lors de la libération des SoftReference au moment du garbage
presentoire.returnObject(this.get(key).getCasque());

Conséquence

Le résultat est assez spectaculaire

On remarque que l’activité du garbage a considérablement baissé. L’activité CPU est maintenant mobilisée sur l’application.

Niveau mémoire, on remarque des GC réguliers sans saturation.

Au bout de 10 minutes, l’application a pu gérer près de 100 000 threads (soit autant de visteurs) contre 10 000 en utilisant uniquement les SoftReference.

4 ème optimisation: optimiser les options de la JVM

Ajoutons quelques options à la JVM:

-Xms1024m -Xmx1024m -Xmn512m -XX:+AggressiveOpts -XX:+UseParallelGC -XX:ParallelGCThreads=16

Et observons le résultat:

Le GC occupe à peine 1% de l’activité CPU.

Les minor GC sont très réguliers jusqu’à atteindre le seuil (ce qui declenchera un full GC)

Le nombre de threads traité passe de 100 000 à 211 124. Nous avons doublé le nombre de visiteurs dans le musée  (throughput).

Conclusion

L’objectif de l’article était de donner quelques pistes pour améliorer les performances d’une application. Dans un premier temps, nous avons vu qu’il était important de libérer les ressources pour éviter, au mieux, les garbages coûteux, au pire, les fuites mémoires. Un mécanisme de cache s’est révélé utile pour éviter la (re)création d’objets coûteux mais pouvait potentiellement engendrer une fuite mémoire en marquant une référence à un objet. Cela peut être évité avec l’utilisation d’un cache en SoftReference qui garantit la libération des objets en cas de saturation mémoire. Nous avons vu ensuite que ce seul mécanisme n’était pas suffisant pour garantir de bonnes performance et qu’il fallait nécessairement relâcher les objets afin d’éviter un overhead cpu lié au Garbage collector. Enfin un petit tunning de la JVM permet d’améliorer nos performances (elle a permis de doublé le nombre de visiteurs dans le musée). Nous verrons dans un prochain article comment améliorer encore les performances de notre application en recrutant de nouveaux guichetiers et en ouvrant de nouveaux musées…

Bibliographie

• http://fr.wikipedia.org/wiki/Ressource_%28informatique%29
• http://blog.developpez.com/adiguba/p2107/java/comprendre-les-references-en-java/
• http://fr.wikipedia.org/wiki/Algorithmes_de_remplacement_des_lignes_de_cache#LRU_.28Least_Recently_Used.2