Discussion :

[speedev]

Bonjour,

Petit code de test...

Code :

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

1
2
3
4
5
6
7
8
9
 
# chargement de classes PHP, constantes etc...
 
$deb = microtime(true);
session_start();	
$fin = microtime(true);
echo round(($fin-$deb),4);
 
# suite du code avec Smarty, templates, gestion du cache etc...

Le résultat s'affichant est souvent 0.0001 et même 0..ça me va...

MAIS....Aléatoirement, remarqué d'une page à l'autre, le résultat affiché va dépasser les 0.3 secondes sur mon serveur local. Je trouve ce chiffre assez élevé quand on le compare aux résultats de mes différentes requêtes sql et autres traitements qui eux, ne dépassent pas les centièmes de secondes (0.0x).

J'ai donc testé le code sur le serveur de prod distant (mon hébergeur) et le temps va atteindre jusqu'à 0.8 secondes soit presque 1 seconde pour un session_start() ! Mais toujours aléatoirement cela jongle entre du 0.0002s et du 0.3500 s (3000 fois plus si je ne m'abuse...)

Est-ce selon vous normal ?

Certaines personnes (site PHP.net) ont remarqué qu'un favicon (sur Firefox ) est susceptible de créer des requêtes en double sur le serveur...on a vérifié, le pb est le mm sous IE....de toute façon ça ne dépent que du service PHP en principe.

Pour info : Le session_id(); ne change pas d'une page à l'autre, pas de regénération donc.

Merci par avance pour vos expertises !

[speedev]

Nouveau test incompréhensible.
J'ai mis en commentaire la ligne smarty affichant les templates, elle se trouve en bas de mon code :

Code :

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

1
2
 
//$smarty->display();

Tout le reste du code (requête, traitements php) s'exécute entièrement.

Résultat du echo du chrono est dorénavant toujours égal à 0.0001 ou 0. Je n'ai plus de 0.3 ou 0.8 aléatoires...

Alors ma question : Pourquoi lorsque je désactive l'affichage des templates à l'écran, le temps d'exécution d'un session_start() est modifié ??

Je ne vois aucun rapport entre les opérations à moins que smarty me cache quelque chose...temps de compilation / session_start() ?

[speedev]

J'ai trouvé une nuance étonnante.

Le chrono du session_start() atteint les dixièmes de secondes (0.4s, 0.8s) lorsque j'arrive sur une page depuis un clic sur un lien de type (par exemple) :

Code :

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

<a href="/page-produit">produit</a>

Par contre, le chrono est cohérent (0.0001s voir 0s) lorsque j'arrive sur cette même page depuis une ré actualisation de la page OU BIEN depuis un événement de type :

Code :

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

onclick="document.location.href='/page-produit';"

Je précise ne pas avoir de paramètres en GET ni en POST.

Mais où est la relation avec session_start() ?

[speedev]

Problème résolu !

C'est en regardant les logs d'apache que je me suis aperçu que LA requête d'appel de la page de destination (GET /truc par exemple) était doublée.

Par conséquent les traitements PHP de cette page de destination étaient eux aussi effectués 2 fois...dont le session_start() et d'où son temps d'exécution plus important.

J'ai donc regardé mon code HTML pour savoir d'où pouvait provenir ce double appel et me suis aperçu de la chose suivante :

Code :

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

1
2
3
4
<li onclick="document.location.href='/truc'">
      	<a href="/truc">page truc</a>
</li>

Quand on clique sur le <a href... cela appelle 2 fois la page /truc car l'événement onclick du <li> est lui aussi exécuté... mais on ne s'en aperçoit pas à l'écran.

Initialement je n'avais pas de onclick et en l'ajoutant j'ai oublié de retirer le <a href... qui trainait.

Tant mieux, j'aurai appris quelque chose d'intéressant !

[ThomasR]

Rien à voir, mais c'est quoi l'interet d'avoir un onclick sur un <li> ? Pourrir ton référencement ? Diminuer considérablement l'accessibilité de ton site ?

Je dis ca parce que ca fait plusieurs fois que je vois ce genre de manipulation pour avoir un lien sur tout le <li>, dans ton cas je suppose que tu utilises les <a> mais, desfois que :

POurquoi ne pas faire :

Code :

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

1
2
3
4
 
<li>
<a href="/" title="Accéder a ce lien">Lien</a>
</li>

et

Code :

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

1
2
 
li a {display:block;width:100%;}

[speedev]

Très bonne remarque, j'avais bien mis le <a href... dans un soucis de référencement et c'est le onclick que je devais virer et non pas l'inverse...Sur le coup la recherche du problème rencontré m'a fais partir sur une mauvaise voie, je corrige ça.
Merci.

[speedev]

width:100% ne sert à rien par contre. Un élément de type block prend la taille de son conteneur par défaut.