Discussion :

[heygeo]

Bonjour,
J'ai créé pour ma société un framework qui fonctionne tres bien, hormis pour une chose : la consommation mémoire de mes scripts.
Je suis passé à PHP 5.3, esperant que le garbage collector allait faire du ménage, mais rien de mieux.
Je me suis donc lancé dans une enquète, aidé de mon fidèle assistant memory_get_usage.
Apres une enquete minutieuse, je me rends compte que c'est le code PHP en lui même qui prend plein de mémoire.
Je m'explique : je fais un require sur un fichier PHP un peu gros : 5500 lignes qui occupe 188 Ko sur mon disque.
C'est une classe, il n'y a pas de code interprété à ce moment là.
Et bien la memoire fait immédiatement un bon de 2.3 Mo !
Du coup, comme mon projet est assez gros, une fois que tous les fichiers utiles sont inclus, je ne peux descendre en dessous de 8Mo.
Est-ce normal ?
Merci de vos réponses !

[Oscar Hiboux]

Utilisez-vous PHP via le module Apache, via CGI, FastCGI ?

[heygeo]

Utilisez-vous PHP via le module Apache, via CGI, FastCGI ?

Pardon, j'ai oublié de préciser :

J'appelle le script via Apache tournant sur un serveur Linux.

[Oscar Hiboux]

Es-tu tout de même parvenu à isoler le code problématique ? Essaye de trouver le fragment de code le plus court possible et expose le nous éventuellement...

Sinon, si tu es à l'aise en anglais tu peux jeter un œil à ce billet. Il y a qq idées à prendre (ou laisser) selon le cas.

[heygeo]

Es-tu tout de même parvenu à isoler le code problématique ? Essaye de trouver le fragment de code le plus court possible et expose le nous éventuellement...

Sinon, si tu es à l'aise en anglais tu peux jeter un œil à ce billet. Il y a qq idées à prendre (ou laisser) selon le cas.

Et bien mon problème n'est pas un problème d'execution, mais de chargement du fichier php.

Je fais le test suivant :

Code :

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

<?php echo round(memory_get_usage()/(1024),2)." Ko";?>

J'obtiens 613.81 Ko, ce qui j'imagine est la mémoire utilisée de base par l'interpreteur PHP.

Ensuite j'ajoute une fonction de 1750 instructions dans le fichier :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
<?php
echo round(memory_get_usage()/(1024),2)." Ko";
function toto()
{
	$var="une chaine de caracteres";
	$var="une chaine de caracteres";
 
	[...] 1750 fois en tout
 
	$var="une chaine de caracteres";
}

J'obtiens 1107.12 Ko, c'est à dire que le chargement de ce fichier de 1750 instructions a utilisé 493.31 Ko de mémoire sans même que je n'ai exécuté quoi que ce soit.
Le fichier en lui même fait 18Ko.
Est-ce normal ? J'imagine que PHP fait une sorte de precompilation de mon fichier et stocke ce code précompilé dans la memoire ce qui fait que cela consomme de la memoire alors que rien n'a encore été éxécuté.
Peut-on demander a PHP d'avoir un autre comportement, de ne charger que ce qui est utile = executé ?

Cela m'interesserait que certains fassent le meme test que moi pour comparer les resultats.

Merci !

[Oscar Hiboux]

Dans mon cas PHP tourne sous la forme d'un module Apache dans une machine virtuelle avec pour base Fedora. Le premier test me donne 90,3 Ko, tandis que le deuxième me donne 586,19 Ko.

En réduisant la taille des chaines de caractères la quantité de mémoire diminue, mais assez peu : en passant de "une chaine de caracteres" à "pouet" ça me donne 528,84 Ko.

Pour chaque bloc de 100 instructions que j'enlève je gagne à ~28,2 Ko, soit un total de ~493,3 Ko pour 17,5 blocs, les 90,3 Ko pour le reste, ce qui nous mène à ~583,6 Ko, un résultat assez proche des 586,19 Ko affichés plus haut.

[devuser]

Bonjour,

A part peut être de changer,le comportement du moteur zend (à confirmer ...),je ne pense pas qu'on peut changer le cycle d'exécution du php ...

Mais,pour des cas ou les fonctions/classes,ne sont pas toujours nécessaires à l'exécution,(Par exemple,les fonctions qui sont utilisable si,et "seulement" si on a un résultat précis ou bien évènement de probabilité,...),on peut mettre ses fonctions,dans des page sépares,et utilisé include/require,avec des conditions.

Code php :

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

