Changement de fil

C'est la fin de ce blog sous Blogspot.

Il ne s'arrête pas vraiment puisqu'il continue sous Wordpress à cette adresse http://cfalguiere.wordpress.com/.

Mon nouvel article est là. Tous les agrégateurs n'ayant pas encore été mis à jour, je continue à poster les liens ici.


Pourquoi j'ai changé ?

Je n'ai pas de grief particulier contre Blogspot.

C'est simple à prendre en main donc pratique quand on se lance. Un inconvénient majeur pour moi est que les reformatages automatiques de texte ne permettent pas de mettre du code dans les posts, en particulier dès qu'il y du XML. Or vu la nature du blog, c'est un peu pénible. J'ai contourné le problème avec des images et puis au bout d'un moment j'ai cherché autre chose.

Une autre raison de passer sous Wordpress est que je participe aussi à deux autre blogs, Valtech et Duchess France et ces blogs sont sous Wordpress. C'est plus cohérent, et ça passe mieux dans les agrégateurs.

Wordpress est un peu plus compliqué à prendre en main au départ, mais plus puissant.


18 mois, le temps d'apprendre à marcher ...

Ce blog a duré environ 18 mois ici de Juin 2008 à début 2010 avec 14 articles, et presque autant de brouillons que je n'ai jamais eu le temps de finaliser.

Je continue ailleurs et j'espère que ceux (et celles) qui ont apprécié mes articles me suivront en adaptant leurs bookmarks et leurs flux.

J'ai repris l'essentiel du contenu dans le nouveau blog.
http://cfalguiere.wordpress.com/ pour la suite de cette aventure ...

Sonar against a non-maven multi-modules project

I’ve explained a few monthes ago how to run Sonar against a non-maven project.

The workaround is to create a POM with an explicit source directory and set the Sonar property sonar.dynamicAnalysis to false.

What if the project has many source folders ?

The article is posted here


.

Retour d'expérience YSlow et Page Speed

J'ai beaucoup utilisé YSlow ces temps ci, en particulier parce pour la première fois j'ai reçu des exigences de performance incluant le grade YSlow.

Je ne reviendrai pas sur la présentation de ces deux outils. Il existe de nombreux commentaires listant la mise en oeuvre et décrivant les règles.

• Yahoo's YSlow
• Google's Page Speed
  

Je voudrais simplement faire un retour d'expérience sur YSlow et Page Speed. C'est un retour QA plus que développeur, car j'interviens sur un projet dans la phase d'optimisation juste avant les tests de performance.

Les deux sont des plugins Firebug et s'installent très facilement. Ils apparaissent ensuite comme onglets dans Firebug. Bien sûr, l'utilisation de Firebug implique que l'application tourne sur Firefox. Pour IE, il existe AOL Page Test, que je n'ai pas testé, vu qu'il a obstinément refusé de fonctionner.

Même s'ils apparaissent très similaires et sont basés en gros sur les mêmes Best Practices, les deux outils ne sont pas positionnés de la même manière.



YSlow

YSlow facilite la communication sur les performances :

• Le grade général permet d'avoir une appréciation globale du niveau de performance, et par conséquent de communiquer sur l'évolution de ce niveau
• Un rapport HTML peut être généré très facilement et diffusé
• Ces rapports peuvent aussi être stockés pour comparer les résultats dans le temps
  

YSlow a permis de déterminer rapidement le besoin de configurer les modules Apache mod_expires et mod_deflate.
Une fois cette opération faite YSlow a permis de vérifier facilement que les dates d'expiration de cache sont maintenant correctes et que les contenus sont compressés.

En revanche, YSlow est assez général sur les recommandations. La règle a appliquer est présentée de manière très claire mais elle n'est pas appliquée au cas particulier. La conséquence est qu'il faut plus d'effort pour estimer le gain que l'on peut espérer de la correction et donc motiver une correction rapide.

C'est là qu'intervient Page Speed.



Page Speed

Page Speed fourni un état très complet, des propositions de correction et une évaluation du gain. Je ne suis pas vraiment la cible car je ne développe pas les pages sur ce projet. Il m'a tout de même servi pour plusieurs choses :

• Evaluer la minification des JavaScripts : le gain de la minification des JavaScript est de 150Ko par page sur les pages testées et une action pour mettre en place Dojo's ShrinkSafe est "rentable". Or cet outil est disponible mais personne n'a jamais eu le temps d'insérer le script dans le build
• inspecter les headers facilement : Les pages sont en HTTPS et les headers ne sont pas disponibles dans Fiddler. L'onglet resources de Page Speed affiche les headers requête et réponse et le texte ou contenu de chaque resource.
  
