Donc comment faire pour héberger une application Java avec un minimum de performance ? Les premiers tests ont été désastreux avec uniquement quelques requêtes par secondes… J’ai donc effectuer du profiling du front avec notamment Firebug et YSlow afin d’apporter les optimisations nécessaires à mon code source. Ensuite, j’ai optimiser la configuration de mon application et mis en place un cache applicatif avec ehCache afin de soulager la base de donnée MySQL.

Cependant, la meilleur des optimisations a été de mettre en place un frontal Nginx avec une configuration des headers pour le cache et une compression zip adaptée couplés à la mise en place d’un webcache avec Memcached. Les performances sont désormais au rendez vous et le serveur ne pâti plus de pic de charges CPU sous mes agressions avec l’outil que j’utilisait à l’époque pour simuler la charge : apache-benchmark. Ainsi sur la page des produits, on obtient encore 124 requêtes par seconde aujourd’hui (je ne me rappel plus du score de l’époque qui était du même ordre) :

Concurrency Level:      10
Time taken for tests:   8.049 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      5478000 bytes
HTML transferred:       5245000 bytes
Requests per second:    124.25 [#/sec] (mean)
Time per request:       80.485 [ms] (mean)
Time per request:       8.049 [ms] (mean, across all concurrent requests)
Transfer rate:          664.67 [Kbytes/sec] received

L’application n’a pas été redémarré depuis plus d’un an et demi et les performances, comme le bon vin, ne font que s’améliorer. On remarque que le débit obtenu est très proche du débit théorique fourni par Gandi (5Mb). Pour preuve de l’ancienneté de l’application :

Aucun problème à signaler depuis malgré l’arrêt des mises à jour des logiciels suite à l’arrêt de la collaboration avec le commerçant pour le moment. Comme quoi performances et disponibilité ne sont pas si difficile a obtenir … même en environnement « hostile ». Cela dit, aujourd’hui je ne proposerais pas une telle solution à un client qui n’a pas de gros besoins de performances. Il faut savoir que la société derrière Play! framework (Zenexity) propose une plateforme d’hébergement d’applications : www.playapps.net Pour 10€, les résultats sont au rendez vous et c’est clef en main… pourquoi se priver ! Par ailleurs, d’autres plateformes « cloud » proposent de plus en plus une compatibilité avec Play! framework comme par exemple Heroku. Peut être qu’un jour je ferais un article sur le sujet…

La Loire-Atlantique ouvre les données publiques par Loire-atlantique

Ce qui est disponible à Nantes

Alors après ce beau discours, il est important de comprendre que les données proposées sont pour l’instant peuvent être de deux types : soit des fichiers mis à jour plus ou moins régulièrement, mais en général il s’agit d’un fichier par an, par exemple concernant la liste des installations sportives ou culturelles ou encore la liste des codes postaux de Nantes. Soit avec une fréquence bien plus rapide de mise à jour, comme la disponibilité des places de parkings ou encore les indices de qualité de l’air. Ces dernières sont appelées API sont de vrai bijoux qui permettent la création d’applications mobiles et/ou Web apportant une vrai valeur ajouté à l’usager. L’exemple le plus courant est très certainement les applications iPhone et Android qui permettent de tout savoir sur les transports en commun ou encore les bicloo. L’open data est également très friande d’écologie et on retrouve le retrouve donc ici avec notamment l’ensemble des données concernant les espaces verts ainsi que les indices de pollutions. Sur ce dernier point on a d’ailleurs accès à un grand nombre de paramètres : particules fines, dioxyde d’azote et dioxyde de souffre.

On remarquera que la majorité des fichiers sont disponibles en CSV ce qui est une bonne chose puisqu’il est encore monnaie courante de trouver des fichiers Excel ou pire des fichiers XLSX qui requièrent l’achat de logiciels Microsoft pour pouvoir être lu. Concernant les API, elles sont faciles à utiliser utiliser par les développeurs qui peuvent ainsi requêter une interface facile à comprendre et proposant des résultats au format XML, CSV ou KMZ. On pourra regretter que les API ne soit pas davantage unifiées et orienté REST.

Et pour la France ?

Les Etats Unis ont été les premier à se lancer dans l’open data. Aujourd’hui la France rattrape son retard avec le site gouvernemental dédié à l’ouverture des données. Les données qu’on y trouve concerne d’avantage des statistiques et les chiffres concernant la fiscalité. Le gouvernement a fait le choix de déléguer l’ouverture des données à chaque ministère sur son domaine de compétence, sous l’impulsion de Etalab présent sur Facebook. On retrouve également l’INSEE, le CSA ou encore IGN en ce qui concerne les producteurs de données. http://data.gouv.fr se veut depuis le 5 décembre 2011 la plateforme française d’ouverture des données publiques.

Récemment une grande première s’est produite puisqu’il s’agit d’une société privée, la SNCF, qui a ouvert sa propre plateforme open data. A terme on peut espérer que tout ceux qui détiennent des données public les distribues librement. C’est ceux vers quoi la France se dirige pour le moment. Même si les jeux de données proposés sont encore limités et parfois peu commode à exploiter à cause du format des fichiers.

Un petit délire ?

Alors comme je cherchais une idée simple (je ne voulais pas y passer plus d’une soirée) et fun, j’ai choisi de créer un mini site Web qui permette (autant que possible) d’aider à choisir des prénoms. Pour cela j’ai écris une application avec Play! et MongoDB. Je me suis basé sur les prénoms les plus utilisés sur ces dernières années grâce aux plateformes open data de Nantes et Paris. J’ai ainsi pu récupérer 1697 prénoms. Le résultat est ici : http://www.jechercheunputaindeprenom.fr/

Au final, il n’est pas très utile… mais j’ai déjà trouver d’autres idée bien plus utiles qui seront présentés dans un prochain article…

Le développement Web sur TV

Chez Wiztivi, nous sommes des pionniers de la télé connectée et forcément ça aide. Nous sommes en contact permanent avec les constructeurs et les différents acteurs de l’IPTV, y compris (bien sûr) notre principal actionnaire : SFR. L’environnement de développement classique d’un développeur d’applications TV, c’est un PC et pleins de TV : différentes marques, différents modèles, différents firmwares mais aussi quelques box ADSL et consoles de jeux

Du point de vue des technologies, ça reste du standard : HTML, CSS, Javascript. La plupart des TV intègre aujourd’hui WebKit ce qui nous facilite le travaille mais il reste malgré tout de nombreuses différences entre TV ce qui nécessite un effort particulier d’intégration et de tests. Il y a aussi les spécificités de chaque marque : API propriétaire et lecteurs vidéo différents. Finalement, l’environnement n’est pas plus contraignant que de réaliser une application Web classique qui soit fonctionnelle sur la majorité des navigateurs du marché (Firefox, Chrome/Safari, Internet Explorer, Opera).

En terme d’usage des applications, tout se pilote depuis la télécommande ce qui a notamment des impacts sur la gestion de la navigation et du focus. Il nous arrive également de devoir gérer des widgets spécifiques à la TV comme un clavier virtuel ou des players video.

La technologie HbbTV

Jusqu’à présent la solution la plus utilisée pour déployer des applications Web sur TV et box étaient d’héberger celles ci sur un serveur. Le constructeur intégrait le lien vers l’applications via son firmware. De ce fait, les communications passent par la prise ethernet de la TV/Box. HbbTV est une nouvelle approche qui permet au contraire de diffuser l’application dans le flux TV. L’idée est d’ajouter des informations au niveau de la TNT. Ainsi ce sont les chaînes qui peuvent désormais diffuser des applications.

HbbTV propose deux modes de fonctionnement : broadband et broadcast. La première approche est assez classique : on va définir une URL dans le flux. Lorsque l’utilisateur arrive sur une chaîne, l’application est chargée depuis cette URL. La communication passe donc par la prise ethernet et fonctionne (presque) comme une application standard : on peut notamment faire des requêtes XHR. La seconde approche est différente. Elle permet de diffuser l’application dans son intégralité dans le flux. Les performances sont donc tributaire du débit TNT et nous oblige à restreindre la taille des images et la quantité d’informations à envoyer à la TV. L’application peut malgré tout se mettre à jour par des informations qui sont mise à jour au niveau du flux (le carousel et les stream events). Développer une application broadcast est donc très contraignante pour le développeur et ça on s’en rend compte quand on développe, pas en lisant les spécifications du standards qui de toute façon ne sont pas respectées à la lettre.

Les TV qui supportent cette technologie ont commencé à apparaître sur le marché français en début d’année. Elles devraient se démocratiser en 2012. On peut dors et déjà acheter, par exemple, cet TV Toshiba de 42 pouces (800€).

France Télévision et HbbTV

France Télévision avait déjà effectué une démonstration à l’IFA. Cette application sera prochainement diffusée au niveau national mais pour la chaîne public le vrai grand test se déroulait en ce printemps 2011. L’idée du projet Roland Garros était de montrer que l’usage de l’HbbTV permet un usage enrichie de la TV. On parle d’ailleurs souvent de « télétexte HD ». France Télévision fait partie du consortium qui développe HbbTV et souhaite réellement devenir leader sur ce thème sur le plan national.

L’application Roland Garros

Les internationaux de Tennis intéressent énormément de monde et chaque jour France 2 et France 3 diffusaient de nombreux matchs. Le but de l’application est d’apportée le maximum d’information aux utilisateurs : résultats en direct (y compris pour les matchs qui ne sont pas en cours de diffusion), les fiches des joueurs et un album photo. Il y a différents modes d’affichages et on peut basculer à volonté entre le live et l’application grâce à la télécommande. L’application était disponible uniquement en broadband. Une popup « Veuillez connecter votre TV » apparaissait si nécessaire. Voici une vidéo de démonstration :

Architecture nosql

Les données nous ont été mise à disposition par IBM. De notre coté nous avons donc développé une application HTML/CSS full javascript. Pour les besoins de mise en forme des informations et de performances, nous avons mis en place un serveur d’application avec une application Spring connectée à la fois au backend IBM et à une instance MongoDB hébergée localement. Ainsi nous avons mis en place un batch qui régulièrement importait et mettait en forme les données (XML) dans notre base. Il faut savoir que nous recevions énormément d’information pour tout les matchs en cours. En fin de tournois, nous avions plusieurs giga de base de donnée. Mongo nous a permis de construire un modèle de donnée prêt à l’emploi notamment pour le résultat des matchs et la construction du tableau de classement. Nous avons utilisé Morphia afin de conserver une approche objet au niveau de notre code Java. Nous utilisions Spring ensuite pour sérialiser ces données en JSON au travers de webservices directement exploitable par les frontend par requêtes Ajax.

Nos outils

Personnellement, je travaille sous Ubuntu. Nous avons utiliser Eclipse et essentiellement Chrome couplé à ses outils de développement pour le développement des interfaces Web. J’ai apprécié l’iPad et l’application France Télévision qui permet d’avoir le live sur mon bureau. C’est appréciable de voir que l’interface de notre application se rafraîchis plus vite que la plupart des sites Web en ligne publiant les résultats de Roland Garros.

Conclusion

Au final, développer une application HbbTV demande surtout d’être en contact avec les constructeurs et d’être alaise techniquement en dehors des technologies Web. En interne, nous utilisions une carte de diffusion (Dektec) ainsi que la solution bien connu dans le milieu : OpenCaster. Heureusement que Karl s’y connait bien  Sans lui ça aurait été difficile !

A noté que Wiztivi a également développé l’application HbbTV pour NRJ12. De mon coté, le prochain article sur la thématique TV parlera de Google TV mais je suis de près aussi Apple TV.

Note : je préfère travaillé avec le paquet 10gen qui est celui qui est le plus à jour. Vous trouverez la procédure d’installation ici.

$ mongo --version

MongoDB shell version: 1.8.2

On commence par mettre en place la réplication

Afin d’assurer la redondance et la haute disponibilité, MongoDB possède une fonctionnalité appelée « replica set » qui permet aux données d’être dupliquées de manière transparente pour le développeur. Le concept est de créer un groupe de serveur (set) qui possédera un nœud principal (primary) et n serveurs de backup (secondary). Si a un moment donné le nœud principal est inopérant, automatiquement l’un des serveurs de backup deviendra serveur primaire.

On commence par arrêter le daemon :

# /etc/init.d/mongodb stop

Puis on crée les dossiers où seront stockées les bases :

# mkdir /data/r0
# mkdir /data/r1
# mkdir /data/r2

Puis on lance les instances :

# mongod --port 27017 --dbpath /data/r0 --replSet foo
# mongod --port 27018 --dbpath /data/r1 --replSet foo
# mongod --port 27019 --dbpath /data/r2 --replSet foo

Ici, on a appelé notre replica set « foo ». Libre à vous de l’appeler comme vous voulez et de mettre autant de serveurs que souhaité.

Ensuite on va configurer le replica set. On se connecte :

$ mongo

Puis on écris notre configuration :

> cfg = {
_id : "foo",
members : [
{ _id : 0, host : "localhost:27017"},
{ _id : 1, host : "localhost:27018"},
{ _id : 2, host : "localhost:27019"},
] }

Et on initialise :

> rs.initiate(cfg)
{
"info" : "Config now saved locally. Should come online in about a minute.",
"ok" : 1
}

Après quelques secondes, l’invite changera lorsque vous taperez « entrée » :

foo:PRIMARY>

C’est bon : La réplication est active. A partir de maintenant vous pouvez connecter votre application sur l’instance MongoDB lancée sur le port 27017. Les données en insertions seront automatiquement répliquées sur les autres instances. Cependant, le failover n’est pas encore en place. Même si on constate que l’élection automatique du master est en place, notre application ne peut pas basculer seule d’une instance vers une autre.

Nous allons donc utiliser le sharding pour y parvenir de manière transparente pour l’application.

Mise en place du sharding

Une infrastructure typique MongoDB consiste en plusieurs replica set ainsi que de plusieurs instances mongo dédiées à la configuration du sharding. Enfin, il faudra également une instance mongos par serveur d’application. Mongos n’est ni plus ni plus ni moins qu’un loadbalancer servant de point d’entrée/sortie pour les applications.

Pour le vocabulaire, chaque replica set est aussi appelé shard_n. Le sharding consiste en une distribution du stockage des données sur les différentes instances Mongo au sein de ce shard. Chaque machine stock donc un sous ensemble des données. Souvent, c’est la clef (id) de chaque document qui permet de définir le serveur qui stockera l’information.

Concrètement, il nous faudra simplement arrêter nos trois instances et leur rajouter le paramètre suivant permettant d’activer le sharding :

--shardsvr

Ensuite, on lance nos serveurs de configuration :

# mkdir /data/configdb0
# mkdir /data/configdb1
# mkdir /data/configdb2
# mongod --port 27020 --configsvr --dbpath /data/configdb0
# mongod --port 27021 --configsvr --dbpath /data/configdb1
# mongod --port 27022 --configsvr --dbpath /data/configdb2

C’est ce serveur qui va stocker les informations utiles au bon fonctionnement du sharding. On lance ensuite le routeur :

# mongos --port 27023 --configdb localhost:27020,localhost:27021,localhost:27022

puis on se connecte sur le routeur :

$ mongo --port 27023

Puis on ajoute les nœud au shard :

> use admin
> db.runCommand({addshard : "foo/localhost:27017,localhost:27018,localhost:27019"})

Vous noterez la syntaxe particulière qui commence par le nom du replica set (foo) suivi d’un slash et de la liste des serveurs. Si tout c’est bien passé vous devriez avoir ce message :

{ "shardAdded" : "foo", "ok" : 1 }

Testons notre infrastructure

Par défaut, le sharding n’est pas activé. On peut l’activer au niveau d’une base de donnée ou bien au niveau d’une collection. Ici nous activons le sharding sur toute la base de données.

> db.runCommand({enablesharding: "test"})

Puis nous définissons la clef à utiliser pour le sharding :

> db.runCommand({shardcollection: "test.hits", key:{"_id":1}})

On va commencer par charger un peu en données. J’ai pris ici l’exemple de hits de statistiques
> use test
> for(i=0;i<1000000;i++) {
db.hits.insert({tag: "search", ctx : ["blah"] });
db.hits.insert({tag: "video", ctx : [parseInt(Math.random() * 100), "play"] });
db.hits.insert({tag: "video", ctx : [parseInt(Math.random() * 1000), "play"] });
}

On insère donc 3 millions de hits en base avec notamment des tags « video » dont l’identifiant est le premier élément du tableau de contexte (ctx). L’insertion va prendre quelques minutes et on pourra observer l’utilisation des ressources. On s’aperçoit que les traitement sont bien paralléliser et que l’utilisation mémoire est constante

Une fois fini on peut constater que les différentes bases MongoDB utilisent 14Go. Attention : MongoDB pré-alloue les fichiers de stockage : 64Mo, 128Mo, 256Mo, 512Mo etc. jusqu’à créer des fichiers de 2Go. Les explications ici.

 On peut avoir les statistiques de la collection :

> db.hits.stats()

Conclusion

La mise en place du sharding et de la réplication est assez simple. Ainsi on peut rapidement mettre en place une infrastructure fiable. Pour augmenter la capacité de montée en charge il suffira d’ajouter des des réplica set au shard. MongoDB s’occupera automatiquement de répartir le stockage des données et l’exécution des différentes requêtes. Pour augmenter la fiabilité, on pourra également augmenter le nombre de noeud dans chaque replica set. Dans un prochain article je montrerais l’utilisation de map reduce.

Pour appuyer ce discours, on a eu le droit à une démo en live. Dans le désordre, nous avons eu des explication création d’un formulaire avec binding vers un objet, mise en place d’Hibernate, internationalisation avec i18n, validation de formulaire, redirections… et pour finir : les tests !

Le public était conquis. Cela montre que Play! commence à devenir une solution de plus en plus connue et de plus en plus acceptée et utilisée. C’est de bon augure pour les projets Web et surtout pour les projets d’entreprise. Trop souvent JEE est préféré encore aujourd’hui et cela pour des résultats souvent mitigés…

Guillaume nous a aussi présenté brièvement l’avenir proche de Play! avec la sortie de la 1.2 release candidate dans les prochains jours. Il en a profité également pour nous rassurer sur l’avenir de Play! : le framework a atteint sa maturité et il ne devrait plus y avoir de grands changements à l’avenir : Keep It Simple ! Et ça, ça fait plaisir Pour résumer, voici les nouvelles fonctions de la prochaine version:

• Meilleur support des requêtes asynchrones dans le nouveau package play.libs.F (promises, continuations, WebSockets, streaming…)
• Gestion des dépendances avec intégration de Ivy via un fichier de configuration dependency.yml
• Passage à la base de donnée H2 pour les modes mem et fs avec en bonus l’accès à une interface d’administration sur http://localhost:9000/@db

Bien sûr comme à chaque release, le framework gagne en performance et en stabilité. Pour rappel, il est possible de suivre la roadmap du projet.

Le blog sur lequel j’écris possède donc le strict nécessaire: publication d’articles, commentaires et flux RSS. A l’avenir viendront s’ajouter la gestion des tags et un workflow de publication plus élaboré (brouillon, auteur, gestion multi-langue) ainsi que l’hébergement d’images (dans le cloud). Une version mobile et TV seront également de la partie.

Pour faire (très) court, il s’agit d’un framework Java (non J2EE) apportant tout le nécessaire pour développer des applications Web selon le modèle MVC. Sa grande force est d’augmenter la productivité du développeur s’appuyant sur REST pour bâtir des applications stateless réellement scalable et a maintenabilité augmentée. Je l’utilise dès que j’en ai l’opportunité.

Petite note aux courageux qui auront lu le billet jusqu’au bout, je serais présent à la soirée Play! framework organisé par le JUG de Nantes le jeudi 31 mars prochain. Elle sera présenté par l’auteur du framework, Guillaume Bort. Venez nombreux!