Discussion :

[guitoux1]

Salut,

Voilà pour mon projet, je dois mettre en place un compteur de temps de chargement des pages, c-a-d du moment où le serveur reçoit la requête jusqu'au moment où la page à terminée de se chargée sur le client.

Pour ça, j'ai appliqué le fonctionnement suivant :
1) Un HttpModule qui alimente une variable de session avec la date du jour dans l'évènement PreRequestHandlerExecute()
2) Un JavaScript dans les pages clientes qui alimente un champ caché avec la date du jour. Le JavaScript est lancé en fin de page HTML (StartupScript)
3) Dans le page_Load des pages, récupération de la date client et calcul de l'écart entre la date serveur et la date client.

Bon, outre le fait que je fait la différence entre la date serveur et la date client (ça n'est pas la question ici), j'ai un soucis.
Quand je fais ça dans un projet de test, pas de PB tout marche.

Mais une fois dans mon application, ça ne marche plus, je n'ai pas accès aux sessions dans mon HttpModule, que celui-ci implémente IRequiredSessionState ou pas. Je ne comprends pas pourquoi, ça m'énerve. J'ai vu sur différents forum d'autres personnes qui tombent sur ce "bug" d'ASP.Net, à savoir que des fois l'état de session n'est pas accessible dans les HttpModule, et même dans le global.asax (j'ai essayé aussi, marche pas)

Quelqu'un a-t-il une solution ? où alors une autre façon de calculer ce temps ?
Merci de vos réponses.

[Sphax]

Juste une question: a quoi ça sert ?

[guitoux1]

Juste une question: a quoi ça sert ?

Comme le dis le titre : a calculer le temps mis entre la réception de la requête sur le serveur et l'affichage final sur le client.

[lutecefalco]

Tu peux pas utiliser un TimeSpan entre le 1er evt et le dernier evt de ta page?

[Bluedeep]

Tu peux pas utiliser un TimeSpan entre le 1er evt et le dernier evt de ta page?

Ca ne donnerait que le temps entre de traitement serveur de la page; aucun interêt ici.

Il veut le temps entre la réception de la requête HTTP par le serveur et le réception par le client.

[Sphax]

Comme le dis le titre : a calculer le temps mis entre la réception de la requête sur le serveur et l'affichage final sur le client.

Oui d'accord mais ça depend de tellement de paramètres, les performances du serveur, de l'appli, l'heure du client, l'état du réseau etc... que je ne vois pas bien ce que ça indique réellement.

[guitoux1]

Oui d'accord mais ça depend de tellement de paramètres, les performances du serveur, de l'appli, l'heure du client, l'état du réseau etc... que je ne vois pas bien ce que ça indique réellement.

Ca indique le "ressenti" du client face à l'application. Evidement, les résultats doivent être interprétés pour être crédibles. C'est plus au niveau global que les valeurs obtenue sont parlantes, pas pour une requête à un moment t, mais plus de façon générale, combien de temps attend l'utilisateur pour avoir sa page chargée.

[Pongten]

Le problème ne viendrait-il pas d'une restriction de sécurité sur IIS pour le serveur de production ?

[Bluedeep]

Ca indique le "ressenti" du client face à l'application. .

Ben non, si tu travailles avec l'heure client, ça n'indique rien du tout; absolument rien à vrai dire.

Imagine qu'il ait 5 secondes d'écart par rapport à l'heure système serveur(en + ou en -, ce qui est très peu) sur une requête/réponse qui s'exécute en 3 secondes : tes données n'ont plus aucune signification dans ce cas.

Si il me prenait la fantaisie de faire un truc comme cela, je passerais l'heure serveur au client (comme donnée dans la page), et j'utiliserais le javascript pour faire une réponse "hors-bande" (façon AJAX avant que ce nom soit inventer pour l'attribuer à un concept utilisé depuis des années) en renvoyant l'heure serveur vers une page aspx "bidon" (vide) qui ne sert que de récepteur à l'appel hors bande; donc une requête get faite hors bande sur cette page, simplement pour déclencher l'event load et récupérer l'heure serveur de début de requête et la comparer avec l'heure serveur au moment de l'event page_load. A ce moment bien, sur tu annule la requête hors-bande.

Là tu peux avoir des données exploitables, mais en aucun cas tu ne peux en avoir de la maniére dont tu veux procéder.

[lutecefalco]

exact