Débat PHP : Améliorer les performances de Zend Framework

Le , par Kioo, Nouveau membre du Club
Bonjour tout le monde, peu de personnes en parle mais il est intéressant de discuter des performances du Zend Framework.

Dans la société pour laquelle je travaille nous avons fait des tests ultra basiques. Et nous sommes arrivés à la conclusion suivante: le Zend Framework n'avance pas, rame la mort même, ...

Nous avons peut-être rater quelque chose, un petit guide sur l'optimisation serait quand meme le bienvenue.

Ci-dessous le code du test
le boot strap, on remarque qu'il n'y a même pas de rendu avec le ViewRenderer mais qu'il y a l'autoload
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
error_reporting (E_ALL) ; 
ini_set ('display_errors','yes'); 
set_include_path('.'. PATH_SEPARATOR . '../library'. PATH_SEPARATOR . '../application/models/'. PATH_SEPARATOR . get_include_path()); 
  
include_once('Zend/Loader.php'); 
Zend_Loader::registerAutoload(); 
 
$frontController = Zend_Controller_Front::getInstance(); 
$frontController->throwExceptions(true); 
$frontController->setControllerDirectory('../application/controllers'); 
$frontController->setParam('noViewRenderer', true); 
 
$frontController->dispatch();
et ensuite le code du controller
Code : Sélectionner tout
1
2
3
4
5
6
 
class IndexController extends Zend_Controller_Action { 
    public function afficherAction() { 
    		echo 'prout'; 
    } 
}
donc rien que le controller et un echo pour afficher 'prout'

hop un petit apache dessus: ab -n 100 -c 10 -k http://adresse_qui_va_bien
on obtient un résultat de environ 3.5 req/s.

Un seul echo dans un script php, on obtient des performance 100 fois supérieure.

Autant dire que pour notre projet utilisé un "truc" avec de telle performance c'est comme se tirer une balle dans le pied voir dans la tête.
Est-ce que les avantages du framework nous font gagner des performances au fur et à mesure de son utilisation ?

Enfin pouvez-vous m'aiguiller, me donner des éléments de réponses ...


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Dvyne Dvyne - Membre à l'essai http://www.developpez.com
le 02/04/2009 à 16:27
Mais on s'éloigne du sujet. Ces paramètres sont indépendants du framework utilisés.
Avatar de vg33 vg33 - Membre expérimenté http://www.developpez.com
le 02/04/2009 à 18:37
Citation Envoyé par Dvyne  Voir le message
Il utilise Zend_View, Z_Layout, Z_Date, Z_Pagination, des plugins, des helpers, Z_Db, Z_Table, etc, etc...

N'oublions pas que Zend_Date est un très gros consommateur de ressources.
Avatar de Dvyne Dvyne - Membre à l'essai http://www.developpez.com
le 02/04/2009 à 20:27
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...
Avatar de serrurierparis serrurierparis - Nouveau Candidat au Club http://www.developpez.com
le 09/02/2010 à 16:33
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
Avatar de kaymak kaymak - Membre chevronné http://www.developpez.com
le 10/02/2010 à 11:25
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.
Avatar de coren coren - Membre à l'essai http://www.developpez.com
le 12/02/2010 à 9:28
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
Avatar de coren coren - Membre à l'essai http://www.developpez.com
le 19/02/2010 à 11:44
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.
Avatar de doudou34 doudou34 - Membre à l'essai http://www.developpez.com
le 11/03/2010 à 14:40
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.
Avatar de gege2061 gege2061 - Rédacteur http://www.developpez.com
le 11/03/2010 à 21:00
Bonjour,

Citation Envoyé par doudou34  Voir le message
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é)

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.
Avatar de doudou34 doudou34 - Membre à l'essai http://www.developpez.com
le 12/03/2010 à 11:44
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)
Avatar de kaymak kaymak - Membre chevronné http://www.developpez.com
le 12/03/2010 à 18:59
ouè enfin, avec une bonne mise en cache tu t'en fous de cela.
Car tu parcourras ton fichier 1 fois toutes les heures / journées / semaine / syncrho.

Encore faut il pouvoir mettre en cache efficacement et sans que cela soit la croix et la bannière.
Offres d'emploi IT
Ingénieur Etudes et Développements PHP5/Zend2
COEMY GROUP - Ile de France - Paris (75000)
Développeur PHP 5 Zend Plateforme Magento
SRIG - Ile de France - Nanterre (92000)
Développeur Front/back Zend
AMETIX - Ile de France - Paris (75000)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Zend Framework