• "Smusher" les images : YSlow fournit aussi ce service mais en passant les URLs des images au site smushit.com. Or le site en développement n'est pas accessible depuis Internet. Page Speed génère automatiquement la version "smushée" de chaque image. Cela a permis de traiter rapidement 5 images sur lesquelles il y avait un gain de plus de 1Ko.
  
• Evaluer le CSS : constater que certaines maladresses sur le CSS sont classées "très mauvais" et nécessitent une action.
  

Avant de conclure, quelques conseils tirés de mon expérience YSlow.



Les jeux de règles YSlow

YSlow permet de créer des jeux de règles spécifiques. C'est utile lorsque certaines règles ne sont pas applicables :

• Le support des navigateurs interdit la mise en oeuvre de certaines règles
• L'application n'est pas dans un environnement permettant l'évaluation de la règle. C'est le cas en particulier de la règle "Use a CDN"souvent difficile à vérifier en développement (un CDN est un Content Delivery Network, c'est à dire un service de cache tel qu'Akamaï ou Limelight)

Les jeux de règles sont accessibles via le bouton Edit à côté du nom de règle.

• Une fois définies les règles via les cases à cocher, sauvez le ruleset. Il apparaitra dans les Custom Sets sur la gauche
• Redémarrez Firefox ! : les mises à jour ne sont sauvées qu'au moment de l'arrêt de Firefox. J'ai refait le ruleset 2 ou 3 fois suite à des plantages Firefox ;-)
  

La gestion du cache

YSlow se base sur le comportement de Firefox. Il est important que tous les contenus soient rechargés pour que leur statut soit mis à jour.

C'est particulièrement visible sur les dates de cache :

• Juste après la mise en place des directives pour mod_expires, les données sont affichées à jour. La date est dans plus de 48h et satisfait la règles "Add expire headers".
  
• Le lendemain, la règle est violée car la date d'expiration n'étant pas atteinte Firefox n'a pas rechargé les contenus statiques. Et les contenus en cache sont maintenant valides pour moins de 48h.
• Forcer le rechargement marche dans une certaine mesure, mais n'agit pas sur toutes les ressources. Le plus fiable est de vider le cache pour avoir les fichiers à jour.
  

En conclusion

Les deux outils sont très utiles pour améliorer la qualité des pages Web.

• YSlow s'adresse plutôt aux personnes qui valident l'application et au suivi qualité
  
• Page Speed est plutôt destiné aux développeurs qui vont optimiser les pages.

Posts similaires :

• Velocity 2009
  

R

I discovered R a few month ago, and it's exactly the tool I was looking for to perform Exploratory Data Analysis on IT data (analyse of monitoring data, logs, performance tests results, workload analysis, code checks).

I used to do all that computation with Excell or ad hoc Java programs. Excell is great for small amounts of data, but when it comes to analyse 300000 lines of result, they won't fit in Excell (at least before Excell 2007).

R let me write scripts to compute statistics that I can run on data every day or when the test session ends with a minimum of manipulations. They are also easy to adapt when need be.

The rabbit is done with R as an illustration of 3D capabilities. I've found it at the R Graph Gallery. This site worth visiting to discover R graphic capabilities. I like R graphics. They are really neat and configurable. R comes with plots and histograms, very handly functions to convert data to graphics and advanced visualization features.

When I decided to write a post on R I balanced between a brief "WoW!" and a long run tutorial with all the nice things in R. As I'm to lazy to write a definitive tutorial on R, I decided to write a mind map and organize things I know about R up to now. I've also set up a pageflake with usefull links and blogs feeds.

R mind map

R pageflake

Please feel free to comment the mind map or pageflake as comments to that blogs. I'am new to R and may have make mistakes or ignored usefull resources.

.

Appeler Curl depuis un program Python 3.1

Curl (un client HTTP en ligne de commande) est très pratique à utiliser pour tester manuellement les requêtes Rest. Il permet en particulier de manipuler les headers ou les méthodes HTTP.

Par exemple :

# envoi des données en JSON en paramétrant le header
curl -i -H 'Content-Type: application/json'
-d '{"items":[{"title": "AAA AAA", "description": "aaa aaa aaa",
"link": "http:AAA.com"}]}'  http://${SERVER}/rest/messages

