Ce débat n'a pas lieu d'être, car il ne s'agit pas du tout d'améliorer les performances de ZF sur une machine en Développement mais plutôt en Production...
de ne pas trop faire dévier le sujet.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Ce débat n'a pas lieu d'être, car il ne s'agit pas du tout d'améliorer les performances de ZF sur une machine en Développement mais plutôt en Production...
Mes articles - Zend Certified Engineer (PHP + Zend Framework)
Ressources PHP - Ressources Zend Framework - Cours et tutoriels pour apprendre PHP - Forum PHP
Pour revenir sur le FrameWork en lui même, il faut quand même reconnaître qu'il est lourd en mode MVC. Mais cela est du au modèle MVC en lui-même. J'ai testé Symphony hier soir, CakePHP et ZF en refaisant des tests. Déjà l'optimisation du BootStrap est essentielle. J'ai trouvé CakePHP plus performant, Symphony aussi.
Mais à mon goût, Symphony n'a pas la fluidité de ZendFramework ni son adaptabilité. Je le connais mal, donc veuillez m'excuser si je raconte des sornettes, mais je trouve le modèle plus figé.
CakePHP est moins utilisé, la communauté est moins forte, et cela a beaucoup d'importance à mes yeux. Il est plus rapide, mais à première vue, il est moins abouti.
J'hésite sur bien des solutions. Full ZF ou Cake+ZF ou Symphony+ZF . Je pense partir sur la première solution car en analysant le code source des applications, on remarque déjà que Zend développe pour être rapide. Il y a bien des exemples en ce sens. Le plus visible est la connexion paresseuse. Si dans le BootStrap, vous ne faites pas l'erreur d'appeler la connexion directement, alors les performances augmente Par exemple, dans un forum, toutes les pages de messages (Votre message a bien été enregistré, cliquez ici, etc..., etc..., ) n'établiront pas de connexion.
Il est évident qu'un hello World ira toujours plus vite avec un echo qu'avec un FrameWork !
Je ne veux pas partir en Troll, mais ca veut dire quoi 3000 acces in the same time. Cet angliscisme me fait penser à ses commerciaux de SSII qui viennent me vendre leur boite à grand coup de "Business Intelligence" et de "IQ" ou de "Benchmark goals". (Pour information : Business Intelligence = espionnage commercial).
Code : Sélectionner tout - Visualiser dans une fenêtre à part <?php echo 'hello World'; ?>
Je dis cela car votre serveur pour répondre à 3000 requêtes HTTP par seconde, il est clairement sous-dimensionné et sa description ne me fait pas du tout pensé à un serveur de production, mais à un puissant PC de bureautique (mais pas de développement) connecté à un serveur de fichier. Déjà pour les machines de développement nous ne choisissons pas de processeur monocoeur ; surtout avec Apache, un serveur web multithread, ce serait dommage de payer si cher un P4 3Ghz pour si peu. Éloigner les disques entraine une perte de performance à moins de sécuriser et de blinder (au sens de protection contre les interférences) le réseau et d'établir tous les accès disque en UDP et non pas en TCP.
Ce que je veux dire n'apparait pas constructif, et semble être une méchante critique sans fondements. Je suis embêté ce n'est pas ce que je veux. Je reformule alors : Pour optimiser les performances, il faut agir sur plusieurs facteurs :
La connexion au réseau Internet du serveur (Fibre optique ou plusieurs lignes dédiés
D'expérience, quand j'auditais des entreprises, voilà comment je fonctionnais :
1- La BDD, c'est là que je me focalisais car j'arrivais en deux trois jours à multiplier les performances par 1000 (lisez les derniers cours de SQLPro, il y a des exemples flingrants et je parle pas du consultant beta qui multiplie les index)
2- Je me porte sur le réseau et sa connexion à la BDD
3- Sur la façon de développer, là, au contraire, il ne faut pas privilégier les performances. Il faut privilégier la maintenabilité du code ! Une fois le code fonctionnel, alors oui, on peut optimiser les quelques actions qui rament. Car cela coûte bien plus cher au client, comme à la SSII et à un éditeur de logiciel, de maintenir une application au code obscur que de maintenir un code hiérarchisé (et donc un développement via un framework)
4- Sur le serveur et sa connexion au serveur de fichier (franchement évitez de déporter les fichiers pour une appli web).
5- Sur le serveur en lui-même
Mais généralement, les performances gagnées par les points 1, 2 (parfois 4) satisfaisaient mes clients. Optimiser le point 3 quand on n'utilise pas un framework c'est très long, trop long au tarif journalier d'un auditeur. La solution consiste à bien paramétrer le cache, mais là je passais le relai à un regretté collègue extrêmement compétent.
En clair, l'utilisation d'un FrameWork fait gagner du temps de développement et du temps de maintenabilité au prix des performances. Ces performances sont vite comblée par un serveur plus puissant. Et même un serveur 10.000 euros plus cher est amorti dès qu'il vous fait gagner seulement 20 jours/hommes en développement.
Je confirme, il faut absolument optimiser la BDD, c'est à dire la connexion physique et l'utilisation logique (nombre de connexions maxi, nombre de threads qui traitent ça ).
Coté MySQL, il existe des caches de requêtes, des hooks sur les requêtes les moins performantes, différents types d'index et de moteurs de stockages ( très importants ), sans compter le proxy et tout le tralala
Coté applicatif, Zend_Db_Profiler peut être utlisé pour mettre en place un cache de requêtes ou de résultats (avec Zend_Cache)
Nous avons, dans le cadre d'un projet, effectuer des tests de performances et des benchmarks sur Zend Framework.
Je me permets de vous publier l'article que j'ai rédigé, dont la source sont ces tests.
Il est apparu que ZF était lourd, très lourd, à telle point que sur une application non optimisée et un serveur pas optimisé, il devenait le goulet d'étranglement à la place de la base de données. Ce fut un constat assez étonnant.
Toutefois après pas mal de modification sur l'infrastructure, on a pu trouver une configuration machine et applicative qui tiennent la route même sur des sites nécessitants de supporter une charge importante.
Je me permets donc de poster l'adresse vers cet article en espérant que cela pourra vous intéressé et je réponds volontier à vos remarques et questions :
http://www.wowww.ch/index.php?post/2...-et-benchmarks
@Dvyne : Je ne crois pas avoir vu le code source de l'application utilisée pour le stress test, est-il possible de le diffuser ? Cela me semble fondamental pour la validité de l'article (qui serait édifiant si ce code source était rendu public).
Mes articles - Zend Certified Engineer (PHP + Zend Framework)
Ressources PHP - Ressources Zend Framework - Cours et tutoriels pour apprendre PHP - Forum PHP
Ca va malheureusement pas être possible du tout. C'est un projet client, pas du tout OpenSource ou quoi que ce soit de ce genre.
Toutefois, sans publier le code, je peux ajouter un chapitre pour décrire l'applications ou alors y ajouter une trace modules Zend et fonction php utilisées. Genre un profiling XDebug...
Je vais voir ce qui est possible de faire.
Toutefois, je pense pas qu'il faut se focaliser sur le code. L'optimisation de ce dernier n'apportera pas les 25, 50 ou 100% d'amélioration qui ont été obtenus via les modifications serveur réalisées.
Je qualifie l'optimisation du code de moyenne et décrit l'application comme étant de type backoffice. Mais l'optimisation côté serveur, sur une application plus lourde, conduira aux mêmes conclusions.
Bien entendu, je comprends l'intérêt de savoir ce qui est "plus lourd" que l'application utilisée afin de déterminer précisément le nombre de connexions concurrentes nécessaire sur un nouveau projet.
Je vais voir si un profiling XDebug suffit à déterminer ça.
Je crois que tu as répondu à l'une de mes questions : il y a des accès base de données, donc des échanges TCP/IP. Est-ce que tu as mesuré ces échanges, sais-tu quel impact ils ont sur les résultats du benchmark ?
Mes articles - Zend Certified Engineer (PHP + Zend Framework)
Ressources PHP - Ressources Zend Framework - Cours et tutoriels pour apprendre PHP - Forum PHP
J'ai un doute :Envoyé par Yogui
MySQL se trouve effectivement sur le serveur cible. Donc pas d'échange TCP/IP bien que je ne sache pas réellement comment "localhost" est géré dans ces cas là. Toutefois, je vois mal comment les accès TCP/IP peuvent interférer de manière marquée sur les benchmarks.
Mais oui, l'application a des accès DB, des contrôles de droits, la récupération de données dans la dite DB, du traitement de données pour l'affichage, etc... Il utilise Zend_View, Z_Layout, Z_Date, Z_Pagination, des plugins, des helpers, Z_Db, Z_Table, etc, etc...
C'est une bonne question... On peut supposer que de facto les temps de réponses sont augmentés, de manière linéaire.
Après il faudrait pouvoir déterminer si cette augmentation évolue en fonction du nombre de clients ( => de requetes), et comment elle évoluerait.
Ou si cela ne change pas vraiment et reste stable.
J'imagine que cette évolution dépendrait du type de lien entre les machines, à savoir le débit, la qualité du matériel ect.
Mais il y à sûrement d'autres variables ?
Mais on s'éloigne du sujet. Ces paramètres sont indépendants du framework utilisés.
N'oublions pas que Zend_Date est un très gros consommateur de ressources.Il utilise Zend_View, Z_Layout, Z_Date, Z_Pagination, des plugins, des helpers, Z_Db, Z_Table, etc, etc...
Zend_Date, en fait, consomme beaucoup de mémoire tout comme Zend_Locale, Zend_Currency, etc... car elles sont visiblement très mal optimisées à ce niveau. Toutes les "locales" sont chargées en mémoire alors que dans la plupart des cas on en utilisera qu'une. Mais au final, ça a très peu d'impact sur la consommation processeur qui est le plus gros problème du ZF.
Bien entendu, on évitera de faire des nouvelles instances de ces classes en boucle. Et si nécessaire, on préfèrera plutôt la bonnes vieilles méthodes mktime(), date(), strtotime(), etc...
En fait, j'ai l'impression, mais ça reste une impression, que c'est la gestion des classes de PHP5 qui est consommatrice et particulièrement l'utilisation des méthodes magiques telle que __get et __set.
Sur une application standard on peut voir le nombre des appels à ces méthodes grimper en flèche. Par exemple, l'utilisation de Zend_Config_Ini et des branchements récursifs tel que $config->maCategorie->maVariable génère rapidement des centaines d'appels à ces méthodes magiques.
Une telle analyse sur une application peut être réalisée très facilement à l'aide d'un profil XDebug. On y découvrira quelques surprises de taille.
Peut être vaut-il mieux utiliser le bon vieux tableau, si ça peut sauver 5 à 10% des ressources ?
Pour faire une petite parenthèse, CodeIgniter est codé entièrement en PHP4. D'où le gain de performances ? J'en sais rien...
Pour ma part les performances de zf ont étés le seul critère de reproche que j'ai jamais pu lui faire, ce qui ne m'a pas empêcher de le déployer pour plusieurs sites internet mais jamais à fort sollicitation.
___________
Mon site : Serrurier
Plus simplement, a défaut d'être performant en DEV. Quels stratégie de scaling, et d'optimisation sont disponible avec ZF pour la PROD ?
Je pense bien qu'il y à quelques API pour discuter avec memcache apc ect. Mais quid de l'intégration avec les composants du fw ?
Est ce compliqué à implémenter ?
Est ce magique ?
Enfin, sur l'autoloading, c'est un plaie en php.
Mais c'est le côté script qui entre en contradiction avec l'aspect fw amha.
Par rapport à cela il est imaginable de réaliser des optimisations très très efficaces, dont les développeurs ZF sont forts capable je n'en doute pas.
Cependant, sont ils prêt à intégrer cette différenciation (DEV / PROD) et les optimisations / agencements qui vont bien dans leurs fw ? En ont ils simplement envie ?
Ou bien, nous laisseront ils dans des situations comme celle de FB qui en vient (pour un problème terriblement plus crucial, et compliqué, certes) à compiler son application pour la mise en PRODUCTION.
Bonjour,
J'ai fait personnellement une librairie basée sur Zend Framework pour accélerer le développement de mes applications et j'ai donc naturellement vérifié ce que ça donnait en perf.
La librairie utilise un cache en APC (via Zend_Cache) elle même pour ne pas recharger les opérations les plus couteuses (chargement des fichiers de configuration, chargement des traductions, etc.). Quand APC est désactivé le cache utilisé est du type File dans Zend, ce qui bien sur pénalise doublement les performances
Processeurs : PC Intel Dual-Core 2,2Ghz avec 2M de cache
Mémoire : 3Go
OS : Debian
J'ai testé avec la commande suivante : ab -n 100 -c 10 -k
Avec le module APC activé et cache APC : 51 requêtes / secondes
Avec le module APC activé et cache FILE : 44 requêtes / secondes
Avec le module APC activé et sans cache : 42 requêtes / secondes
Sans le module APC avec le cache FILE : 19 requêtes par secondes
Sans le module APC avec le sans cache : 17 requêtes par secondes
Il s'agit de chiffre sans base de données
Bon à priori en mettant optionnel certains paramètres et en ajoutant des optimisations à droit à gauche, j'ai bien monté.
Zend Framework out of the box : 214 requêtes / secondes
Ma surcouche : 167 requêtes / secondes
Si on réactive la sécurité (via Zend_Acl sur les controller) les traductions et Smarty : 125 requêtes / secondes
Smarty a lui tout seul a un coût très élevé je trouve.
Bonjour,
puisque je vois que vous parlez de performance dans ce topic, je me permet de vous poser cette question :
Dans la documentation du Zend Framework, il est précisé que "Les enveloppes de flux de vue dégradent les performances".
Lien vers la page de documentation
Pourriez-vous m'expliquez en quoi les enveloppes de flux dégradent les performances ? (Pour ma part, mis à part les "replace" fait par le biais d'expression régulière, je ne vois pas ce qui pourrait dégrader les performances, mais je n'ai pas idée non plus du coût des preg_replace() utilisé)
J'ai dans l'idée d'utiliser cette enveloppe de flux pour utiliser les short_open_tag quelque soit l'environnement. Mais si la dégradation des performances est trop importante, je préfère laisser tomber. Auriez-vous une idée de l'ordre de grandeur avec laquelle les performances sont affectées ?
Par avance merci pour votre réponse.
Bonjour,
C'est simple :
Sans enveloppe de flux :
- Inclusion du fichier
Avec enveloppe de flux :
- Chargement complet du fichier en mémoire,
- Remplacement des balises <?=,
- Remplacement des balises <?,
- Inclusion du contenu
Le contenu fichier est parcouru trois fois dans son intégralité. A tester, sur des petits fichiers de template ça ne doit pas être gênant.
Ok, merci, c'est bien ce que je me doutais...
Au delà la performance, le gros risque à utiliser cette fonctionnalité est d'éclater la mémoire du serveur.
Qu'est-il conseiller au sujet des short_open_tag ?
Mon hébergeur les autorise, mais étant perfectionniste, j'ai pu lire qu'il était déconseillé de ne pas les utiliser pour ne pas "casser" la portabilité d'un site. Apparemment tout les hébergeurs n'activeraient pas les short_open_tag.
Qu'en pensez vous ?
(Désolez d'enchainer sur cette question qui du coup est un peu hors sujet)
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager