Discussion :

[Benjamin Delespierre]

Bonjour à tous.

Je commence à être de plus en plus inquiet à propos des problèmes de performances de mon composant Axiom. Selon les installations, le temps nécessaire au boostrap occupe entre 15% et 40% du processing total...

J'aimerai grandement améliorer ces performances désastreuses. Actuellement, le boostrap consiste en un ensemble de fichiers de configurations PHP lus successivement avant de lancer le routeur, ce comportement est exprimé ici: https://github.com/bdelespierre/php-.../bootstrap.php

J'ai pensé à utiliser un cache pour corriger le problème ou utiliser un fichier unique (INI, JSON ou XML) lu une seule fois et utilisé par les différentes classes mentionnées plus haut.

Selon vous, quelle serait la meilleure façon de procéder ?

[stealth35]

normalement t'as pas a faire de require, avec l'autoloader les classes se chargent suivant le besoin, pour le reste un fichier de conf suffit

[Benjamin Delespierre]

Le but du bootstrap est moins de charger explicitement les librairies que de charger les configurations à l'intérieur desdites classes.

Ex:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
require_once LIBRARY_PATH . '/core/Lang.class.php';
 
Lang::setConfig(array(
    'locale' => 'fr',
    'locales' => array('en', 'fr')
));
 
Lang::loadLanguage();

La plupart des classes du framework portent un méthode statique setConfig prennant un tableau associatif en paramètre. C'est ce fonctionnement que je remets en cause aujourd'hui.

[stealth35]

tu peux faire un ini, le boostrap le lit, si y'a une config dans Lang par exemple il chargera la conf, sinon il fait rien

ou alors faire l'inverse le module fera un getConfig

[Benjamin Delespierre]

J'avais envisagé l'éventualité d'un fichier ini, chargé dans un singleton de config qui serait lu par les modules une fois ceux-ci chargées. Ce qui évite des définitions inutiles si les modules en question ne sont pas utilisés.

As tu tenté de mettre en place une sorte de benchmark (ou profiler) pour savoir quelle partie du boostrap causerait problème, ou serait anormalement lente ?
(Pas mal de FrameWork intègrent ça, sous forme de module ou autre).

Pas la peine de créer des modules pour ça, tu prends Webgrind + Xdebug et tu active le profiling. Sans surprise c'est l'instanciation de PDO qui est le plus lent, suivi des modules utilisant des fichiers sur disque (évidement aussi).

Bref, vu que tous ces modules ne sont pas utilisés à chaque requête, c'est un peu débile de les charger systématiquement.

Ah bon ?
L'autoloader ne se charge t-il pas d'instancier seulement la classe, mais pas de l'inclure ?
(enfin, j'ai toujours compris ça comme cela).

Nan, c'est l'inverse, l'autoloader va chercher et charger la classe (l'inclure en somme) mais pas l'instancier, c'est le boulot de l'appli

[RunCodePhp]

Nan, c'est l'inverse

J'ai dis une bêtise.
C'est pas grave.

Sans surprise c'est l'instanciation de PDO qui est le plus lent, suivi des modules utilisant des fichiers sur disque (évidement aussi).

Donc finalement, il n'y aurait rien d'anormal.
Tu recherche juste un moyen de rendre ce FrameWork plus modulaire : On y charge QUE ce qui est utile.

En tout cas, si tu recherche quelque chose de rapide, de simple tableaux de config seront à mon plus rapide que des INI, XML et consoeurs, ces derniers demandent à être lus/parcourus, même s'il existe des fonctionnalités au coeurs de Php.
Kohana par exemple utilisent des tableaux.
Un premier tableau dans le bootstrap qui liste les modules à charger.
Puis chaque module doit avoir un répertoire config, et là aussi toutes les configs sont dans un tableau.

De plus, quand il s'agit de module présents dans le FrameWork (et non un module perso), les modules du core prévois de configs par défaut (à le pas modifier à ce niveau).
Au bout, par défaut ça charge les configs du core, sinon, ça charge celles qu'on aura personnalisé/redéfinies coté applicatif.


C'est juste pour exemple.
En tout cas c'est extrêmement performant (du moins c'est ce que je remarque).

[grunk]

Quelques pistes de réflexions :

- Le bootstrap est appelé à chaque page (comme le frontcontroller) c'est donc un fichier qui doit aller à l'essentiel.
Au contraire tu y charges tout tes modules. c'est, je pense, la première erreur. Soit utiliser un autoload soit laisser l'utilisateur charger les bonnes classes quand il en a besoin serait déjà pas mal.

le boostrap consiste en un ensemble de fichiers de configurations PHP lus successivement

seconde "erreur" de conception à mon avis. Ton framework devrais pouvoir se suffire à lui même de base , ne pas avoir besoin de fichier de config (ou alors un seul générique).
Encore une fois il faut je pense laisser l'utilisateur modifier le comportement des différents modules en lui laissant accès à différents getter/setter.
perso quand je code et qui faut que je me tape un fichier de config à remplir , ca me gonfle royalement , encore plus si le dit fichier est dans un format à la con.

- J'ai pas vu à quoi ressemblait tes fichiers de config , mais essai de favoriser au maximum des solutiond qui savent être lu nativement par php (json,ini) et qui ne nécessite pas un travail de parsage trop important (xml).

- Profiter de l'intégration de APC dans PHP peut être intéressant (typiquement lire une fois le fichier de conf puis venir chercher les infos en mémoire par la suite)

Pour te donner une idée , le seule fichie rde config d'une appli utilisant mon framework ressemble à ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
[prod]
database.adapter = pdo_mysql
database.params.host = localhost
database.params.username = root
database.params.password = 
database.params.dbname = db
smtp.auth = xxxx
smtp.user = xxx
smtp.pass = xxx
smtp.port = 25
finfo 	  = C:/wamp/bin/php/php5.2.5/extras/magic
root	  = C:/wamp/www/class/
 
[preprod:prod]
db.dsn	  = 'mysql:dbname=intranet_test;host=localhost'
db.pass   =
db.error  = 1
 
[dev]
database.adapter = pdo_mysql
database.params.host = localhost
database.params.username = root
database.params.password = 
database.params.dbname = db
smtp.auth = xxx
smtp.user = xxx
smtp.pass = xxx
smtp.port = 25
finfo 	  = D:/wamp/bin/php/php5.2.5/extras/magic
root	  = D:/wamp/www/class/

Et le bootstrap (si on peut encore l'appeler comme ça) : c'est simplement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Config::register();

qui correspond à la configuration de deux autoloader :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
static public function register()
{
	spl_autoload_register(array(new self, 'autoload_mylib'));
	spl_autoload_register(array(new self, 'autoload_zend'));
}

[RunCodePhp]

Salut

As tu tenté de mettre en place une sorte de benchmark (ou profiler) pour savoir quelle partie du boostrap causerait problème, ou serait anormalement lente ?
(Pas mal de FrameWork intègrent ça, sous forme de module ou autre).

normalement t'as pas a faire de require, avec l'autoloader les classes se chargent suivant le besoin

Ah bon ?
L'autoloader ne se charge t-il pas d'instancier seulement la classe, mais pas de l'inclure ?
(enfin, j'ai toujours compris ça comme cela).