Performance de Zend Framework

On dit que la nuit porte conseil alors j'ai dormi sur mes deux oreilles et je suis prêt à faire suite à ma réflexion amorcée hier quant à réinventer la roue en programmation.

Tout a commencé quand un programmeur récemment embauché s'est mis à remettre en question les façons de faire adoptées par l'entreprise. Pas qu'il manque d'expérience : il a tout simplement une expérience différente. C'est correct car ça apporte un point de vue nouveau qui peut nous éclairer face à certaines décisions. Comme n'importe quoi, on en prend et on en laisse. Or, pour rester objectif, je n'aime pas quand ça fonctionne sur des ouï-dire ou quand ça tourne à la loi de celui qui parle le plus fort. C'est important d'appuyer nos arguments avec des faits concrets, d'être en mesure de les justifier.

Je l'avoue, j'ai reçu des coups bas (cheap shots) de sa part et je n'ai pas été mieux car j'ai répondu à ses attaques. Je suis un type de personne assez "low-profile", généralement assez discret mais quand j'entends dire une niaiserie, je suis toujours prêt à défendre mon point et d'assumer mes opinions et prouver ce que j'avance.

Un des points qui m'a dérangé est une accusation visant la qualité de Zend Framework (ZF). Selon lui, parce qu'il a trouvé une limitation d'un composant et un bogue dans un autre, c'est suffisant pour conclure que c'est de la merde dans son ensemble. À ses yeux, mieux vaut développer nos propres composants, ça serait plus fiable. De plus, il prétendait que le framework était trop lourd, que la performance était atroce et qu'il fallait bannir ZF de nos projets à tout prix.

Hum, ça sonne mal à mes oreilles. Malgré toute ma bonne volonté, je n'ai pas la prétention d'être meilleur que les développeurs de Zend. Vous savez Zend, les mêmes qui développent le Zend Engine, le moteur de PHP ? C'est un peu comme si on accusait Sun de bâcler le travail effectué dans le développement de Java. C'est facile de chialer sur le travail accompli par les autres. Et avouez que ça donne le goût de lancer un défi aux détracteurs pour voir s'ils feraient mieux! À tord, notre ego de programmeur est souvent trop confiant de pouvoir surpasser les éléments en place pour apporter une amélioration réellement significative. Parfois on réussit, mais à quel prix ?

D'un côté, c'est vrai qu'en utilisant ZF, on est dépendant du développement externe pour les "bug fixes". Au rythme où les mises à jour sortent (1 fois par mois je crois), les chances sont bonnes pour que le bogue risque d'être corrigé rapidement si on leur rapporte.

Du point de vue de la performance, il n'a pas été en mesure de quantifier l'amélioration qu'a apporté le développement interne effectué pour remplacer le composant de Zend qui avait largement fait ses preuves. À l'écouter parler, le gain était tel que c'était le jour et la nuit. J'étais sceptique face à ce qu'il avançait car jamais je n'ai remarqué de lenteur en utilisant ce composant en trois années d'utilisation. Quand je lui ai demandé de préciser, il s'est contenté de répondre que c'était trop technique pour en parler devant les patrons et qu'on en discuterait à un moment plus opportun.

En vérité, on ne l'utilise pas sous forme de framework MVC proprement dit justement pour ne pas qu'il soit trop limitatif (nous avons développé une grosse base de code réutilisable au fil des ans). Le terme "framework" n'est pas tout à fait exact dans le cas de ZF (contrairement à Symphony, CakePHP, etc) car il s'agit plutôt d'une librairie de composants indépendants (on choisit ceux qu'on a besoin) qualifié de "lightweight, loosely-coupled component library".

Mais lentement, on se rend compte des avantages liés à l'utilisation d'une architecture MVC et on s'en va dans cette direction. Utiliserons-nous les composants ZF pour arriver à nos fins ? Eh bien non. Il semblerait qu'on soit en train de développer une autre solution maison.

Développeriez-vous une équivalent "home-made" pour remplacer jQuery ou faire votre propre éditeur RTE plutôt que de préférer TinyMCE ? Si la librairie ZF offre une classe qui permet de faire le travail, par exemple Zend_Service_Twitter, est-ce que ce n'est pas un choix logique que de le mettre à l'essai en premier avant de réinventer la roue ? Est-ce que la loi du 80/20 (Pareto) serait de mise ?

Il y a aussi un autre avantage de taille à utiliser des composants connus et supportés par la communauté : lorsque des nouveaux programmeurs sont engagés, ils peuvent apprendre rapidement les composants qui sont largement documentés et testés par des milliers de développeurs, plutôt que de tenter de patauger dans du code maison que seuls ceux qui travaillent (encore) entre les 4 murs de l'entreprises peuvent supporter.

C'est une attitude qui me déplait chez certains programmeurs. Au lieu de se concentrer sur "getting the job done", ils ont la prétention de pouvoir révolutionner le monde avec des solutions obscures. En même temps, créer un système maison les rend indispensables à l'entreprise puisque la vision et la documentation se trouvent dans leurs têtes. S'ils quittent, quelles ressources pourront reprendre le flambeau ? On est loin des standards que l'autre parlait.

En tant que programmeur, qu'est-ce qui fait qu'on a une fâcheuse tendance à vouloir remplacer une solution qui marche bien par une autre ? Est-ce par recherche du défi ? Avoir le mérite d'avoir codé toutes les lignes du projet ? L'atteinte de la perfection ? Le monde qui nous entoure n'est pas parfait alors réinventons en un numérique qui le sera ? Est-ce une façon de jouer à Dieu et d'avoir le contrôle total sur notre création ? (bien entendu, j'exagère, mais c'est pas faux)

Cela dit, je ne remets pas en question la compétence de ces individus, seulement les décisions liées au développement durable dans une entreprise. Dans notre cas, je sens qu'on est à la croisée des chemins et que j'ai mon mot à dire sur ce qui touchera mon travail dans les années à venir.

Revenons-en à la performance du composant de ZF. Rappelons-nous que l'argument qui était au coeur de la discussion était que ce composant précis était peu performant. Pour m'en assurer, je suis allé chercher conseil auprès de Matthew Weier O'Phinney, le "project lead" du ZF. Tant qu'à aller à la source, autant choisir quelqu'un qui ne parlera pas à travers son chapeau. Je lui ai expliqué la problématique et voici un extrait de sa réponse :

I haven't done any benchmarking of the component, but knowing its design, I suspect it will not suffer. It uses a di-cyclic graph in order to perform permission lookups, which tends to be very fast, and comparable to tree traversal when it comes to zeroing in on an individual permission.

Of course, it will take some amount of time -- just like calling any operation in PHP. If you're doing 100s or 1000s of lookups in a single request, it may be possible that you'll see a slowdown -- but then, that will be true for any operation you perform that many times in your request.

If you're uncertain, use XDebug or Zend Debugger to do some targetted profiling of your application to see how much time is being spent.

Merci Matt, je vais suivre ton conseil, juste pour avoir des chiffres à l'appui. Qui sait si ce n'est pas moi qui a tord ? Je laisse le bénéfice du doute tant que je n'ai pas de preuve. J'ai installé XDebug et j'ai effectué un test de performance où 1000 appels ont été faits sur le composant ZF. Le résultat est étonnant : 0,29 seconde. Je ferai des tests de performance comparatifs la semaine prochaine en soumettant la classe maison dans le collimateur et voir si ça valait le coût de remplacer ce composant. À date, avec ce que j'ai vu, ce sera difficile à battre...

Stay tuned!