[PHP 5.2] Bootstrap et performances [Résolu]

[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 :

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

[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).

[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]

Envoyé par Benjamin Delespierre

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 :

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 :

Config::register();

qui correspond à la configuration de deux autoloader :

Code :

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'));
}

[Benjamin Delespierre]

Merci de consulter le code des modules concernés par le bootstrap avant de répondre dans ce topic SVP.

Bon on va corriger le tir.

Le bootstrap ne charge pas l'intégralité des modules du framework, l'Autoloader s'en charge au runtime. En revanche, le bootstrap charge les classes à configurer (sans faire appel à l'autoloader pour éviter les appels inutiles).

On se retrouve donc avec un fichier PHP par module à configurer, ce qui devait dans l'idée permettre au programmeur de ne pas charger certains modules (comme RSS ou Log par exemple). Actuellement, la configuration n'est pas portée par un fichier INI ou XML, elle est définie "en dur" dans le fichier de configuration PHP.

Je souhaite changer ce comportement pour que les modules aillent lire leur configuration en best effort sans pour autant introduire une dépendance fonctionnelle entre ces modules et une classe de configuration (et encore moins avec des variables globales, cela va sans dire).

Ensuite, mes modules se suffisent à eux même, il sont, dans la mesure du possible, faiblement couplés entre eux et leur configuration reste optionnelle (seul l'appel à la méthode statique setConfig pour initialiser la conf du module par défaut est mandataire).

Vu qu'un grand nombre de ces classes ne portent que des méthodes statiques, je vais peut être avoir besoin d'utiliser le pattern Singleton (ce sera d'ailleurs pas plus mal s'il faut mettre la conf en cache...)

@grunk

Dans l'exemple que tu propose, comment les modules chargés par l'autoloader lisent leur conf en réalité ?

[rawsrc]

Bonsoir Benjamin,
juste une petite chose en passant :
vu les problèmes que tu sembles rencontrer, es-tu toujours sûr de ça :

Axiom: a lightweight PHP framework

[RunCodePhp]

Je souhaite changer ce comportement pour que les modules aillent lire leur configuration en best effort sans pour autant introduire une dépendance fonctionnelle entre ces modules et une classe de configuration

Ne faudrait il pas prévoir par exemple un fichier config (Php, ini, xml, comme tu veux) dans chaque module de la librairie ? (une sorte de convention).
php-axiom / libraries / captcha / config.php (ou config.ini)
php-axiom / libraries / feed / config.php
... etc ...

La classe chargera alors les configs à ce niveau là.
Enfin, c'est une idée.

[Benjamin Delespierre]

Envoyé par rawsrc

Bonsoir Benjamin,
juste une petite chose en passant :
vu les problèmes que tu sembles rencontrer, es-tu toujours sûr de ça :

Nan plus vraiment

On pourrait remplacer par

Axiom: a lazy completely f*cked up framework

Enfin, si au départ je l'avais qualifié de léger, c'est parce qu'il tiens tout entier sur 16 classes

[grunk]

Envoyé par Benjamin Delespierre

@grunk

Dans l'exemple que tu propose, comment les modules chargés par l'autoloader lisent leur conf en réalité ?

90% de mes modules n'ont pas de configuration , ça ne sert à rien dans mon cas.
Si je prend l'exemple du singleton pdo ou de l'envoi de mail qui eux on besoin d'info supplémentaire pour fonctionner :
Mon fichier ini est lu dans l'index.php (frontcontroller) de l'appli , un objet de config est crée. Selon le besoin cet objet est mis en cache ou non.
Je passe ensuite la "config" supplémentaire à l'instanciation de l'objet concerné.

Par exemple pour utiliser Zend_Db qui est intégré dans mon framework je fait simplement :

Code :

Zend_Db::factory($objConfig->database);

Après mon FW n'est sans doute pas un foudre de guerre niveau performance mais il rempli son role et fonctionne bien sans besoin de quelconque cache.

On peut avoir une idée des tests que tu as réalisé et des résultats ? Tu t'inquiètes peut être pour pas grand chose

[Benjamin Delespierre]

Le mien non plus n'est pas une foudre de guerre, on parle d'une moyenne de 100 à 300 ms par requête...

Exemple: une page du module d'admin comprenant des helpers de vue et des requêtes MySQL dure 325ms (+200 appels) et le boostrap dure à lui seul 147ms (même si on enlève les 55ms de PDO, il nous reste 92ms soit 1/3).

J'ai commencé à écrire des classes pour manipuler des fichiers de conf INI en m'inspirant de Zend_Config_Ini:

Code :

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
<?php
/**
 * Axiom: a lightweight PHP framework
 *
 * @copyright Copyright 2010-2011, Benjamin Delespierre (http://bdelespierre.fr)
 * @licence http://www.gnu.org/licenses/lgpl.html Lesser General Public Licence version 3
 */
 
/**
 * INI Configuration file parser
 *
 * @author Delespierre
 * @package libaxiom
 * @subpackage configuration
 */
class IniConfiguration implements Configuration {
 
    /**
     * INI structure cache
     * @var array
     */
    protected $_ini;
 
    /**
     * INI Tree structure
     * @var ConfigurationItem
     */
	protected $_tree;
 
	/**
	 * Default constructor
	 * @param string $file
	 * @param string $section [optional]
	 * @throws MissingFileException
	 * @throws RuntimeException
	 */
	public function __construct ($file, $section = "common") {
		if (!is_file($file))
			throw new MissingFileException($file);
 
		if (!$ini = parse_ini_file($file, true))
			throw new RuntimeException("Cannot parse $file");
 
		foreach (array_keys($ini) as $key) {
			if (($offset = strpos($key, ':')) !== false && isset($ini[trim(substr($key, $offset+1))]))
				$ini[$key] += $ini[trim(substr($key, $offset+1))];
			if (strpos(trim($key), $section) === 0)
				$section = $key;
		}
 
		$this->_ini = $ini;
		$this->_generateTree($section);
	}
 
	/**
	 * Generates the tree structure using the INI structure
	 * @param string $section
	 * @throws RuntimeException
	 * @return void
	 */
	protected function _generateTree ($section) {
		if (!isset($this->_ini[$section]))
			throw new RuntimeException("Unable to find section $section");
 
		$this->_tree = new ConfigurationItem;
		foreach ($this->_ini[$section] as $key => $value) {
			$p = explode('.', $key);
			$c = $this->_tree;
			while ($k = array_shift($p))
				$c = $c->$k;
			$c->setValue($value);
		}
	}
 
	/**
	 * (non-PHPdoc)
	 * @see Configuration::__get()
	 */
	public function __get ($key) {
		return $this->_tree->$key;
	}
 
	/**
	 * Switch between INI sections
	 * @param string $section
	 * @return IniConfiguration
	 */
	public function switchSection ($section) {
	    $this->_generateTree($section);
	    return $this;
	}
}

Code :

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
<?php
/**
 * Axiom: a lightweight PHP framework
 *
 * @copyright Copyright 2010-2011, Benjamin Delespierre (http://bdelespierre.fr)
 * @licence http://www.gnu.org/licenses/lgpl.html Lesser General Public Licence version 3
 */
 
/**
 * Configuration Item Class
 *
 * @author Delespierre
 * @package libaxiom
 * @subpackage configuration
 */
final class ConfigurationItem {
 
    /**
     * Parameter value
     * @var mixed
     */
    protected $_v;
 
    /**
     * Children parameters
     * @var array
     */
    protected $_c;
 
    /**
     * Value setter
     * @param mixed $v
     * @return void
     */
    public function setValue ($v) {
		$this->_v = $v;
	}
 
	/**
	 * Valxue getter
	 * @return mixed
	 */
	public function getValue () {
		return isset($this->_v) ? $this->_v : null;
	}
 
	/**
	 * Child getter
	 *
	 * Note: if the child doesn't exists, an
	 * empty child will be created and returned.
	 * Thus you will never face an error accessing
	 * an inexisting entry.
	 *
	 * @param string $k
	 * @return ConfigurationItem
	 */
	public function __get ($k) {
		if (isset($this->_c[$k]))
			return $this->_c[$k];
		return $this->_c[$k] = new self;
	}
 
	/**
	 * toString
	 * @return string
	 */
	public function __toString () {
		return (string)$this->getValue();
	}
}

Reste à résoudre le problème de l'injection des paramètres de conf dans les modules à charger "on demand".

[rawsrc]

Bonjour,

Sans avoir la possibilité d'accéder un cache, il est quand même possible d'accélerer le chargement des éléments toujours utilisées dans ton framework. Un peu comme le fait Yii avec son fichier Yiilite.php. C'est un fichier généré automatiquement qui regroupe en un seul bloc toutes les classes nécéssaires au bon fonctionnement de 80 à 90% des classes et fonctionnalités du framework.
Cela n'empêche pas la conservation des classes dans ton arborescence mais tu y gagnes beaucoup en temps de parseur et d'inclusion.
Sans cache tous les moyens sont bons pour gagner en vitesse (et je sais de quoi je parle)
Enfin, je te renvoie à ma classe de minification du code PHP qui elle aussi d'après mes tests sur mon framework fait sacrément économiser du temps au chargement. Regardes ici pour la discussion, et ici pour la source.
Bref, yapuka faire des essais.

[Benjamin Delespierre]

L'idée est séduisante mais je vais devoir t'emprunter l'idée et coder une dérivation de ce travail car mon code doit rester compatible 5.2 et surtout qu'il est publié en LGPL et le tien en GPL.

Mais c'est un concept intéressant, je vais m'en servir.

[grunk]

Envoyé par Benjamin Delespierre

Le mien non plus n'est pas une foudre de guerre, on parle d'une moyenne de 100 à 300 ms par requête...

Exemple: une page du module d'admin comprenant des helpers de vue et des requêtes MySQL dure 325ms (+200 appels) et le boostrap dure à lui seul 147ms (même si on enlève les 55ms de PDO, il nous reste 92ms soit 1/3).

Le temps mis part PDO est assez étonnant. Voila ce que ça donne chez moi , sachant que PDO est en plus instancié par Zend_Db :



En gros 26 ms pour l'instanciation et 4 requêtes , d'où mon étonnement pour tes 50 ms.
Je viens de faire un profiling chez moi et très clairement ce qui me prend le plus de temps c'est le moteur de template (twig) et du coup je tourne également à une moyenne de 300 ms par page. avec un cache sur le template je suis en moyenne à 80ms.

Bon après si tes test on été fait sur une machine peut puissante ou php 5.2 ça peut expliquer cette différence.

[rawsrc]

Envoyé par Benjamin Delespierre

L'idée est séduisante mais je vais devoir t'emprunter l'idée et coder une dérivation de ce travail car mon code doit rester compatible 5.2 et surtout qu'il est publié en LGPL et le tien en GPL.

Mais c'est un concept intéressant, je vais m'en servir.

Je vais te faciliter le travail, j'ai changé la licence en LGPL (donc tu peux rester relax) et pour l'adaptation en PHP 5.2, il te suffit de commenter dans le tableau $noSpaces le T_NS_SEPARATOR qui correspond au séparateur de namespace (PHP 5.3+).
Normalement tout devrait rouler pour ta version.

[stealth35]

on gagne pas grand chose par rapport a un php_strip_whitespace

[rawsrc]

Oui sur un seul fichier c'est sûr mais sur une branche complète d'un framework ou le framwork entier, le gain est énorme.
Ensuite la différence entre un php_strip_whitespace() et la réécriture optimisée du code est certes ridicule en terme de gain mais quitte à faire un outil autant qu'il pousse au-delà de la simple fonction native. D'ailleurs le point de départ est ladite fonction. Tout compte fait et vu que ce fichier minifié n'est pas regénéré à chaque appel, autant qu'il soit très optimisé (ça mange pas de pain).
Avec php_strip_whitespace() tu perds le rendu dans les notations heredoc/nowdoc, dans mon cas c'était problématique, c'est pour ça que je suis parti des tokens bruts en faisant attention à bien préserver cet aspect.