PerfUG : Hadoop et HDFS : Stockage, Requêtage et Performances

Hadoop est principalement utilisé pour le monde batch. Le paradigme MapReduce sur Hadoop ne propose pas de transformation ou de requêtage performant mais plutôt un traitement d’une forte volumétrie de données.

Cependant, la performance n’est pas à négliger dans certains cas :

• lorsque la fenêtre de traitement des données devient serrée pour fournir des données à jour

• des besoins de requêtages ponctuels par des analystes peuvent arriver au travers d’outils type Hive ou Pig.

Il devient nécessaire de fournir ces données dans un temps de requêtage supportable à l’échelle humaine.

Cette session permet d’introduire les basiques d’Hadoop et de HDFS ainsi que des astuces de performance sur le stockage, le requêtage (Hive, MapReduce) ainsi que sur du paramétrage.

Le speaker de cette session est Sofian Djamaa, Software Engineer chez Criteo.

Pour le descriptif complet de la séance, suivez le lien.

L’événement aura lieu le Jeudi 24 Avril à 19h. Pour s’inscrire, c’est sur Eventbrite.

OCTO accueille « Web Performance Paris » le jeudi 7 novembre

Nous avons le plaisir d’accueillir le groupe Web Performance Paris, jeudi 7 novembre à partir de 19h, pour une soirée de présentations et d’échange dédiée aux performances web.

Web Performance Paris

Au programme :

(Lire la suite…)

A quoi sert Azul Zing ?

La compagnie Californienne Azul Systems a gagné sa notoriété au travers de son produit phare : la JVM Zing. Cette JVM promet d’excellentes performances pour applications Java de manière déterministe : Zing aura toujours une faible latence pendant toute la durée de vie d’une application en production. La clef de cette machine virtuelle vient de son algorithme sans pause : C4 (Continuously Concurrent Compacting Collector). Les promesses de cette JVM sont-elles réalistes ? A qui cette JVM peut bénéficier et pour quel coût ?

NB : cet article présuppose que vous connaissez les principes du Garbage Collector. Les algorithmes sont détaillés de manière très pédagogue (en anglais) par Martin Thompson dans l’article cité ci-dessous.

(Lire la suite…)

Compte-rendu du Performance User Group #3

OCTO a accueilli jeudi 29 août la session de rentrée du Performance User Group à laquelle 25 personnes ont participé. Ci-dessous le contenu de cette soirée.
(Lire la suite…)

HTML5 pour améliorer la performance web front-end ?

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

NewSQL: Comment distribuer ses données avec SQLFire

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

Mesurez les performances web front-end

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

Les Patterns des Grands du Web – Fluidité de l’expérience l’utilisateur

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

Performance côté client avec Rails & Heroku

À 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 de tests de performance

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