# suppression du message avec la methode DELETE
curl -X DELETE http://${SERVER}/rest/messages/1

J'ai fait un petit programme Python pour faciliter la construction des différentes requêtes Rest. Le programme Python permet de sélectionner le server GAE local/remote, le type d'opération, le variant pour l'input, l'output demandé et saisir les données à envoyer.

Appeler Curl m'a posé quelques problèmes.
Pycurl (une intégration curl/python) n'existe pas pour python 3.1. J'ai donc implémenté les appels de commande externes directement en Python. Mais j'ai eu un peu de mal à trouver les informations car les I/O Python ont pas mal changées au cours du temps. Voici le code qui permet d'appeler une commande et récupérer la sortie standard en Python 3.1.


On utilise Popen du module subprocess. La méthode communicate() crée un tableau où 0 contient la sortie standard et 1 la sortie erreur.
Si vous voulez rediriger la sortie erreur sur la sortie standard, utilisez stderr=STDOUT.
Pour une raison qui m'échappe le passage de la commande en tableau a cessé de fonctionner, mais la concaténation de chaînes à résolu ce problème.

Sur Velocity 2009

Enfin des choses qui bougent sur le thème performance ...

La conférence Velocity "Web Performance and Operations Conference" s'est tenue du 22 au 24 juin à San Jose, CA.

On y trouvait des représentants des plus gros sites Web (Facebook, Google, Microsoft, Twitter, Yahoo, etc) réunis pour discuter des problématiques d'exploitation et souvent de performance de leurs sites.

Je n'y étais malheureusement pas mais fort heureusement beaucoup de présentations et même des vidéos de sessions sont en ligne.




Brooks Elliott

Qu'est ce qui ressort ?

Tout d'abord, ces sites sont tous des sites commerciaux, très fréquentés où les performances sont nécessairement un enjeu. D'ailleurs Performance n'a pas toujours le même sens selon les interventions : il peut signifier ROI, expérience de l'utilisateur ou efficacité technique.

D'une manière générale, les participants constatent que dans les applications "Web 2.0"/AJAX les problèmes de performance perçue proviennent pour une bonne part de la restitution dans le navigateur (environ 50% du temps total). La plupart des outils cités sont des outils d'analyse du comportement sur le poste client et d'optimisation du Web design.

Je ne pense pas qu'ils aient ignoré la partie serveur (on voit passer par ci par là des outils plus classiques), mais il existe déjà des outils pour la partie réseau/serveur et le sujet est peu à même de déplacer les foules. Ils sont inclus dans le mantra le mantra "mesurer, mesurer, mesurer, visualiser et analyser les données pour comprendre le problème" que l'on retrouve un peu partout. Juste pour préciser au cas où, mesurer la production.

Bien qu'Agile cela n'apparaisse pas directement, on sent que le développement de la plupart de ces application est Agile (résolutions itératives des problèmes, rythme rapide des mises à jour en particulier). On voit donc l'envers du décor, quand les projets sont livrés pour être exploités et ne marchent pas forcément aussi bien que l'on souhaiterait. Les solutions sont souvent différentes de celles qu'on rencontre dans des secteurs plus classiques. En particulier ce sont plus souvent des solutions mixant l'infrastructure et le développement de l'application (travail sur les caches et les proxies à différent niveaux de l'infrastructure par exemple).




Darren Hester

Mesurer, mesurer, mesurer et comprendre

Tout d'abord une session avec un titre interminable
The User and Business Impact of Server Delays, Additional Bytes, and HTTP Chunking in Web Search de Eric Schurman (Microsoft) et Jake Brutlag (Google) qui présentent les résultats de tests utilisateurs qu'ils ont menés sur leurs moteurs de recherche. C'est intéressant et assez abordable. Prenez le temps de regarder la vidéos car les slides seuls sont assez laconiques.

Ils ont dans les deux cas appliqués la méthodologie A/B Testing (ou Split A/B Testing) utilisée habituellement en marketing pour choisir entre différents designs. L'A/B Testing utilise dans l'arrière boutique des méthodes statistiques de tests d'hypothèses basées sur des comparaisons de séries (variante de test de Khi2 type GTest, ZTest). Il nécessite une infrastructure qui permet de servir différentes versions du site à différents utilisateurs et de collecter les mesures.

La page Wikipedia sur A/B testing est un peu jargon. Vous trouverez sur ces deux pages des explications destinées au marketing plus faciles à appréhender dans le contexte :

