Zend FR

Pour le Viewrenderer, dans tous les cas, en regradant au début de dispatch() dans le front, je me suis appercu que même si il n'est pas initialisé dans le bootstrap, il y a une belle intanciation de celui-ci :

if (!$this->getParam('noViewRenderer') && !Zend_Controller_Action_HelperBroker::hasHelper('viewRenderer')) {
            #require_once 'Zend/Controller/Action/Helper/ViewRenderer.php';
            Zend_Controller_Action_HelperBroker::getStack()->offsetSet(-80, new Zend_Controller_Action_Helper_ViewRenderer());
        }

donc (sauf ''noViewRenderer'') il est toujours loader.

Dernière modification par baboune (28-04-2009 10:29:36)

baboune a écrit:

une petite question sur les perfs, mon gros problème est de faire fonctionner correctement des sites avec zend sur des serveur mutuailsé, le souci est le premier chargement du site, c'est la normalement que les class sont compilé en C, enfin ce que j'ai comprit et ensuite ça fonctionne assez bien dans l'ensemble (+ ou moins 1 seconde la page, sans cache) mais le premier chargement peut aller jusqu'a 11 secondes !

donc je sais zend n'est pas fait pour les mutualisé, mais exite-il des solutions pour minimiser ce phénomène.
(j'utilise zend_Loader) j'hésite a changer mon code et a supprimer Zend_layout et le viewrenderer, mais bon vu le boulot faut que je sois sure du résultat.

déjà le moteur Zend ne compile pas en C mais en ByteCode et je ne sais pas ou tu as vu que ce n'était pas fait pour le mutualisé
le moteur Zend est au contraire très efficace sur le sujet
les classes dans les librairies partagé ne sont compilée qu'une seule fois pour tout les sites hébergés
seul les segments de code utilisés sont compilé (compilation partielle) les mécanisme de cache code interne au moteur Zend sont justement optimisé pour travailler en mode partagé.

pour ce qui est du dispatch il y a plusieurs étapes le front contrôleur se charge de déterminer quel contrôleur et quelle action
puis il donne la main au contrôleur pour préparer le traitement de l'action (constituer tout le contexte d'exécution)
puis il exécute l'action
ensuite il prépare la réponse et rends la main au front contrôleur
qui se charge de terminer proprement le travail.

le travail de dispatching du front contrôleur et du contrôleur sont donc complémentaires. il n'y a là aucune perte d'énergie que tu fasse faire tout par le front contrôleur ou découpé en plusieurs partie l'ensemble du boulot reste à faire

reste la phase de compilation effectivement si tu n'a qu'une seule méthode dans le front contrôleur pour le dispatch tu ne comile que cette partie. avec une méthode dans le contrôleur tu en compile deux.

mais contrairement à ce que tu dis il n'y en a pas une dans chaque contrôleur la méthode dispatch est commune à tous les contrôleur et n'est donc compilée qu'une fois.
il n'y a que si tu surcharge cette méthode que la version surchargée sera compilée lors de sa première exécution. (rien ne t'empêche si tu doit la surcharger dans tout tes contrôleur de te faire une classe App_Controlleur_Action dérivée de Zend_Controller_Action) ainsi ta version surchargé n'est compilée qu'une fois.

pour ce qui est des pre et post dispatch tu n'en mets que si tu a besoin là encore tu peut les mutualiser pour n'avoir qu'un endroit ou tu les écris.

en se qui concerne les pre et post dispatch dans les pluggins je ne vois pas comment tu t'en passerait.
par exemple j'utilise DOJO j'indique à mon contrôleur que je vais l'utiliser en ajoutant le pluggin pour que dojo fonctionne il faut ajouter quelque bricoles  dans l'entête de façon systématique. le pré dispatch va pouvoir ajouter au contexte de mon action les fonctionnalité de dojo que le plugin me mets à dispos puis lorsque l'action est terminé le post vas pouvoir ajouter les entête en fonction des éléments dojo que j'ai utilisé

