Retour d'expérience cakePhp

24 réponses

Page 12

Auteur	Message
superfc \| Florent Membre Inscrit le : 01/07/2006	# Le 05/10/2006 à 19:36 Pour un forum, le cache est implémentable assez facilement. Mais les gens trouvent ça trop compliqué à mettre en place. Pourtant, c'est simple, un nouveau post signifie qu'on vide le cache du topic, du forum et de la liste des forum. Pour e-farm, c'est vrai que ça ne peut pas du tout s'appliquer. Mais y'a du contenu que tu peux mettre en cache, comme le design utilisateur, un cache de 20 minutes ça fait déja gagner beaucoup en performance. A chaque fois que le mec gagne de l'argent ou rembourse sa banque ou un truc comme ça, tu vides le cache. Enfin, tout ça pour dire, on peut en faire quasiment partout. Après l'intérêt est pas forcément évident. Mais en terme de performance, ça devrait vraiment changer quelque chose. Si vous mettez /tmp en tmpfs (en mémoire vive quoi), vous pouvez stocker des infos là dessus et y accèder est quasi instantanné. Genre, imaginez une fonction méga simplifiée (c'est important que la lecture soit simplifiée pour des caches) où on stocke des infos répétitives Le code est sans doute faux, mais il décrit le principe de cache de design : function get_cache( $info ) { $valeur = @file_get_contents( '/tmp/cache_'.md5( $info ) ); return $valeur; } function put_cache( $info, $valeur ) { return file_get_contents( '/tmp/cache_'.md5( $info ), $valeur ) } /* En fait, il vaut mieux spécifier un temps d'expiration et le rentrer dans la base de données SQL pour qu'un programme à côté se charge de vider les caches dépassés. C'est pas "précis" mais très rapide. / et après : $design = get_cache( 'design_user_'.$_SESSION['user_id'] ); if ( ! $design ) { ob_start(); readfile( $design ); $design = ob_get_contents(); ob_end_clean(); put_cache( 'design_user_'.$_SESSION['user_id'], $design); } ob_start(); / travail de génération de la page * genre : * if ( $_GET['page'] == 'help' ) require('pages/help.php'); * / $page = ob_get_contents(); ob_end_clean(); $design = str_replace( '<!-- page -->', $page, $design); echo $design; Ca peut sembler lourd en travail mémoire, mais ce qui coûte en PHP c'est le chargement et l'appel des fonctions, plus on le réduit plus on y gagne. Donc c'est à mon avis très rapide. C'est applicable pour la pub, pour les messages diffusés, les fiches utilisateurs, les classements, etc. Autant de requêtes SQL et de travail PHP à ne pas faire. Et là où c'est bien sur le plus efficace c'est sur les sites composés à 70% de visiteurs et 30% de membres, on peut les différencier sans grande difficultés et offrir du cache aux visiteurs et du contenu généré en live aux membre. Dans les caches, on peut très bien structurer avec serialize et unserialize. Bref, les caches coûtent un peu en développement mais servent toujours. Florent Clairambault* - http://florent.clairambault.fr Gtalk : superfc@gmail.com
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 05/10/2006 à 21:28 Heu ,pour ma part, j'utilise deja allegrement le cache sur les forums Mais c'est pas la reponse à tout Le dynamique genere plein de traitements Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 06/10/2006 à 17:48 On met aussi plein de trucs en cache dans des fichiers, mais pas en serialize() qui est lent à unserialize(), on recrée le code PHP correspondant (via une fonction maison). Tiens, d'après mes tests la méthode var_export / include était beaucoup plus lente que le serialize / unserialize... probablement du à la complexité du parser PHP. Et ce, même avec eAccelerator. Et d'ailleurs à ce sujet, cette méthode ruine le travail du cache d'opcode, qui se retrouve alors avec des dizaines de milliers de scripts à gèrer au lieu de la centaine de départ. Mais il s'agissait probablement de PHP 4.3 ; avec les nouvelles versions il en est peut-être tout autrement. As tu conservé tes benchs ? daevel : infogérance et conseil \|\| moi
superfc \| Florent Membre Inscrit le : 01/07/2006	# Le 06/10/2006 à 18:46 J'ai du mal à comprendre. Ce qui est lent en PHP c'est le fait que ce soit un script. Chaque déclaration de variable, fonction ou classe et chaque appel de fonction/méthode est lent. Un serialize ou un serialize, ça travaille en code machine, donc rapide. Un include, ça execute du script, donc lent. D'ailleurs, les sessions fonctionnent avec du serialize et c'est très rapide. Bref, ça m'intéresserait aussi que tu donnes des chiffres, parce que à mon avis un unserialize par passage de référence, ça doit aller très très vite (plus qu'un include d'un tableau équivalent). Florent Clairambault - http://florent.clairambault.fr Gtalk : superfc@gmail.com
erwinol \| Erwin Membre Inscrit le : 09/05/2005	# Le 09/10/2006 à 09:48 De mémoire, la sérialisation/désérialisation d'objets en Java est très lente. J'en avais donc naturellement déduis qu'il vallait mieux l'éviter en PHP ... une déduction trop vite faite apparemment

Auteur

Message

superfc | Florent
Membre