1
2
3
4
5
6
7
8
9
10
11
12
function _($function,$arg)
{
    if(!function_exists($function)
        include($function.'.php'); // l'autre fichier
    return $function($arg);
}
 
 
 
if($condition) _('toto',$arg);
 
echo round(memory_get_usage()/(1024),2)." Ko";

[kaymak]

Bonjour,
J'ai créé pour ma société un framework qui fonctionne tres bien, hormis pour une chose : la consommation mémoire de mes scripts.
Je suis passé à PHP 5.3, esperant que le garbage collector allait faire du ménage, mais rien de mieux.
Je me suis donc lancé dans une enquète, aidé de mon fidèle assistant memory_get_usage.
Apres une enquete minutieuse, je me rends compte que c'est le code PHP en lui même qui prend plein de mémoire.
Je m'explique : je fais un require sur un fichier PHP un peu gros : 5500 lignes qui occupe 188 Ko sur mon disque.
C'est une classe, il n'y a pas de code interprété à ce moment là.
Et bien la memoire fait immédiatement un bon de 2.3 Mo !
Du coup, comme mon projet est assez gros, une fois que tous les fichiers utiles sont inclus, je ne peux descendre en dessous de 8Mo.
Est-ce normal ?
Merci de vos réponses !

Hello,

3mo c'est peanut pour une application. N'importe quel fw, cms avec un minimum de fonctionnalitée utilise au moins 15 mo par requête.

Aussi dans le cas de l'occupation mémoire par déclaration de classe/fonction il n'y à aucun autre moyen que l'accélérateur (apc, xcache, eaccelerator etc) pour soulager le serveur.
D'ailleurs cela à deux fonctions
1 optimiser l'utilisation mémoire
2 optimiser les cycles CPU.

Le gc n'intervient que, et uniquement, pour les variables déclarées, fonctions lamdba incluses je pense.

a plus

[Oscar Hiboux]

C'est peanut ? Ah... alors parce que beaucoup sont médiocres il faudrait signer également dans ce registre ? 15 Mo / requête ça donne vraiment le vertige !

@heygeo : courage, lâche pas avec ton administrateur, c'est vraiment trivial d'installer APC...

D'expérience unset n'a jamais fait de miracle effectivement, c'est même presque plus une prière qu'une instruction...

[RunCodePhp]

D'expérience unset n'a jamais fait de miracle effectivement, c'est même presque plus une prière qu'une instruction...

Houlà
Quel serait le moyen de détruire des éléments de manière plus efficace alors ?
Les réinitialiser, comme par exemple : $Objet = NULL; ?

[kaymak]

C'est peanut ? Ah... alors parce que beaucoup sont médiocres il faudrait signer également dans ce registre ? 15 Mo / requête ça donne vraiment le vertige !

C'est pas question de faire dans le médiocre ou de donner le vertige. Mais si tu veux intégrer une fonctionnalité, de facto elle possède sa propre définition, donc de facto elle consomme la mémoire.
Plus tu ajoutes de fonctionnalités, plus tu consommes de mémoire.

On pourra toujours me parler de lazy loading, sauf que à un moment, lazy loading ou pas, ta page / script propose N services, qu'il faut charger.
Et donc mettre la définition du programme dans la mémoire pour s'en servir.

@heygeo, oui ce sont les fonctions anonymes.
Je précise ce point parce que je ne sais pas du tout comment c'est géré par php.
Soit comme des variables setable / unsetable, bref un classique, soit comme des fonctions plus persistante faisant en quelque sorte partie de la définition du programme, et qui donc pourrait possiblement ne pas se supprimer facilement de la mémoire allouée avant la fin du script.


Pour les accélérateurs, c'est devenu nécessaire. Et c'est somme toute assez logique de les utiliser.
C'est un compromis acceptable, d'une part on garde la simplicité de déploiement du scripting, d'autre part on bénéficie des améliorations et optimisations d'une pseudo compilation (même si ce n'est pas tout à fait pareil qu'une compilation classique).

[heygeo]

Pour les accélérateurs, c'est devenu nécessaire. Et c'est somme toute assez logique de les utiliser. C'est un compromis acceptable, d'une part on garde la simplicité de déploiement du scripting, d'autre part on bénéficie des améliorations et optimisations d'une pseudo compilation (même si ce n'est pas tout à fait pareil qu'une compilation classique).

Ca m'a lair super. J'ai lu la doc d'APC. Ca me plait.
Ca ne resoud toujours pas mes "problemes" de memoire mais au moins les performances vont s'ameliorer ! :-)
Merci

[heygeo]

En fait, j'ai l'impression que ca consomme moins de mémoire finalement ,
J'arrive à tourner autour de 5Mo, ce qui est bien (mais pas top ;-) )

[heygeo]

Hello,
3mo c'est peanut pour une application. N'importe quel fw, cms avec un minimum de fonctionnalitée utilise au moins 15 mo par requête.

Je trouve cela enorme, mais au vu de mes tests ca ne m'etonne pas.

Aussi dans le cas de l'occupation mémoire par déclaration de classe/fonction il n'y à aucun autre moyen que l'accélérateur (apc, xcache, eaccelerator etc) pour soulager le serveur.
D'ailleurs cela à deux fonctions
1 optimiser l'utilisation mémoire
2 optimiser les cycles CPU.

C'est bien ce que je craignais

Le gc n'intervient que, et uniquement, pour les variables déclarées, fonctions lamdba incluses je pense.

Là je ne comprends pas tout, variables déclarées, c'est à dire ? Perso je declare/initialise toujours mes variables en PHP (j'ai commencé avec du C++ c'est pour ca )
Les fonctions anonymes, c'est nouveau en PHP 5.3 c'est ca ?