• Test AB (AB Testing) (en français)
• An Introduction to A/B Testing (un peu plus détaillée mais en anglais)
• et un exemple chez Google Google Website Optimizer; un service de A/B testing gratuit

En l'occurrence, ils ont soumis les utilisateurs a des versions de site plus ou moins lentes, ou dont les pages ont été refactorées selon diverses techniques pour mesurer l'impact sur l'usage et donc les revenus du site. Les constats sont que les utilisateurs commencent à percevoir l'attente à partir de 500ms mais aussi qu'ils ne sont pas impactés de la même manière selon la façon dont s'affiche la page.

On trouve un peu plus de détails l'utilisation de l'A/B Testing et d'autres moyens utilisés dans la présentation Performance-Based Design - Linking Performance to Business Metrics de Aladdin Nassar (Microsoft - Hotmail) et une moisson de sigles aussi : PBD Performance Based Design, RPI Relative Performance Index, PLT (ah non celui là c'est juste Page Load Time). C'est aussi en vidéo.

Philip Dixon (Shopzilla) dans Shopzilla's Site Redo - You Get What You Measure fait un retour d'expérience sur la refonte complète de leur site. Peu technique mais intéressant quand même pour les problématiques et le vécu. C'est aussi en vidéo.





aussiegall

Les outils

Pas de bon artisan sans de bons outils.
Plusieurs présentations ont été consacrées à des outils d'analyse dans le client :

Performance Tools par Eric Goldsmith (AOL), Simon Perkins (Simtec Limited), Stoyan Stefanov (Yahoo! Inc), Jim Pierson (Microsoft), Jan Odvarko (Freelance). Attention il y a deux présentations attachées :

• Performance Tools Presentation [ZIP] sur Page Test d'AOL
• Performance Tools Presentation 1 [PPTX] sur VRTA de Microsoft

Page Speed par Bryan McQuade (Google), Richard Rabbat (Google, Inc.) sur Google Page Speed.

Jiffy, une extension Firefox pour analyser le temps de réponse dans la partie client par Scott Ruthfield de Rooster Park Consulting.





geishaboy500

Optimiser le Web Design

Maintenant qu'on a compris d'où vient le problème, il faut lui trouver une solution.

Julien Lecomte (Yahoo!) présente dans High-performance Ajax Applications diverses techniques pour améliorer les temps de réponse du JavaScript. Attention c'est très technique et nécessite une bonne connaissance du développement JavaScript.

Si vous n'êtes pas un expert JavaScript vous préfèrerez probablement la présentation plus pédagogique de Douglas Crockford (Yahoo!) Ajax Performance.

Si vous n'en avez pas assez :

• Une autre présentation d'optimisations JavaScript Writing Efficient JavaScript de Nicholas Zakas (Yahoo!),
• ou Steve Souders (Google) présente ses 14 règles et analyse l'impact de plusieurs techniques en JavaScript et CSS dans Website Performance Analysis,
• ou Dave Artz (AOL) The Secret Weapons of the AOL Optimization Team,
• ou Frontend Performance Engineering in Facebook par David Wei (Facebook Inc.), Changhao Jiang (Facebook Inc.).

Go with the Reflow de Lindsey Simon (Google) est une présentation très spécifiquement sur le reflow en Javascript, c'est à dire le repositionnement des objects graphiques dans la page. Ce comportement du navigateur est cause d'un certain nombre de ralentissement dans le client.

Une très belle présentation sur CSS de Nicole Sullivan (Consultant) The Fast and the Fabulous: 9 ways engineering and design come together to make your site slow.

Et pour finir avec le Web design, Stoyan Stefanov (Yahoo!) présente dans Image Optimization: How Many of These 7 Mistakes Are You Making divers outils et techniques qui permettent d'améliorer le poids des images dans les pages Web.





ecstaticist

Rails

La présentation sur Twitter est particulièrement intéressante pour ceux qui s'intéressent à Rails. Fixing Twitter: Improving the Performance and Scalability of the World's Most Popular Micro-blogging Site par John Adams (Twitter) présente l'architecture, le reporting et le process de déploiement mis en place, les techniques de cache mises en oeuvre. C'est aussi en vidéo.





hounddiggity

Deployer

Passons un peu du coté de nos amis (si, si) de la production.

Une présentation très sympa sur les rapports devs/ops de John Allspaw & Paul Hammond (Yahoo!) 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr et la nécessité d'un respect mutuel pour faciliter les déploiements fréquents et rapides.

Pourquoi il ne faut pas compter sur l'administrateur Apache pour vous améliorer tout ça d'un coup de zip : Beyond Gzipping de Tony Gentilcore (Google) montre que la compression des flux n'est pas une panacée car 15% des utilisateurs ont quand même des réponses non compressées. Le problème est dû aux firewalls et proxies qui altèrent les headers HTTP.

Scalable Internet Architectures par Theo Schlossnagle (OmniTI) présente quelques slides intéressants sur les pratiques de cache et de partitionnement/sharding de base de données.

Introduction to Managed Infrastructure with Puppet présente l'outil de configuration management Puppet pour le déploiement d'application distribuées.





Chocolate Tools par JanneM

Les outils cités

J'ai regroupé ici divers outils cités dans ces présentations ou d'autres que je n'ai pas reportées.

JavaScript/DOM

• HttpWatch analyse/profilage poste client, adon IE et Firefox (commercial)
• PageTest analyse/profilage poste client, addon IE (AOL, opensource)
  
• Jiffy analyse/profilage poste client, addon Firefox
  
• Visual Round Trip Analyzer analyse/profilage poste client, add on IE (Microsoft, free)
• Page Speed analyse/profilage/suggestions sur poste client, add-on Firebug (Google, opensource)
  
• YSlow analyse de page Web - addon Firebug (Yahoo!, gratuit)
  
• Firebug analyse/debug poste client - addon Firefox (opensource)
• MSFast analyse/debug addon IE (opensource)
• JSLint.com service en ligne d'analyse de code JavaScript
  
• Cuzillion générateur de pages de test contenant diverses techniques JavaScript
  

Images

• Smush.it service en ligne d'optimisation d'image
• CSS Sprite Generator service en ligne de génération de CSS sprite à partir de plusieurs images dans le but de limiter le nombre de requêtes HTTP
• SpriteMe idem
• d'autres outils en ligne de commande sont cités dans la présentation Image Optimization
  

Réseau / HTTP

• Fiddler analyse/debug http - addon IE (Microsoft, gratuit)
• Charles HTTP proxy (commercial)
  
• nExpert simulation de connexion réseau de différentes qualités (Windows)
  
• WANSim simulation de connexion réseau de différentes qualités (Linux)
  
• HTTP Analyzer sniffer HTTP Windows
• Varnish cache HTTP
  

Surveillance

• NetMon monitoring réseau Windows (commercial)
• Ganglia surveillance de systèmes distribués Linux (opensource)
• KITE service en ligne de mesure de performance sur les postes clients Web et RIA (Keynote, commercial avec un mode gratuit)
  

Configuration Management

• Puppet configuration management (commercial)

J'en ai probablement ratés quelques uns et je n'ai pas systématiquement noté les outils connus (Squid ou Nagios par exemple) ou les outils système)

A suivre ...

Google et Yahoo! ont lancé chacun leur site pour regrouper les initiatives :

• Google Let's make the web faster
• Yahoo! Exceptional Performance

Running Sonar against a GAE Java project

The GAE SDK generates a project that is not Maven enabled. Namely, source and target directories does not follow Maven conventions.

Sonar may be run against such a project by using Sonar light mode configuration.

• We will write a minimal POM project and instruct Sonar to run only static analysis (code violations, complexity).
• For the time being, we will put dynamic analysis (unit test results and code coverage) aside as it requires code to be executed, therefore dependencies configuration. Sonar may actually report dynamic analysis if surefire and cobertura reports are available.

But let's start with some simple configuration.
You will need Sonar (1.8 minimum) and Maven 2.

• Install Maven
• Install Sonar

Write a POM

Open the Eclipse project generated by GAE SDK and create a pom.xml file at the project's root.

Add your project's information (replace cirrus in the snapshot below by your project's information)

Add GAE build information. You should not have to change these lines.

Add some Sonar configuration to skip dynamic analysis. You should not have to change these lines.

Depending on your repository and mirror, you may have to download sonar jars from the Codehaus repository.

Run Sonar

Now run sonar from the shell command line or configure an Eclipse launcher. As the Sonar maven plugin will send out data to Sonar during the build, the Sonar server must be running.

It may take a while the first time, as maven will download tons of libraries and plugins.

When it's done, Sonar's analysis report is available at http://localhost:9000.

You may find usefull information about Sonar configuration including "Non-Maven" projects in Analyzing Java Projects