déc
26

J’ai une application Play! en production

Je tenais à faire un article sur un sujet bien précis qui reflète un retour d’expérience sur le déploiement d’applications Play! Framework en production. Je vais prendre l’exemple de ce site Web e-commerce : www.labottegardiane.com que j’ai développé from scratch à l’aide de Play! framework et jQuery en 2009 pour le compte d’un de mes clients. Il a été mis en production fin 2009, soit il y a plus de deux ans à l’écriture de cet article et ce sur un serveur Gandi. Il faut savoir qu’à l’époque c’était « osé » car l’offre ne proposait que des parts de 0,5 CPU et 128Mo de mémoire vive. Ces quota ont été doublé pour une part seule depuis mais la puissance disponible reste malgré tout un peu juste pour déployer du Java.

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… :-)

 

mar
31

Résumé : Play! Framework au JUG de Nantes

Le jeudi 31 mars a eu lieu à La Cantine Numérique de Nantes une conférence menée avec brio (comme d’habitude :-) ) par le créateur du Play! Framework : Guillaume Bort. Cet article dresse un résumé de la soirée pour ceux qui n’ont pas eu la chance d’être parmi nous. La salle était pleine et pas mal de monde ont eu dû rester debout (dommage que la Cantine n’est pas de salle plus grande). L’ambiance était très studieuse malgré quelques questions mal posées par certains mais rapidement taclées en touche avec humour par notre orateur !

Guillaume a commencé par nous a présenter Play! framework. En bref, il s’agit d’un framework pour le développement d’applications Web en Java mais en s’affranchissant de l’API servlet et donc en proposant une solution réellement stateless. Au delà d’avoir une architecture propre, cela provoque des effets de bords intéressant dont les principaux restent quand même le grand respect du protocole HTTP (et donc un comportement parfait du navigateur lors d’un back ou d’un refresh sur un formulaire par exemple), le (re)chargement du code à chaud et la précision des logs d’erreurs.

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.

mar
31

Réinventer la roue : blog sur mesure

Cela fait bien longtemps que je n’ai pas écris sur mon blog. L’année 2010 fut chargée et je n’ai eu que peu de temps à consacrer à ce blog et encore moins à l’idée que j’avais en tête: faire un moteur de blog avec mes petites mains. L’objectif affiché est de réinventer la roue. Mais contrairement à mon métier de tout les jours qui impose un certain pragmatisme pour mener à bien des projets réels: ici tout est expérimental. N’ayant ni contrainte de temps ni de cadre technique imposé, je me suis lâché. En revanche, tout est très conventionnel du point de vue fonctionnel. Je m’inspire beaucoup des plateformes Blogger et Eklablog mais également de l’outil WordPress dont la réputation n’est plus à faire.

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.

Concernant la technique, j’ai fait le choix de partir sur des technologies innovantes encore peu utilisées dans le monde de l’entreprise bien que cela devienne de moins en moins vrai maintenant. Pour commencer, l’application est développée avec le framework Play! Il s’agit d’un framework Web sur lequel j’ai déjà écris sur mon ancien blog en 2008. Je reviendrais dessus: il y a beaucoup à dire et de nombreuses nouveautés ont fait leur apparition depuis.

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é.

Pour l’hébergement, j’ai opté pour le cloud computing avec Google App Engine. La grande force de Play! sur ce sujet est de fournir un module GAE apportant une solution clef en main pour déployer n’importe quelle application Play! dans le nuage de la compagnie de Mountain View. Il y a bien quelques contraintes à respecter dont la plus impactante est l’absence de base de données relationnels. En effet, Google nous propose un datastore basé sur sa solution Big Table. J’ai choisis de me baser sur la librairie Siena qui propose une couche ORM implémentant également la solution cloud concurrente SimpleDB d’Amazon. Un module est également disponible pour Play!. Je ferais un article détaillé sur GAE datastore et Siena. La syntaxe est vraiment plaisante et finalement pas si éloignée de l’API que propose Play! (qui ne fait qu’étendre JPA en proposant des méthodes plus intuitives). Google App Engine a également quelques restrictions concernant Java, notamment l’absence de support de la librairie AWT. Cela m’a empêcher dans un premier temps de réutiliser un mécanisme de captcha que j’avais développé pour la validation des commentaires. Finalement pour ce besoin précis, j’ai préférer me baser sur la solution SaaS Disqus et je ne le regrette pas.

Le code source de ce projet est disponible sur la plateforme GitHub. Il est loin d’être parfait mais évoluera à l’avenir et notamment des tests fonctionnels et unitaires seront écrits et une plateforme d’intégration basée sur Jenkins (RIP Hudson) sera mise en place. Si vous avez des questions ou des suggestions, n’hésitez pas à laisser un commentaire.

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!

Go back to top