La conférence « Velocity Europe 2013 » a eu lieu en Novembre 2013. Il est grand temps de faire un petit retour de la deuxième journée de cette conférence. Le thème de cette conférence est la performance web (back, front, système).
La conférence « Velocity Europe 2013 » a eu lieu en Novembre 2013. Il est grand temps de faire un petit retour de la deuxième journée de cette conférence. Le thème de cette conférence est la performance web (back, front, système).
Testing all the way to production par Sam Adams (Lmax exchange)
http://www.youtube.com/watch?v=_cS9QPJ5pIE#t=28
Cette présentation repose sur le fait qu’on doit effectuer des tests pour valider au moins unitairement les développements pour les déploiements. Ainsi, Sam Adams va présenter le workflow de développement qui est basé sur les tests pour déployer du code et en évitant les régressions.
Il utilise l’intégration continue et par du postulat que chaque build peut être et doit être prêt à passer en production (chaque commit doit être fonctionnel). Au vu du contexte de l’entreprise, ils font des déploiements en production toutes les deux semaines, le samedi matin).
Le workflow de déploiement se fait en 4 phases et ce workflow est tout le temps utilisé :
- Avant le commit, il doit y avoir des tests unitaires
- Lors du passage sur « testing », on a une analyse sur le code, et des tests (intégration, unitaire, performance, etc)
- Ensuite viens, le passage sur « staging », qui est ISO prod.
- Et enfin la production, si tout est bon.
Actuellement, il y a plus de 7000 tests automatisés sur leurs applicatifs.
Le but de ce workflow, c’est d’automatiser les déploiements. De cliquer sur un lien et d’ensuite aller boire un café sans se soucier de la mise en production, car c’est testé et on sait que ça marche ! (utopie … 🙂 )
En réalité, la plupart du temps, les mises en production se passent bien mais il peut arriver des problèmes car :
- Les tests ne représentent jamais la production. La production est la production et sera la seule production.
- Il peux avoir des erreurs humaines.
Le meilleur moyen de tester c’est aussi de tester en production. Ce n’est pas des tests fonctionnels ou de performances, mais juste de savoir très rapidement ce qui marche et se focaliser uniquement sur les choses qui ne fonctionnent pas.
Une des solutions quand on développe une nouvelle fonctionnalité c’est d’essayer d’impacter le moins possible le fonctionnel existant : isoler le développement afin de ne pas contaminer le reste.
Afin de tester au mieux l’applicatif et de reproduire au mieux la production, il faut aussi pouvoir la tester avec les données de production et donc permettent à tout le monde de récupérer facilement les données de production.
Petit rappel de cette présentation :
- test, test et test ( et si c’est lourd, il faut les automatiser)
- tout tester
- si il y a un problème sur la production, il y a un problème sur l’intégration continu
- avoir accès simplement aux données de production
Making performance personal at Financial Times labs par Andrew Betts (Financial Times)
http://triblondon.github.io/talk-makingperfpersonal/#/
Le Financial Times sont très actifs concernant les web perfs. Voici ce qu’ils ont mis en place sur leurs sites :
- utilisation de fastClick
- utilisation de manifest
- la non utilisation de plugins tiers comme l’api de facebook, ou l’api de google qui alourdit énormément le temps de chargement des pages.
HTTP Archive, BigQuery, and you! par Ilya Grigorik (Google)
http://www.youtube.com/watch?v=TOFgDSqNRz4
Google propose avec son service BigQuery un accès à beaucoup de données. Ainsi on peut savoir si mon site est rapide, quels sites va le plus vite, si mon site télécharge plus d’image qu’avant, quel est la font la plus utilisée, etc . BigQuery se base sur les données de HTTP Archive qu’on avait vu lors du premier jour de la Velocity Conférence. BigQuery est un requeteur qui va interroger la base de données de HTTP Archive.
Ensuite Ilya va présenter BigQuery et comment on peut l’utiliser.
Enfin pour finir, Ilya present un site qui permet de partager des resultats de BigQuery : bigqueri.
When dynamic becomes static: the next step in web caching techniques par Wim Godden (Cu.be Solutions)
Dans cette présentation, on parle des ESI et de leurs limitations : on ne peut pas cacher en ESI des blocs qui doivent avoir des comportements différents en fonction de différents paramètres comme un utilisateur par exemple. Il existe des contournements mais on ne peut cacher correctement ces blocs.
C’est pour cela que Wim a développé un langage dans Nginx permettant au serveur web de gérer des variables afin que celui les stockent dans du memcache ou autres et qui puisse y accéder sans faire un appel supplémentaire.
La release publique devrait arriver en 2014. On a hâte ou pas !
What is the Velocity of an Unladen Swallow? A quest for the Holy Grail par Perry Dyball (SeatWave)
C’est l’histoire d’une entreprise qui a créé un site pour acheter des tickets (concert / spectacles) en ligne. Suite à un appel antenne à la télévision (publicité), leurs sites a lamentablement crashé (ça me rappelle beaucoup de choses :)).
Ils ont du optimiser leurs sites avec un système de queue notamment pour faire face aux autres appels antennes.
La morale de cette histoire c’est tout simplement qu’on ne doit pas s’intéresser à l’optimisation quand ça plante, mais dès le début de l’applicatif.
Code is Evil par Dan Rathbone (British Sky Broadcasting)
Face aux problèmes de performance de leur site skybet, il a été décidé de remettre à plat l’applicatif. Leur seul but était de donc de pallier aux problèmes de performance coûte que coûte et ainsi de faire des choix surprenants.
Les données sont alors stockés de manière dénormalisées, directement prête à être affiché avec des templates simples. Les règles métiers sont faites en amont et le résultat est stockés en base de données.
Ainsi, on réduit le code, donc peu de maintenance, pas de framework ni de cache.
Cette présentation m’a bluffé car elle ne correspond pas au paradigme actuel du développement web.
Breaking 1000ms Mobile Barrier par Ilya Grigorik (Google)
Ilya nous présente dans cette présentation comment afficher une page en moins d’une seconde. La perception humaine dit qu’en dessous de 250 ms, le site est rapide. Au bout d’une seconde, la personne commence à réfléchir. Au bout de 10 secondes, la personne s’en va tout simplement.
Déja pour les devices mobiles, on a le touch event qui permet de gerer la navigation par le toucher. Ce touch event prendre entre 50 et 300 ms en fonction des devices. Celui ci peut être overrider par fastClick.
Il parle aussi des différences entre la 4G et la 3G, mais aussi du protocole TCP qui permet d’avoir des taux de latence plus ou moins long.
Voici quelques conseils pour optimiser les temps de chargement des pages web :
- utiliser des CDNs pour les assets (javascript, css, images, etc)
- compresser au maximun les assets
- Eliminer les redirects inutiles, etc
- Optimiser le chemin critique de rendu : charger en meme temps le html et le css qui permet de rendre visible le site et ensuite charger les css et les javascripts supplémentaires
- Charger uniquement les assets utiles pour la page
- Utilisation des mots clés « predict », « preresolve », « prefetch » et « prerender » pour anticiper les actions utilisateurs.
Conclusion
Cette seconde journée s’est centré sur la performance des applicatifs web. En effet, il faut prendre en compte cette notion de performance dès le début du projet. La présentation de Dan Rathbone a été assez surprenante car elle ne correspondait pas forcement à ma conception des applications web.
Testing all the way to production par Sam Adams (Lmax exchange)
http://www.youtube.com/watch?v=_cS9QPJ5pIE#t=28
Cette présentation repose sur le fait qu’on doit effectuer des tests pour valider au moins unitairement les développements pour les déploiements. Ainsi, Sam Adams va présenter le workflow de développement qui est basé sur les tests pour déployer du code et en évitant les régressions.
Il utilise l’intégration continue et par du postulat que chaque build peut être et doit être prêt à passer en production (chaque commit doit être fonctionnel). Au vu du contexte de l’entreprise, ils font des déploiements en production toutes les deux semaines, le samedi matin).
Le workflow de déploiement se fait en 4 phases et ce workflow est tout le temps utilisé :
- Avant le commit, il doit y avoir des tests unitaires
- Lors du passage sur « testing », on a une analyse sur le code, et des tests (intégration, unitaire, performance, etc)
- Ensuite viens, le passage sur « staging », qui est ISO prod.
- Et enfin la production, si tout est bon.
Actuellement, il y a plus de 7000 tests automatisés sur leurs applicatifs.
Le but de ce workflow, c’est d’automatiser les déploiements. De cliquer sur un lien et d’ensuite aller boire un café sans se soucier de la mise en production, car c’est testé et on sait que ça marche ! (utopie … 🙂 )
En réalité, la plupart du temps, les mises en production se passent bien mais il peut arriver des problèmes car :
- Les tests ne représentent jamais la production. La production est la production et sera la seule production.
- Il peux avoir des erreurs humaines.
Le meilleur moyen de tester c’est aussi de tester en production. Ce n’est pas des tests fonctionnels ou de performances, mais juste de savoir très rapidement ce qui marche et se focaliser uniquement sur les choses qui ne fonctionnent pas.
Une des solutions quand on développe une nouvelle fonctionnalité c’est d’essayer d’impacter le moins possible le fonctionnel existant : isoler le développement afin de ne pas contaminer le reste.
Afin de tester au mieux l’applicatif et de reproduire au mieux la production, il faut aussi pouvoir la tester avec les données de production et donc permettent à tout le monde de récupérer facilement les données de production.
Petit rappel de cette présentation :
- test, test et test ( et si c’est lourd, il faut les automatiser)
- tout tester
- si il y a un problème sur la production, il y a un problème sur l’intégration continu
- avoir accès simplement aux données de production
Making performance personal at Financial Times labs par Andrew Betts (Financial Times)
http://triblondon.github.io/talk-makingperfpersonal/#/
Le Financial Times sont très actifs concernant les web perfs. Voici ce qu’ils ont mis en place sur leurs sites :
- utilisation de fastClick
- utilisation de manifest
- la non utilisation de plugins tiers comme l’api de facebook, ou l’api de google qui alourdit énormément le temps de chargement des pages.
HTTP Archive, BigQuery, and you! par Ilya Grigorik (Google)
http://www.youtube.com/watch?v=TOFgDSqNRz4
Google propose avec son service BigQuery un accès à beaucoup de données. Ainsi on peut savoir si mon site est rapide, quels sites va le plus vite, si mon site télécharge plus d’image qu’avant, quel est la font la plus utilisée, etc . BigQuery se base sur les données de HTTP Archive qu’on avait vu lors du premier jour de la Velocity Conférence. BigQuery est un requeteur qui va interroger la base de données de HTTP Archive.
Ensuite Ilya va présenter BigQuery et comment on peut l’utiliser.
Enfin pour finir, Ilya present un site qui permet de partager des resultats de BigQuery : bigqueri.
When dynamic becomes static: the next step in web caching techniques par Wim Godden (Cu.be Solutions)
Dans cette présentation, on parle des ESI et de leurs limitations : on ne peut pas cacher en ESI des blocs qui doivent avoir des comportements différents en fonction de différents paramètres comme un utilisateur par exemple. Il existe des contournements mais on ne peut cacher correctement ces blocs.
C’est pour cela que Wim a développé un langage dans Nginx permettant au serveur web de gérer des variables afin que celui les stockent dans du memcache ou autres et qui puisse y accéder sans faire un appel supplémentaire.
La release publique devrait arriver en 2014. On a hâte ou pas !
What is the Velocity of an Unladen Swallow? A quest for the Holy Grail par Perry Dyball (SeatWave)
C’est l’histoire d’une entreprise qui a créé un site pour acheter des tickets (concert / spectacles) en ligne. Suite à un appel antenne à la télévision (publicité), leurs sites a lamentablement crashé (ça me rappelle beaucoup de choses :)).
Ils ont du optimiser leurs sites avec un système de queue notamment pour faire face aux autres appels antennes.
La morale de cette histoire c’est tout simplement qu’on ne doit pas s’intéresser à l’optimisation quand ça plante, mais dès le début de l’applicatif.
Code is Evil par Dan Rathbone (British Sky Broadcasting)
Face aux problèmes de performance de leur site skybet, il a été décidé de remettre à plat l’applicatif. Leur seul but était de donc de pallier aux problèmes de performance coûte que coûte et ainsi de faire des choix surprenants.
Les données sont alors stockés de manière dénormalisées, directement prête à être affiché avec des templates simples. Les règles métiers sont faites en amont et le résultat est stockés en base de données.
Ainsi, on réduit le code, donc peu de maintenance, pas de framework ni de cache.
Cette présentation m’a bluffé car elle ne correspond pas au paradigme actuel du développement web.
Breaking 1000ms Mobile Barrier par Ilya Grigorik (Google)
Ilya nous présente dans cette présentation comment afficher une page en moins d’une seconde. La perception humaine dit qu’en dessous de 250 ms, le site est rapide. Au bout d’une seconde, la personne commence à réfléchir. Au bout de 10 secondes, la personne s’en va tout simplement.
Déja pour les devices mobiles, on a le touch event qui permet de gerer la navigation par le toucher. Ce touch event prendre entre 50 et 300 ms en fonction des devices. Celui ci peut être overrider par fastClick.
Il parle aussi des différences entre la 4G et la 3G, mais aussi du protocole TCP qui permet d’avoir des taux de latence plus ou moins long.
Voici quelques conseils pour optimiser les temps de chargement des pages web :
- utiliser des CDNs pour les assets (javascript, css, images, etc)
- compresser au maximun les assets
- Eliminer les redirects inutiles, etc
- Optimiser le chemin critique de rendu : charger en meme temps le html et le css qui permet de rendre visible le site et ensuite charger les css et les javascripts supplémentaires
- Charger uniquement les assets utiles pour la page
- Utilisation des mots clés « predict », « preresolve », « prefetch » et « prerender » pour anticiper les actions utilisateurs.
Conclusion
Cette seconde journée s’est centré sur la performance des applicatifs web. En effet, il faut prendre en compte cette notion de performance dès le début du projet. La présentation de Dan Rathbone a été assez surprenante car elle ne correspondait pas forcement à ma conception des applications web.
