Capture du temps d'exécution du serveur ASP.Net sans latence réseau

Question

Je dois capturer le temps qu'ASP.net prend pour exécuter chaque requête de page dans mon application, mais j'ai besoin d'exclure toute latence réseau. Je capture actuellement les temps de rendu en utilisant la classe StopWatch et en démarrant le chronomètre pendant la méthode OnInit du cycle de vie de la page et en l'arrêtant après la fin de la méthode Unload. Il semble que la méthode Unload inclue le temps qu'il faut pour envoyer la requête au client, incluant ainsi toute latence internet/réseau. Quel est le dernier point possible que je pourrais arrêter le chronomètre dans le cycle de vie de la page qui ne comprendrait pas le temps qu'il faut pour envoyer la demande au client. Serait-ce directement avant l'événement Unload?

Question connexe: Est-ce que ASP.net finit de générer la réponse avant qu'elle ne commence à être envoyée au client? Ou commence-t-il à envoyer de manière asynchrone, alors que la réponse est en train de se former? J'utilise actuellement ASP.Net 2.0 avec IIS 5.

Je possède ce code dans une classe que toutes mes pages héritent de:

readonly Stopwatch _serverExecutionTime = new Stopwatch(); 

protected override void OnInit(EventArgs e) 
{ 
    _serverExecutionTime.Start(); 
    base.OnInit(e); 
}  

protected override void OnUnload(EventArgs e) 
{ 
    _serverExecutionTime.Stop(); 
    base.OnUnload(e); 
} 

MISE À JOUR

J'ai essayé de capturer le temps d'exécution à la fin de la méthode OnRender, au début de la méthode OnUnload et à la fin de la méthode OnUnload. Dans les trois cas, la différence de temps était d'au plus 1 milliseconde. Même en testant cela depuis un client en Europe vers un serveur aux USA, les temps étaient identiques. Donc je pense qu'il me manque quelque chose ici.

Answer 1

Si Response.BufferOutput est défini sur true, alors .Net attendra que le traitement de la page soit terminé avant de renvoyer le html au client.

Si c'est faux, alors .Net commence à renvoyer des données dès qu'il le peut.

Response.Flush va normalement vider le tampon. La meilleure façon que j'ai vu pour tester les performances du site tout en ignorant la latence est d'avoir la machine qui fait la demande sur le même segment de réseau que le serveur. Généralement branché sur le même routeur/commutateur. À ce stade, vous aurez suffisamment diminué la latence pour que ce ne soit qu'une petite partie de vos calculs. Notez que vous ne voulez pas tester directement sur le serveur lui-même, car cela entraîne la séparation du temps de traitement pour exécuter votre client.

MISE À JOUR (des commentaires)
Ce fut un peu plus d'un commentaire. Jon, Êtes-vous sûr de ne pas avoir déjà éliminé la latence en tant que facteur? Pour le détecter, vous devez vous assurer que votre cache Web local et votre cache DNS sont effacés avant d'exécuter chaque test. Si tout cela est mis en cache et que la quantité de données restantes est relativement faible, cela ne fera pas vraiment la différence en ce qui concerne le serveur. Disons que la partie non-cacheable de la page est seulement 4KB. Vous ne remarquerez pas beaucoup de différence entre une connexion de 2 Mo par rapport à une ligne RNIS dans la vitesse de la page.

Vous pouvez vérifier this question pour voir comment tester différents niveaux de latence. Je sais que vous voulez éliminer toute latence en tant que facteur, mais vous pourriez envisager d'attaquer ceci d'un point de vue différent. À savoir, vérifier la différence entre une latence élevée et une connexion à faible latence. Cela devrait vous donner une bonne quantité d'informations afin de tenir compte de ces valeurs des valeurs que vous voulez vraiment.

Answer 2

Il suffit d'activer le suivi ASP.NET: http://msdn.microsoft.com/en-us/library/ms972204.aspx Il affiche le temps d'exécution sur chaque méthode et pour la page entière.

Answer 3

Le fichier journal IIS contient le temps passé à traiter la demande. Cela inclurait n'importe quel temps nécessaire pour appeler .Net que votre méthode n'enregistrerait pas.