et si j'utilise jquery ou ou autre plugin il en va de même.

maintenant si je n'ai pas de pre et de post dispatch dans les plugin le predispatch ne peut mettre dans mon contexte les éléments nécessaire je serais donc obligé dans chaque action de le faire à la main le code du pre dispatch qui est validé testé et compilé une fois je vais devoir l'écrire dans toutes les actions il sera donc moins sur et compilé dans toutes les actions pareil pour le post dispatch.

il comme aujourd'hui je veux que mon développeur n'ai pas à préparer lui-même le contexte (ni écrire le post traitement) et que je n'ai pas les notion de pre et post dispatch dans les plugins la seule solution est de mettre tous les pre et post dispatch dans la classe de base des contrôleurs je compilerais donc qu'une fois mais pas seulement les élément dont j'ai besoin mais l'équivalent de tous les pre et post dispatch de tout les pluggin. perte d'énergie mais aussi énorme difficulté d'évolution (il devient vite impossible de concevoir un plugin puisqu'il faut toucher au classes de bases.)

les pre et post dispatch sont donc un gain de souplesse et de performance contrairement à ce que tu pense.

Je ne sais pas comment tu as fait pour obtenir 11 seconde sur le premier chargement même avec de très grosse appli on ne dépasse jamais les 3s

pour la vue soit ton action produit quelque chose en réponse et tu as une vue et donc il faut charger le view renderer soit tu n'a pas de réponse (redirect) ou tu passe par un autre mécanisme que la vue (envoi d'un fichier par exemple) et tu place le noViewRenderer et il n'est pas chargé.
mais la encore le view renderder n'est chargé et compilé qu'une fois pour toutes les actions.

mieux sur un hébergement mutualisé si la lib Zend est partagé entre les sites hébergés la classe n'est compilé qu'une fois pour tous les sites qui la partage. le loader du moteur ne faisant que placer un handler dans le contexte du site.

A+JYT

Commence par le chapitre "Performances" de la doc

j'ai déja tous essayé, metadata cache, Effacer les appels de require_once avec find et sed, optimisation de l'include_path ...

PS : j'hésite a utiliser le fichier de cache des inclusions du PluginLoader, car je n'ai pas trouvé de réel gain.
Ces Class sont toujours inclu pour n'importe quel action.

déjà le moteur Zend ne compile pas en C mais en ByteCode et je ne sais pas ou tu as vu que ce n'était pas fait pour le mutualisé

nul part, c'était une question je pensé que le php était compilé en C d'abord.

les pre et post dispatch sont donc un gain de souplesse et de performance contrairement à ce que tu pense.

je suis d'accord qu'un traitement PreDispatch et PostDispatch est indispensable, mais au niveau des plugins uniquement, pas au niveau des controllers. donc plus besion du dispatch dans zend Controller action, mais juste $dispatcher->$action(); dans le dispatcher standart. (j'ésite a faire des modifs )

Je ne sais pas comment tu as fait pour obtenir 11 seconde sur le premier chargement même avec de très grosse appli on ne dépasse jamais les 3s.

je sais, je comprend pas non plus, d'ou ma question, a première vu, j'ai des bon résultat chez infomaniak, mais chez OVH, j'ai c'est fameuses 11 secondes, pas tous le temps. Si vous avez des idées de test, je suis preneur.

En ce qui concerne le View renderer, c'est un helper, donc pour moi optionnel, alors qui si on veut afficher une vu, il est essentiel. j'aurait pensé qu'en natif zend afficher une vue sans "l'aide" du view renderer.

Merci encore Sekaijin de cette superbe explication !

Dernière modification par baboune (28-04-2009 19:34:12)

baboune a écrit:

non, c'est en ligne

APC est actif par défaut chez OVH ? Utilises-tu Zend_Date ?

Hello,

Essayes dans ton .htaccess :

SetEnv ZEND_OPTIMIZER 1

A+

Info : Le seul hébergeur activant APC sur PHP en mutualisé que je connaisse est Nexen.