Image de couverture de l'article Retour d'expérience sur Symfony Flex
Retour aux articles

L'agence

WanadevStudio

Retour d'expérience sur Symfony Flex

Symfony Flex se présente comme une nouvelle structure pour nos projets Symfony et peut-être même LA nouvelle structure. Petit retour d'expérience sur les gains techniques de futures nouvelles normes.

Présentation de Flex

Flex est le futur de Symfony. Précédemment, l'initialisation d'un projet se faisait grâce à une base dite "standard" (symfony/standard) qui embarquait tous les composants Symfony. Depuis Symfony 3.3, vous pouvez désormais créer des projets Symfony à partir d'une base dite "Flex" (symfony/skeleton). Celle-ci se veut par défaut légère.

En fonction de vos utilisations, vous ajoutez les composants Symfony dont vous avez besoin.

  • symfony/translation pour les traductions
  • symfony/form pour générer des formulaires
  • et bien d'autres

Présenté comme une alternative à la version standard avec Symfony 3, ce système sera celui par défaut avec Symfony 4 bien que l'initialisation de la version standard sera toujours possible.

Contexte : pourquoi j'utilise Flex

Je travaille actuellement sur un projet Symfony 3 et je viens tout juste de finir la migration vers une structure Flex. La migration n'est pas "simple" car aucun outil n'a été développé. Il faut être rigoureux et suivre les indications données par Sensio. Au final, on réalise la migration assez rapidement quand on a compris le fonctionnement de Flex et son architecture.

En réalisant quelques recherches (voir toutes les sources en pied de page -- merci aux auteurs :-) ), j'ai trouvé un article du site symfony.fi comparant les performances entre les deux architectures disponibles.

La conclusion était une amélioration des performances de l'ordre de 20% entre Symfony 3 (Microkernel) et Flex bien que l'auteur ne veuille pas s'engager outre mesure sur des chiffres parfaitement exacts.

I wouldn't get too excited without more indepth analysis, but it looks like you get on average 20% improved throughput with the Microkernel and other improvements in Symfony Flex.

De mon côté voici l'état des changements/améliorations pour le passage d'un Symfony standard (non Microkernel) vers une architecture Flex.

Les dépendances

Titre_de_l_image

Les tailles du dossier vendor diminuent légèrement de mon côté... mais le gain reste faible. Certes, Flex embarque par défaut le minimum vital, mais la construction d'une application nous amène rapidement à importer quasiment l'intégralité des composants Symfony. De plus, certains composants ne sont pas stateless et l'ajout d'un composant entraînera probablement l'installation d'autres composants en arrière-plan. Le gain est donc relativement faible dans mon cas. Selon les projets le gain sera plus ou moins important.

Plus le projet est petit, plus Flex sera intéressant.

Benchmark

J'ai réalisé un petit benchmark des performances. Ces chiffres sont bien évidemment à prendre avec précaution, mon cas de test pouvant ne pas correspondre à l'intégralité des cas.

Le test a été particulièrement simple. Réaliser un siege sur l'environnement de production pendant 1 minute. Une fois, sans accès concurrent et une fois avec 10 concurrents simultanés. opcache et APCu ont été désactivés pour limiter l'effet de cache qui compense les latences I/O lors de l'accès aux fichiers.

Les chiffres rendus sur un graphique ne permettent pas de distinguer de différences comme vous pourrez le constater.

Titre_de_l_image

Utilisation de Flex : la conclusion

Symfony Flex apporte une architecture différente qui permet de toucher aussi bien les "gros" projets que les projets plus légers. Les gains de Flex seront d'ailleurs principalement visibles pour les petits projets ne nécessitant que quelques composants, comme faire le rendu d'une page, ou simplement gérer une API (dans ce dernier cas, il est inutile d'installer le composant de templating par exemple). Le système de dépendances reste facile à prendre en main et l'ajout de nouveaux composants se fera extrêmement rapidement. Toutefois, dans la pratique, les gains resteront plus faibles que sur des benchmarks comparant deux projets vides sans dépendance supplémentaire ajoutée.

En savoir plus sur Flex : les références à lire

Commentaires

Photo de Maxime Steinhausser auteur du commentaire

Maxime Steinhausser

Il y a 7 ans

Hello!


Je trouve que l'article passe un peu à côté de la raison d'être de Flex :/

Celle-ci n'a jamais été vraiment orientée vers les performances, mais vise plutôt à faciliter la création d'applications spécifiques en un minimum de configuration grâce aux recipes et à l'auto-configuration des fonctionnalités en fonction des composants installés, en se reposant sur le principe de composition.


Les gains de performances potentiels avec Flex ne sont que la conséquence de l'activation des fonctionnalités strictement requises (et le nombre de vendors n'importe que peu, voire pas du tout), ce qui était d'ores-et-déjà tout à fait réalisable en partant d'une édition standard et en ayant require `symfony/symfony` (et donc l'intégralité des composants, bundles et bridges). Tout (ou presque) n'est que question de configuration et le but avoué de Flex est d'automatiser un maximum et faciliter la vie des développeurs en se sens, tout au long du cycle de vie du projet.


Mais tout ceci est très bien expliqué par Fabien dans sa suite d'article sur Flex, dont je recommande la lecture si ce n'est pas déjà fait ! :) https://symfony.com/blog/symfony-4-a-new-way-to-develop-applications


Concernant ce retour donc, il me semble un peu trop orienté benchmark et manque d'un véritable retour d'xp sur les changements qu'apporte Flex au quotidien dans le développement d'une application. Certainement parce que tu n'as pu qu'effectué une migration d'un projet existant vers la nouvelle structure jusqu'à présent ?

Bonjour Maxime et merci pour ton retour.

Tout comme tu le dis, Flex n'a jamais été présenté comme ayant pour objectif une amélioration des performances et son intérêt se trouve dans de nombreux autres aspects.

L'objectif de ce (micro) article est simplement de faire la lumière sur les performances, sujet que j'ai vu maintes fois vues dans des différents articles. Mon objectif caché est clairement de montrer que les gains de performance vendu par certains ne sont pas constatable en production.

J'espère pouvoir réaliser un article orienté présentation qui serait loin des aspects benchmarks car il ne s'agit pas (comme tu as pu le dire) des bénéfices mises en avant par la communauté.

Merci tes retours, il est important de ne pas penser que Flex n'apporte rien car ce n'est pas ce que j'ai voulu présenté :-)