Agile Back Front

Il y a 15 ans -

Temps de lecture 7 minutes

Revue de Presse Xebia

Revue de Presse Xebia
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Le coin de la technique

Evènements de notre communauté en France et à l’étranger

Le coin de la technique

invokedynamic vu de l’intérieur

Dans cet article, Charles Nutter, JRuby Core Developper nous présente pourquoi il est nécessaire de mettre à jour le bytecode invokedynamic.
Java nous oblige à typer chaque variable et chaque méthode doit définir une signature statique dont les types sont connus avant le Runtime : Java est un langage ‘statiquement’ typé. Si ce typage fort est une des forces du langage, comment la JVM peut-elle supporter des langages dynamiques ? La rigidité de Java provient, plus de son langage que de son bytecode. C’est ainsi que des langages comme Groovy permettent d’enfreindre certaines règles, par exemple : ne pas définir de types aux variables. Ce n’est pas pour autant que le bytecode va tout nous permettre, certaines règles sont incassables dont celles qui s’appliquent aux invocations de méthodes :

  • Les invocations sont statiquement typées.
  • Les invocations doivent s’effectuer sur des méthodes Java. Il est impossible de remplacer un appel à une méthode par un morceau de code interprété.

À l’origine, la JSR-292 a proposé la mise en place d’un nouveau code invokedynamic permettant l’invocation de méthodes sans signatures typées statiquement, mais rien n’avait été prévu pour modifier dynamiquement la logique d’invocation de la JVM.

Concurrency : past and present

Brian Goetz, auteur du livre ‘Java Concurrency In Practice’, a publié sur InfoQ une vidéo enregistrée lors du QCon 2007 : Concurrency : Past and Present.
Pourquoi est-il plus difficile de développer des applications multithreadées que de parler en lisant son journal ?
Dans cette présentation, Brian tente de répondre à cette question en revenant sur les principales difficultés de la programmation concurrente. Sujet que nous avions également abordé lors d’un article publié cet été sur le sujet : « programmation concurrente : notions fondamentales« . Pour illustrer ces problèmes, Brian revient sur l’histoire de la programmation concurrente et ses différentes approches, avant de donner ses recommandations. À la fin de la vidéo, il présente également les fonctionnalités offertes par d’autres langages comme ErLang et Scala.

Tuning des JVM Websphere 6.1

Giribabu Paramkusham et Ajay Bhalodia, WebSphere Application Server Technical Support, présentent dans JVM Performance Tuning with respect to Garbage Collection(GC) policies for WebSphere Application Server V6.1 part 1 (pdf) les points clef du tuning des JVM pour Websphere. Nous retiendrons :

  • Les JVM IBM proposent quatre stratégies de garbage collections :
         – -Xgcpolicy:optthruput pour minimiser le temps global d’exécution (batch, …).
         – -Xgcpolicy:optavgpause pour minimiser la durée de chaque pause.
         – -Xgcpolicy:gencon destiné aux applications web. L’algorithme Générationnel Concurrent communément utilisé dans les JVM Sun est optimisé pour les objets à courte durée de vie.
         – -Xgcpolicy:subpools pour les serveurs à grand nombre de processeurs (>16).
  • A la différence de l’implémentation GenCon de Sun qui comprend trois zones (Young, Tenurd et Permanent), celle d’IBM n’en comporte que deux (Young et Old)
  • L’option -verbose:gc est activable en production avec un impact négligeable sur les performances et l’option moins connue -Xverbosegclog permet de préciser un fichier de sortie en mode rolling file . Nous noterons que les informations de GC sont désormais formattées en XML ce qui facilitera la manipulation avec des outils.
  • Indépendamment des limites techniques liées au système d’exploitation, les JVM IBM sont optimisées pour utiliser des heap le plus souvent inférieures à 2 GB :
Platform Additional Options Maximum Possible Advised Maximum
AIX automatic 3.25 GB 2.5 GB
Linux 2 GB 1.5 GB
Hugemem Kernel 3 GB 2.5 GB
Windows 1.8 GB 1.5 GB
/3GB 1.8 GB 1.8 GB
z/OS 1.7 GB 1.3 GB

source IBM

  • L’utilisation de JVM 64 bits supprime les limites de taille de heap mais pénalisent les performances (plus de données manipulées) et la consommation mémoire (des pointeurs sur 64bits plutôt que 32bits accroissent de 30% à 50% la mémoire consommée)
  • La JVM 6 d’IBM réduit les dégradations de performances et de consommation mémoire en 64bits grâce à l’introduction de « pointeurs compressés »

Performance d’affichage d’une page Web

Hayes Potter, nous présente dans Speed up your website, quick! des règles structurantes afin d’améliorer les performances d’affichage d’une page Web :

  • Compression des ressources statiques (images, fichiers flashs, scripts, …).
  • Mettre en place une politique d’expiration des ressources statiques .
  • Mettre les styles CSS en haut de la page HTML tandis qu’il faut mettre les fichiers Javascript en bas de la page.
  • Limiter les requêtes http://request vers d’autres domaines. En effet à chaque requête vers un autre domaine, pendant le chargement de la page, une résolution DNS est effectué (accès réseaux supplémentaires).

Dans le même esprit, Yahoo a mis à dispositon de la communauté des développeurs Web un ensemble de règles : Exceptional Performances.
Il y a 34 Best Pratices répartis dans 7 domaines différents :

  • Contenu
  • Serveur
  • Cookie
  • CSS
  • Javascript
  • Image
  • Mobile

Voici les règles les plus marquantes :

  • Externaliser les fichiers CSS et Javascripts de la page HTML.
  • Réduire la taille des fichiers Javascripts en éliminant les caractères superflus (espace, variable à rallonge, …). Cela peut être assisté par des outils tel que JSMin et YUI Compressor. L’idéal c’est que les développeurs des pages gardent des fichiers Javascripts lisibles et maintenables puis au déploiement de ces pages, passer une moulinette sur les fichiers Javascripts afin d’épurer les caractères superflus.
  • Eviter la duplication des importations du même script, par exemple IE retéléchargera plusieurs le fichier bien que c’est la même ressource.
  • Utiliser une requête HTTP GET pour les requêtes AJAX.
  • Rassembler l’ensemble de vos images (pour les gestions des boutons par exemple) en une seule image et en faire un sprite avec CSS. Cette tache peut être assister par les outils CSS Sprites et Website Performance CSS Sprite Generator.
  • Limiter l’utilisation des iframe.

Références :

Voici une liste d’outils facilitant la mise en oeuvre et la vérification de ces points :

Evènements de notre communauté en France et à l’étranger

Refactoring itératif de conférences : JavaPolis, Javoxx et DeVox

Terminons cette revue de presse par la petite histoire belge de la semaine. L’un des plus gros événements Java au monde JavaPolis vient de changer de nom pour la seconde fois cette année. Renommé Javoox en début d’année, il semblerait que cet ancien nouveau nom soit encore trop proche de « Java » pour Sun. Avec ce nouveau nom : DeVoxx, le BeJug (porteur de l’événement) continue le bras de fer avec Sun en osant mettre un ‘V’ en 3e caractère de leur nouveau nom … tout comme dans ‘jaVa’ … La newsletter de DeVoxx nous explique que ce nouveau changement de nom est dû à une volonté de rester un événement Java indépendant.

Published by

Publié par Publicis Sapient Engineering

Commentaire

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.

REJOIGNEZ-NOUS