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.
Alexandre Tranchant
Ing�nieur DevOps pour le Minist�re de l'�cologie
Retrouvez mes articles sur PHP et Symfony
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)
R�pondre avec citation
Partager