Lorsque XMLHttpRequest a été implémenté dans nos navigateurs, ce fut une petite révolution pour le web. Nous pouvions désormais échanger des données avec le serveur de manière asynchrone sans recharger toute la page courante. Cette technique baptisée AJAX (sauf si vous avez hiberné les 10 dernières années, vous devez connaître) a permis d’améliorer les performances web et le confort d’utilisation. Avec HTML5, de nouvelles fonctionnalités sont disponibles dans nos navigateurs. Voyons celles qui vont nous permettre d’améliorer les performances web front-end.
(Lire la suite…)

Contexte

SQLFire est une base de données relationnelle « in memory », c’est-à-dire qu’à tout instant ses données sont disponibles en mémoire vive. Les performances attendues sont donc très élevées, mais ce choix impose une limite sur le volume de données que peut stocker efficacement une instance (hors overflow sur le disque).

Pour franchir cette limite, pour permettre un failover en cas de panne matérielle et pour pouvoir monter en puissance, les concepteurs de SQLFire ont choisi d’encourager les développeurs à partitionner et répliquer leurs données sur plusieurs machines, toutes connectées sur un réseau local.

L’architecture choisie est de type share nothing, ce qui a des conséquences intéressantes à la fois pour le développeur et pour les performances. Ce deuxième article va présenter le mécanisme de partitionnement de SQLFire, proposer une méthodologie pour adapter le modèle de données, et discuter les conséquences des choix d’architecture de la solution.

(Lire la suite…)

Les applications et sites web deviennent de plus en plus riches, la quantité et la taille des fichiers ne cessent d’augmenter. Les téléchargements et traitements effectués par le navigateur sont importants et peuvent fortement influer sur les performances de l’application web. La performance est essentielle, un élément à ne pas négliger si l’on ne veut pas voir son application rejetée par les utilisateurs. Je ne vais pas ici vous donner des techniques d’améliorations des performances mais vous parler des indicateurs à mesurer et analyser afin de coller au plus près de ce que perçoit l’utilisateur.
(Lire la suite…)

“L’ergonomie n’est plus négociable aujourd’hui”. OCTO Technology

L’aspect incontournable de la performance

Il existe une conviction partagée chez les grands du Web : la performance perçue par l’utilisateur est critique. Cette performance a en effet un impact direct sur l’adoption du service et son utilisation dans la durée. Et le ressenti utilisateur est directement lié à la rapidité d’affichage des interfaces.

Le grand public se moque bien de l’architecture logicielle, de la puissance des serveurs, de la latence réseau provoquée par l’appel à des Web services… Tout ce qui lui importe, c’est l’impression de fluidité dans l’usage.

(Lire la suite…)

À ChooseYourBoss on développe une appli web tout ce qu’il y a de plus classique : HTML5, JS, CSS3 + quelques API (Linkedn, Viadeo, Google Maps, Google Analytics, etc). Côté serveur on est en Rails sur Heroku. Bref, rien d’exceptionnel quoi.

Puis un jour, on a jeté un œil sur le graphe de temps de chargement de notre appli – merci Google Analytics. Et là le drame : une moyenne de plus de 5 secondes pour la page d’accueil, et je ne vous parle pas sur mobile. On se dépêche alors d’aller faire un petit tour sur Google Pagespeed, notre score : 44/100 (bof bof).

On décide d’investiguer point par point nos hypothèses, en voici un résumé.
(Lire la suite…)

Une démarche naïve de réalisation de tests de performance est d’effectuer des améliorations successives sur un système donné, donc d’avoir un processus pseudo-itératif. Donc, pourquoi ne pas se baser sur les processus développés dans les méthogologie Agiles, voir même d’utiliser les cycles d’améliorations continues issue du Lean.

En effet, on peut très facilement se rapprocher de la roue de Deming, appelée plus communément la démarche PDCA : Plan, Do, Check, Act.

Le but des tests de charge est de trouver les points faibles d’une architecture dans le but de l’améliorer : performance, stabilité sous charge, coût, etc. On rapproche donc les étapes du PDCA avec un processus de tests de charge :

