Recherche:

yep, mais ça c'est bien souvent l'hebergeur qui le controle.

Et puis sur un truc codé comme un goret, le cache d'OpCode ne changera pas grand chose : phpBB est lent qu'eAccelerator soit installé...

Et justement, comme tu ne peux pas mesurer le temps de compilation du script principal, tes résultats sont complètement faux.

Death83 : pour "mesurer" les includes, ta méthode n'est pas bonne : tu ne tiens pas compte du temps de "parsing" du script principal !

Si tu veux vraiment comparer, ce n'est pas via PHP qu'il faut...

Bon, je ré-explique : les connexions persistantes fonctionnent par PROCESSUS, c'est à dire que si ton Apache est configuré pour tourner avec 200 processus, tu auras potentiellement 200 connexions...

Et bien ça n'engage que moi, mais je dirais : absoluement pas.




Je me suis peut être mal exprimé, mais je maintiens à 100% mes dires.

Tu t'avances beaucoup je trouve... :?

Pour les connexions persistantes, c'est quasiment inutilisable en mutualisé. Et sur un dédié, il faut configurer MySQL pour accepter un grand nombre de...

Si tu utilises le format DATE de MySQL, tu pourras faire un grand nombre de calcul directement via MySQL. Et si besoin, tu pourras quand même récupèrer le timestamp UNIX, via la fonction MySQL dédiée...

Je ne sais pas si cela a changé dans les nouvelles versions, mais quand il s'agit d'une petite quantité de données les références sont plus lentes. C'est un des phénomènes curieux de PHP... :?

Sur mon forum j'ai un cache de données, et un cache HTTP.... ça ne pose aucun problème.... quand c'est bien fait.
Et le gain est évidement énorme.

Hello,

oui les commentaires et autres "choses trucs inutiles" ont une légère incidence sur le temps de "compilation". Mais ce n'est pas pour ça qu'il faut les supprimer !!! Le plus sage est plutot...

ça, ça m'a toujours posé problème :? j'ai pris l'habitude d'indenté "à ma sauce", et j'avoue avoir du mal à en démordre...

ça donne :

<?php
function maFonction&#40;&#41; &#123;
instructions
&#125;