Inscrit le : 01/07/2006

# Le 05/10/2006 à 19:36

Pour un forum, le cache est implémentable assez facilement. Mais les gens trouvent ça trop compliqué à mettre en place. Pourtant, c'est simple, un nouveau post signifie qu'on vide le cache du topic, du forum et de la liste des forum.

Pour e-farm, c'est vrai que ça ne peut pas du tout s'appliquer. Mais y'a du contenu que tu peux mettre en cache, comme le design utilisateur, un cache de 20 minutes ça fait déja gagner beaucoup en performance. A chaque fois que le mec gagne de l'argent ou rembourse sa banque ou un truc comme ça, tu vides le cache.

Enfin, tout ça pour dire, on peut en faire quasiment partout. Après l'intérêt est pas forcément évident. Mais en terme de performance, ça devrait vraiment changer quelque chose.
Si vous mettez /tmp en tmpfs (en mémoire vive quoi), vous pouvez stocker des infos là dessus et y accèder est quasi instantanné.
Genre, imaginez une fonction méga simplifiée (c'est important que la lecture soit simplifiée pour des caches) où on stocke des infos répétitives

Le code est sans doute faux, mais il décrit le principe de cache de design :



function get_cache( $info ) {

    $valeur = @file_get_contents( '/tmp/cache_'.md5( $info ) );

    return $valeur;

}



function put_cache( $info, $valeur ) {

    return file_get_contents( '/tmp/cache_'.md5( $info ), $valeur )

}

/* En fait, il vaut mieux spécifier un temps d'expiration et le rentrer dans la base de données SQL pour qu'un programme à côté se charge de vider les caches dépassés. C'est pas "précis" mais très rapide.

*/



et après :

$design = get_cache( 'design_user_'.$_SESSION['user_id'] );

if ( ! $design ) {

    ob_start();

    readfile( $design );

    $design = ob_get_contents();

    ob_end_clean();

    put_cache( 'design_user_'.$_SESSION['user_id'], $design);

}



ob_start();

/* travail de génération de la page

 * genre : 

 * if ( $_GET['page'] == 'help' ) require('pages/help.php');

 *

 */



$page = ob_get_contents(); ob_end_clean();

$design = str_replace( '<!-- page -->', $page, $design);

echo $design;

Ca peut sembler lourd en travail mémoire, mais ce qui coûte en PHP c'est le chargement et l'appel des fonctions, plus on le réduit plus on y gagne. Donc c'est à mon avis très rapide.

C'est applicable pour la pub, pour les messages diffusés, les fiches utilisateurs, les classements, etc. Autant de requêtes SQL et de travail PHP à ne pas faire. Et là où c'est bien sur le plus efficace c'est sur les sites composés à 70% de visiteurs et 30% de membres, on peut les différencier sans grande difficultés et offrir du cache aux visiteurs et du contenu généré en live aux membre.
Dans les caches, on peut très bien structurer avec serialize et unserialize.
Bref, les caches coûtent un peu en développement mais servent toujours.

Florent Clairambault - http://florent.clairambault.fr
Gtalk : superfc@gmail.com

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 05/10/2006 à 21:28

Heu ,pour ma part, j'utilise deja allegrement le cache sur les forums
Mais c'est pas la reponse à tout
Le dynamique genere plein de traitements

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 06/10/2006 à 17:48

On met aussi plein de trucs en cache dans des fichiers, mais pas en serialize() qui est lent à unserialize(), on recrée le code PHP correspondant (via une fonction maison).

Tiens, d'après mes tests la méthode var_export / include était beaucoup plus lente que le serialize / unserialize... probablement du à la complexité du parser PHP. Et ce, même avec eAccelerator. Et d'ailleurs à ce sujet, cette méthode ruine le travail du cache d'opcode, qui se retrouve alors avec des dizaines de milliers de scripts à gèrer au lieu de la centaine de départ.

Mais il s'agissait probablement de PHP 4.3 ; avec les nouvelles versions il en est peut-être tout autrement. As tu conservé tes benchs ?

daevel : infogérance et conseil || moi

superfc | Florent
Membre

Inscrit le : 01/07/2006

# Le 06/10/2006 à 18:46

J'ai du mal à comprendre. Ce qui est lent en PHP c'est le fait que ce soit un script. Chaque déclaration de variable, fonction ou classe et chaque appel de fonction/méthode est lent.

Un serialize ou un serialize, ça travaille en code machine, donc rapide. Un include, ça execute du script, donc lent. D'ailleurs, les sessions fonctionnent avec du serialize et c'est très rapide.

Bref, ça m'intéresserait aussi que tu donnes des chiffres, parce que à mon avis un unserialize par passage de référence, ça doit aller très très vite (plus qu'un include d'un tableau équivalent).

Florent Clairambault - http://florent.clairambault.fr
Gtalk : superfc@gmail.com

erwinol | Erwin
Membre

Inscrit le : 09/05/2005

# Le 09/10/2006 à 09:48

De mémoire, la sérialisation/désérialisation d'objets en Java est très lente.

J'en avais donc naturellement déduis qu'il vallait mieux l'éviter en PHP ... une déduction trop vite faite apparemment

Page 12

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.