Jour 2 du PHP Tour 2016. Cet article suit le retour sur la première journée.

Optimisation des performances (PHP)

Par Fabien Potencier (Sension Labs, Blackfire.io)
Fabien nous parle ici de profiling. (J’ai un peu peur que ce soit une publicité ouverte pour blackfire).
40% des utilisateurs quittent un site qui prend plus de 3 secondes à charger. Ce nombre descend d’année en année.
Fabien reprend l’exemple d’Amazon qui augmente son revenu de 1% en optimisant de 100ms le temps de chargement d’une page.
Pour lui, un problème de performance EST un bug.
Les trois solutions les plus faciles à mettre en œuvre : PHP7, HTTP2, Varnish.
Profiler en PHP: on peut utiliser microtime, mais ce n’est pas très efficace 🙂
Il nous explique ensuite les notions de base du profiling (temps inclusif, exclusif, etc.), ainsi que le temps I/O.
Le but du jeu quand on profile est vraiment de trouver les portions bloquantes du code.
Il faut savoir s’arrêter, l’optimisation est toujours un compromis: CPU vs Mémoire, Temps passé vs temps gagné, Vitesse vs complexité du code.

De 7 à 3s : retour d’expérience sur la performance Web sur decitre.fr

Par Sébastien Rogier, Decitre

A l’inverse de Fabien dans la conférence précédente, Sébastien nous parle ici des améliorations de perfs mais surtout sur le front.

Il nous présente ses outils: NewRelic, Blackfire. Il nous annonce un gain de ~40% avec le passage à PHP7.

Il parle ensuite des outils pour le fronts (waterfall, détail d’un HIT http et du navigateur), fait un petit point sur webpagetest.org.

Sébastien fait un retour sur toutes les bonnes pratiques de l’optimisation de front :

  • iconfont,
  • suppression d’images inutiles,
  • images en base64 pour les petites images,
  • minification / concaténation d’assets,
  • lazy-loading d’images,
  • la compression,
  • la gestion de la durée du cache HTTP.
  • les “Cookieless” domain pour charger les assets,
  • optimisation des images (tinypng),
  • parallélisassions des appels pour les images

Il nous explique que les différentes itérations ont amené 15% de CSS mort. La solution peut être “uncss”. Pour leur part, ils ont profité d’un passage à Sass pour ne reprendre que le nécessaire.

Il parle ensuite de la réduction des contenus bloquants pour retarder leur execution (Javascript). L’outil “requestmap” permet d’avoir une visualisation sur l’exécution du JS pour identifier les SPOF. Il faut auditer les scripts externes qui sont la pour une version business, mais qui ont un impact sur les perfs.

Leur prochaine améliorations: Passer à HTTP2 (multiplexage des requêtes, compression des headers, content pushing)

Les slides

 

RabbitMQ 101 : How to cook the rabbit?

Par Quentin Adam de CleverCloud

Http: manque de la notion d’ack (aknowledgment), routing et sécurité pas simple à gérer.

Dans une application, on a besoin de réagir à des évènements: Si l’on achète un produit, on envoie un mail, on modifie son compte, on lui ajoute des points de fidélité, etc.

AMQP a plusieurs implémentations, RabbitMQ étant la plus connue. RabbitMQ a une librairie dans à peu prêt tous les langages.

On envoie simplement le “messsage” dans la hitbox. Il faut ensuite brancher une “queue” qui récupère le message. Le consumer “consume” les queues.

Quentin nous parle des différents types d’exchanges de AMQP.

Possibilité d’avoir un “reply-to” par message qui permet de retourner la réponse dans une autre queue.

Conférence assez pointu, je suis toujours un peu perdu dans l’utilisation de Rabbit, même si je suis convaincu que c’est un bon outil 🙂

Soyez spécifiques

Par Kevin Gomez, créateur de Rulerz

Kevin donne un exemple sur “Comment afficher / chercher les livres selon plusieurs critères ?” Les critères sont des spécifications : Décorréler l’expression d’un besoin d’un objet sur lequel on doit vérifier ce besoin.

Il nous parle donc de Rulerz, la librairie qu’il a développé qui permet de définir nos règles business. (recherche bizarres, coupons de réduction, recherche avec beaucoup de filtres, etc.)

Feature Flags

Par Olivier Dolbeau, Benjamin De Bernardi de BlaBlaCar

Les besoins:
  • Besoin d’activer / désactiver des fonctionnalité en prod pour éviter l’effet capital
  • Tester en prod pour certaines raisons
  • Faires des déployements de features au fur et à mesure
  • Features spécifiques par pays

En plus de ça, ils veulent changer sans livrer un service, que ça soit device agnostic et que ça fonctionne partout (API, etc.)

Besoin d’un storage: interface d’admin, storage et librairie pour accéder aux données. Utilisation de quandidate/toggle.

En plus du code, qandidate fournit de base une API et une UI de gestion des features.

Stockage des features dans redis + apcu en cache pendant une minute.

Pour les applications mobiles: Flags dans l’API + Flags dans les applications mobiles: export des flags dans un Amazon S3, le mobile utilise la même configuration que les flags “PHP”, mais traité avec des libs développés en interne (open-sources: flaggr)

Retour d’expérience : réaliser des Workers en PHP

Par Fabien de Saint pern, M6Web

Fabien nous explique ici comment faire des workers en PHP, même si ce n’est pas le langage le plus pratique pour ça. Il nous explique qu’on peut lancer les traitements non critiques en différé.

Utilisation de RabbitMQ là aussi. Fabien nous présente là aussi RabbitMQ dans l’utilisation qu’ils en ont.

Utilisation de workers pour : dénormaliser, production de documents, transcodage vidéo, jeux interactifs, stats, etc.

Les ennemis des workers : la Fatal error, les memory leaks

Les workers ne sont pas forcément utiles, un crontab peut suffire. Ne pas mettre des workers partout lorsqu’il n’y en a pas besoin (Queues vides !).

Fabien présente ensuite le DaemonBundle qu’ils ont développé pour créer des commandes via Symfony qui fait tout ça bien pour nous. Utilisation de supervisord pour lancer les services.

Pour RabbitMQ: AMQPBundle.

Il est indispensable de monitorer vos workers ! (nombre d’itération, mémoire, IO, logs)