Améliorez les performances: Parallel processing with Camel & Spring (Partie 1/2)

Ce billet s’inscrit dans la catégorie optimisation des performances.

Il se fixe comme objectif d’illustrer avec démo détaillée comment améliorer significativement les performances de nos projets.

Et cela sans se lancer dans l’aventure d’écrire des kilomètres de code lourd de gestion du ‘parallel processing’ car nous allons laisser la puissance du framework Camel opérer.

Sachez néanmoins que de nombreux problèmes de mauvaise performance peuvent être traités sans recours aux implémentations complexes de parallélisme.

Voici deux situations où il faudrait réfléchir sur l’apport du parallélisme :

– Si les tâches ou opérations ne prennent que très peu de temps (échelle quelque sec). La gestion/monitoring des threads devient coûteux.

– Si les ressources mémoire, CPU et IO sont déjà fortement utilisées; sachez que le parallélisme consomme davantage de ressources.

Le billet veut s’inspirer (librement) des deux étapes décrites dans la démo du chapitre 10 du livre « Camel in action ».

L’essentiel du code source est fourni ici.

Sachez néanmoins que le code présenté ci-après a été largement adapté et pour certaines parties complètement réécrits.

En effet, comme j’utilise Spring, toutes les parties de code sont adaptées ou réécrites en fonction.

En particulier j’utilise l’implémentation spring ThreadPoolTaskExecutor de l’interface TaskExecutor à la place de la méthode statique de Executors de java.

Le billet est organisée en deux parties:

– La première partie permet d’exécuter en séquentiel notre démo,

– La seconde permet adapte la première partie pour une exécution parallèle.

Nous donnons quelques indications sur le temps d’exécution de chacune des parties.

Avec les bons paramètres nous pouvons diviser par quatre le temps d’exécution voire plus.

Le framework Camel offre avec son java DSL des fonctions permettant d’obtenir simplement de meilleurs performances en parallélisant les tâches.

Comme d’habitude nous le combinons avec le framework Spring v3+ car peut-on faire autrement?

Dans le domaine de performance, il est utile d’identifier les deux limites: CPU-bound et IO-bound.

Distinguer ces deux limites permet d’identifier le bon choix pour améliorer les performances.

En guise de conclusion, dans le domaine d’exécution parallèle, Camel simplifie grandement la vie des développeurs.

Néanmoins, il leur reste la responsabilité de la cohésion des données.

Passons à la mise en pratique.

Présentation, étape par étape, de Spring-DATA-JPA

Ce billet présente une démo pour illustrer, étape par étape, comment utiliser Spring-Data-JPA.

Ce billet peut être considéré traitant le même thème que Construction de requêtes en Java : comment faire le bon choix ?.

Nous détaillons, dans une première partie, la prise en main du « framework » Spring-Data-JPA avant de progresser dans notre compréhension.

Le projet Spring-Data-JPA est l’un des projets de Spring reposant sur Spring-Data.

Spring-Data réduit considérablement le coût économique de la couche d’accès aux données relationnelles ou NoSQL.

Il simplifie l’accès aux bases de données SGBDR ou de type NoSQL.

Spring-Data peut-être combiné avec le framework QueryDSL (Domain Driven Design) afin de réaliser des requêtes complexes.

Avec Spring-Data-JPA, le développeur bénéficie d’un certain nombre de méthodes d’accès à la base sans écrire une ligne de code d’implémentation.

Le projet Spring-Data-JPA vise à améliorer la mise en œuvre de la couche d’accès aux données en réduisant considérablement l’effort d’écriture du code d’implémentation en particulier pour les méthodes CRUD et de recherche.

La notion centrale dans Spring-Data-JPA est la notion « Repository ». Le repository est une interface à écrire par le développeur.

Il déclare, dans cette interface, les méthodes utiles d’accès aux données et Spring-Data-JPA fournit les implémentations nécessaires.

Notez que la même approche est appliquée à des contextes autres que JPA comme pour les bases non relationnelles.

Vous pouvez télécharger les sources de la démo1 ici.

Avec Spring-Data, écrire des méthodes de requête à la base se fait en 3+1 étapes:

  • Déclarer une interface Repository,
  • Ecrire la signature de la méthode de requête (CRUD ou de recherche),
  • Configurer Spring pour la génération automatique,
  • Appeler dans le client (ou test unitaire) les méthodes du Repository

C’est aussi facile!

Mais là on n’a fait que survoler la surface de Spring-Data.

