Aller au contenu | Aller au menu | Aller à la recherche
mercredi, 9 décembre 2009
Il y a un petit truc assez sympa avec la gestion des caches dans Zend Framework (et donc Zend_Cache) et c'est les tags.
Les tags sont peut-être ignorés par beaucoup parce que ce n'est que le 3ème paramètre et qu'il n'est pas obligatoire. Voici un petit exemple de leur utilité.
vendredi, 24 juillet 2009
Voici un petit exemple d'optimisation réalisé. J'ai analysé avec XDebug et WinCacheGrind l'appel à une page. Cette page affiche quelques centaines de lignes provenant d'une table d'une base de données.
Chacune des lignes est affichée avec un partial ce qui me permet d'utiliser le même affichage dans deux pages différentes. Les données de chaque ligne sont accédées via les getters et setters de Zend_Db_Table_Row et Zend_Db_Table_Rowset.
Voici tout d'abord l'analyse de la page sans aucune optimisation.
On constate un temps d'exécution de 488ms. En rouge, j'ai surligné les processus liés aux getters et en jaune ceux liés aux partials. On peut constaté d'ores et déjà qu'ils sont nombreux et au sommet des processus les plus consommateurs.
Voici, ensuite, le résultat après suppression des getters en utilisant des tableaux PHP standard à la place d'objet Zend.
On est passé de 488ms d'exécution à 379ms. Un gain de l'ordre de 20%.
Ci-dessous, la même analyse après l'optimisation des partials et l'utilisation d'includes.
Là, on gagne presque 30% de performance en passant à 225ms de temps d'exécution. Ce qui fait, au total, 50% de gain par rapport au code original.
Voici un petit code qui vous aidera à récupérer le chemin vers vos fichiers de script et donc utiliser un include à la place du helper partial :
$moduleDir = Zend_Controller_Front::getInstance()
->getControllerDirectory('default');
$viewsDir = dirname($moduleDir) . '/views/scripts';
<?include($viewsDir . '/controller/_partial.phtml')?>
Bien entendu, on peut discuter de la manière de faire. Mais ce que j'essaie de démontrer est plutôt la lourdeur des tâches réalisées par Zend. Par exemple, on constate le chargement des plugins, le clonage des variables de la vue, le chargement des helpers, etc... à chaque utilisation de partial()
A utiliser, donc, avec parcimonie et toujours préférer les méthodes efficaces sur des codes récurrents.
Les getter et setter dans PHP5 sont des outils très utiles. Malheureusement, à force de trop les utiliser, ils parviennent à rapidement plomber l'efficacité d'un code qui est pourtant simple.
Zend Framework, ici, n'échappe pas à la règle. Une solution simple pour éviter les contre-performances des classes comme Zend_Config ou Zend_Db_Table est de faire attention de ne pas abuser de la petite flèche vers la droite (->) et surtout pas dans des boucles.
On constate que rapidement, en bouclant sur un résultat de requête, par exemple, 20% du temps est pris simplement par les tests et la copie des données dans le getter.
La solution est évidemment d'utiliser des tableaux standards. La fonction toArray() règle le problème dans la plupart des cas.
Le helper partial, quel bonheur ! On inclut un bout de code au milieu d'un autre bout de code et on peut le réutiliser partout. Oui, mais non...
Ce helper a la facheuse tendance de dupliquer la vue et énormément de code. Cette duplication a bien entendu un coût d'exécution. En le positionnant au milieu d'une boucle, la fuite de performance est inévitable.
Préférez encore l'utilisation du vieux include pour insérer votre code, quitte à déclarer les variables nécessaires avant son appel. Et ceci, surtout si vous vous trouvez dans un code récurrent.
On en a déjà parlé dans un précédent billet. Zend_Date et Zend_Locale sont des gouffres à mémoire. Malheureusement, il s'avère que ce n'est pas leur unique problème.
A l'instanciation d'une classe utilisant Zend_Locale, une multitude de fichiers XML sont chargés en mémoire, prenant d'un seul coup quelques mégas. Ceux-ci contiennent les détails sur l'affichage des dates, heures et devises. Bien entendu, ceci a un coût au niveau du temps de chargement.
Il faut utiliser ces classes avec parcimonie. Surtout, éviter les instanciations multiples dans des boucles, comme toujours. Et si vraiment les performances sont trop mauvaises, n'hésitez pas à utiliser les bonnes vieilles fonctions PHP.
Zend Framework nous offre des outils mais leur philosophie n'a pas l'air d'être la performance. Malheureusement pour nous, il va falloir utiliser ces classes avec attention.
En optimisant un tout petit peu son code, on arrive à des gains de performances énormes, de l'ordre de 50 à 60% de temps d'exécution économisé. Donc ça en vaut largement la chandelle !
Vous pouvez facilement analyser les performances de votre code en suivant le petit tutoriel à disposition ici.
Suite à quelques expériences, j'ai de gros doute sur les performances de Zend_Application et également le générateur de CAPTCHA de Zend. Mais n'ayant pas pu faire de plus amples tests, j'évite de m'étendre là dessus pour l'instant.
Connaissez-vous d'autres gouffres à performance ? N'hésitez pas à en faire part... 
Mise à jour: j'ai publié un exemple d'optimisation de Zend Framework en espérant que ça vous sera utile.
lundi, 30 mars 2009
Zend Framework propose des fonctionnalités et une puissance certaine en plus d'être modulaire et de disposer de la pérennité de sa société créatrice. Malheureusement, le framework a quelques soucis de performance qui apparaissent rapidement à l'oeil du développeur averti.
En affichant simplement la mémoire consommée sur une page générée à l'aide du ZF, nous constatons rapidement que cette consommation est assez exagérée. Les scores nous amènent rapidement aux alentours des 10 ou 15M. On peut alors imaginer ce qui se passerait si nous montions en charge.
Dans le cadre d'un projet nécessitant, justement, de supporter une haute charge, j'ai été amené à participer à l'évaluation des performances de Zend Framework.
Le but de cette évaluation n'était pas de déterminer si le framework était plus ou moins performant qu'un code PHP pur ou qu'un autre framework, comme CodeIgniter ou Kohana, car nous connaissons déjà la réponse à cette question.
Non, le but était de déterminer, premièrement, si l'infrastructure prévue était suffisante. Dans le cas contraire quelle infrastructure devait être mise en place pour supporter un nombre déterminé de connexions concurrentes. Et finalement, déterminer si ces acquisitions étaient une solution viable et moins onéreuse que l'optimisation ou la formation de développeurs sur un framework différent.
Malgré les piètres performances de Zend Framework en terme de consommation mémoire, nous avons vite réalisé que ce n'était pas son plus gros point faible.
lundi, 16 mars 2009
Pour contacter ses utilisateurs et leur transmettre codes, mot de passe et communication, nous utilisons des e-mails. Dans Zend Framework, Zend Mail nous aide à cette tâche. Cette classe permet de facilement configurer, construire et envoyer un e-mail.
Jusque là, aucun problème, mais bientôt on voudra probablement améliorer sa communication et ajouter son logo, ou un pied de page contenant les mises en garde et ceci pour tous nos e-mails sortants. On se dit alors, qu'il serait fort pratique de bénéficier de la puissance de Zend Layout pour ce faire.
Egalement, bien souvent, les données contenues dans nos e-mails sont formatées de la même manière que sur notre site grâce à des aides de vue (Helpers). Pour pouvoir bénéficier de ces aides, on aimerait pouvoir créer nos e-mails grâce à des vues de type Zend View.
Dans cet article, je vous propose une classe, qui vous permet de gérer vos e-mails grâce à un layout et une vue tout comme vous le faites pour vos pages standards.
« billets précédents - page 1 de 3
Copyright © 2007 - 2009 Eric Jeker
propulsé par DotClear