• Le P (ou plan) a pour but d’établir, préparer et de planifier un plan d’action. Que doivent mesurer, améliorer nos tests pour cette itération.
• Le D (ou do) est la phase de faire, celle où on effectue les tests à proprement parler.
• Le C (ou check) est le moment où l’on vérifie les résultats renvoyés par nos tests. C’est aussi dans cette phase que l’on se préoccupe du rapprochement et de l’agrégation des métriques recueillies dans la phase précédente.
• Le A (ou act) sert à améliorer le système que l’on test. C’est la phase d’optimisation.

(Lire la suite…)

Nous allons présenter dans cet article le filtre de Bloom, une structure de données méconnue mais appréciée, tant pour sa simplicité d’utilisation que pour les gains de performance qu’elle permet d’apporter.

Elle a été choisie par l’équipe de Google Chrome pour implémenter la fonctionnalité « Safe Browsing » qui protège les utilisateurs contre des attaques de fishing et contre certains types de malware. Avec Safe Browsing, le navigateur effectue une validation avant de commencer le chargement d’une page. Si l’URL en question est identifiée parmi une vaste blacklist, Chrome affiche une alerte à l’utilisateur.

Le stockage de cette blacklist pose problème, à cause de son volume. Un million d’URL représentées de manière classique occuperaient environ 30MB, soit l’équivalent de l’empreinte mémoire totale du navigateur.

Chrome a choisi de représenter cette liste sous la forme d’un filtre de Bloom, ce qui a permis de réduire la consommation mémoire à deux mégas, et de garantir une validation en temps constant.

Cet article va détailler l’implémentation d’un filtre de Bloom, expliquer ses propriétés principales et proposer plusieurs scénarios d’utilisation concrets.

(Lire la suite…)

Dans cet article, nous allons faire le point sur Node, une technologie serveur dont tout le monde parle et qui est devenue, en 2 ans seulement, le 3ème projet le plus suivi sur GitHub derrière Rails et jQuery.

(Lire la suite…)

Récemment un papier d’étude de Google UK a été publié sur la performance des langages de programmation JAVA, Scala, C++ et Go (Loop Recognition in C++/Java/Go/Scala). Dans ce papier, les performances des langages sont comparées sur la base d’un algorithme de recherche de boucles dans un graphe (Algorithme de Tarjan).

Principalement basé sur la performance d’exécution d’instructions séquentielles (boucles), la gestion de la mémoire, le temps de compilation et le nombre de lignes de code écrites cette étude montre que pour arriver à des hautes performances en C++ les optimisations techniques (au niveau du langage) deviennent trop compliquées pour le résultat produit. Comme le dit Robert Hundt :

We find that in regards to performance, C++ wins out by
a large margin. However, it also required the most extensive
tuning efforts, many of which were done at a level of sophistication
that would not be available to the average programmer.

Cependant, cet article a été critiqué sur son use-case peu pertinent et sur la validité des résultats. Quand même, C++ est le ++ fort ! Bien qu’il ait été maladroit, ce cher Robert a soulevé un point très intéressant : la programmation haute performance n’est-elle réservée qu’à une élite de développeur C++ ? Le développeur moyen peut-il espérer développer des applications haute performance ?

(Lire la suite…)

Users really respond to speed

La citation est de Marissa Meyer, VP expérience utilisateur à Google, en 2006.

Pas grand chose n’a changé depuis, si ce n’est qu’on a des chiffres plus précis, et un peu effrayants, sur l’importance de la performance dans les applications web : Quelques points de performance feront la différence entre une expérience réussie et une application perçue négativement par ses utilisateurs.

Ou plutôt si, ce qui a changé c’est que depuis 2006 on ne se contente plus de sites web, les applications web ont envahi les entreprises et leur SI. Il devient donc primordial de faire attention aux spécificités des applications web : On ne traite pas un navigateur comme un client lourd. (Lire la suite…)