Nous allons détailler ces étapes ci-après dans la démo.

Mylyn 3.5 – Intégration de Hudson dans Eclipse

La nouvelle version 3.5 du module Mylyn permet d’avoir accès à la plate-forme d’intégration Hudson directement depuis l’environnement de développement de Eclipse.

Ainsi plus besoin de sortir de Eclipse, toutes les informations sont disponibles depuis Eclipse :

  • l’état des jobs d’intégration est rafraîchi automatiquement dans Eclipse et une notification s’affiche indiquant si un build échoue
  • les résultats des tests du job sous Hudson s’affichent dans la vue JUnit comme s’il s’agissait de tests unitaires lancés en local.
  • les traces de la console du build Hudson sont affichées dans la vue console de Eclipse

Paramètres mémoire de la JVM pour le plugin maven-surefire-plugin

Chez Netapsys, nous mettons un point d’orgue à assurer la qualité de nos réalisations. Dans nos développements, les tests y sont pour beaucoup. Nous utilisons, pour les exécuter, le plugin Eclipse Junit. Et, dans le cadre de l’industrialisation de nos projets, ces tests sont lancés via Maven grâce au plugin maven-surefire-plugin.

Problème :
Récemment j’ai eu besoin de booster la mémoire de la JVM pour lancer un test assez gourmand en ressources. Et là, problème : alors que mon test passait sans problème sur Eclipse, il déclenchait à chaque fois une exception java.lang.OutOfMemoryError: Java heap space lorsqu’il était lancé via Maven, et ce malgré un paramétrage identique au niveau variables d’environnement.

[Paris JUG] Soirée spéciale Tests

Le 11 janvier 2011 a eu lieu le premier JUG de 2011, ayant comme thème: les Tests.
La soirée était animée par David Gageot, auteur du blog Java Bien!.

Lors de nos développements, nous avons tous été confrontés à écrire des tests. Un bon développeur doit écrire des tests fonctionnels et/ou unitaires de façon régulière. Mais s’il y a beaucoup de tests, le build prend plus de temps. Du coup, nous perdons du temps sur la suite du développement.

La question est: Comment faire des tests rapides et efficaces ?

AGILE & MORE EFFICIENT : Test JUnit, EasyMock & Spring

Ce billet aborde l’aspect purement technique de mise en oeuvre de l’agilité dans le développement d’applications robustes.
Il s’inscrit dans la continuité du séminaire de Netapsys sur le thème « Agile & more efficient ».
Il présente les tests JUnit 4.x et EasyMock sous Spring afin de concrétiser « être agile ».
EasyMock permet de simuler l’accès aux fonctionnalités des couches applicatives, par exemple la couche DAO.
Un des piliers de l’agilité est TDD (Test Driven Development).
Le TDD est une approche évolutive de réalisation de projets basés sur les tests avant même de produire du code effectif.
TDD combine le TFD (Test First development) et le refactoring afin d’arriver à affiner / définir les spécifications.
Easymock et JUnit constituent donc les briques afin de réaliser le TDD via les tests unitaires et d’intégration.
En fait, les tests unitaires sont faciles à mettre en place mais les tests d’intégration restent encore difficiles.
Et le coût de réaliser les tests d’intégration est pesant.
Et EasyMock permet la mise en place des tests sans pour autant avoir développé une ligne de code d’implémentation des couches applicatives.
Tous ces aspects vont être explicités ci-dessous.

Spring annotations vs standards annotations: Que choisir entre @Autowired et @Resource?

L’objet de ce billet, en deux parties, est de comparer l’annotation standard @Resource du package javax.annotation.Resource à celle de
spring @Autowired du package org.springframework.beans.factory.annotation.
Nous verrons les situations où nous sommes obligés de favoriser les annotations standards.

L’utilisation des annotations réduit considérablement la verbosité des fichiers de configuration de Spring.
C’est aussi le même constat pour d’autres frameworks.
En effet, le principe « convention Over configuration » participe à cette diffusion.
Certes, les « pour » et les « contre » ne manqueront pas d’arguments pour débattre.
Mais ceci n’est pas l’objet de ce billet.
L’objectif ici est de comparer ces deux types d’annotations.
Pour cela, nous nous appuyons sur un projet java simple, sans maven, que vous pouvez créer sous Eclipse en suivant les étapes décrites ci-après.
Nous écrivons d’abord un projet avec les annotations de Spring puis nous illustrons les difficultés qui nous amèneront à introduire les annotations standards.