Prise en charge asynchrone dans .NET

L'agent instrumente ces HttpClient méthodes asynchrones :

• SendAsync
• GetAsync
• PostAsync
• PutAsync
• DeleteAsync
• GetStringAsync
• GetStreamAsync
• GetByteArrayAsync

L'agent instrumente ces RestClient méthodes asynchrones :

• ExecuteTaskAsync
• ExecuteGetTaskAsync
• ExecutePostTaskAsync

L'agent instrumente ces SqlCommand méthodes asynchrones :

• ExecuteReaderAsync
• ExecuteNonQueryAsync
• ExecuteScalarAsync
• ExecuteXmlReaderAsync

L'agent instrumente ces SqlDataReader méthodes asynchrones :

• NextResultAsync
• ReadAsync

L'agent instrumente ces NpgsqlCommand méthodes asynchrones (Postgres) :

• ExecuteReaderAsync
• ExecuteNonQueryAsync
• ExecuteScalarAsync

L'agent .NET prend en charge l'instrumentation personnalisée de vos propres méthodes asynchrones.

Il est prévu que le temps de réponse soit inférieur au temps total passé dans async-await scénarios d'utilisation. Considérez l’exemple de code suivant pour un point de terminaison Web :

async Task<string> WebEndpointExample() 
{
    await DoSomethingForSomeSecondsAsync(5); //kick off a 5-second-work to be done.
    return "Complete";
}

[Trace]
[MethodImpl(MethodImplOptions.NoInlining)]
private static async Task DoSomethingForSomeSecondsAsync(int seconds)
{
    await Task.Delay(TimeSpan.FromSeconds(seconds));
}

Dans cet exemple de code, il faut environ 5 secondes pour que le WebEndpointExample soit terminé, donc le temps de réponse pour la transaction qui représente la demande au point de terminaison WebEndpointExample sera d'environ 5 secondes.

L'agent capture également le temps « occupé » (le temps pendant lequel la méthode instrumentée s'exécute réellement) de chaque segment individuel qui constitue la transaction. Ce sont WebEndpointExample et DoSomethingForSomeSecondsAsync. Idéalement, le temps d’exécution total des deux segments est égal au temps de réponse (environ 5 secondes).

Il est facile de voir que le temps d’exécution de DoSomethingForSomeSecondsAsync est de 5 secondes. Cependant, le temps d’exécution du WebEndpointExample devrait être proche de 0 seconde. (Cela ne fait aucun travail ; c'est DoSomethingForSomeSecondsAsync awaitde terminer.)

Cependant, l'agent mesure toujours son temps d'exécution à environ 5 secondes. Cela est dû à l'incapacité de l'agent à détecter le temps bloqué (pas le temps CPU) lorsqu'une méthode est awaitpour une autre. Le temps total indiqué est donc de 10 secondes, ce qui est supérieur au temps de réponse (environ 5 secondes).

Dans le même temps, l’agent ne peut pas supposer que l’appel aux méthodes async bloquerait toujours l’appelant pendant toute la durée. L'exemple suivant le démontre :

async Task<string> WebEndpointExample()
{
    var task = DoSomethingForSomeSecondsAsync(5); //kick off a 5-second-work to be done.

    //Do something less than 5 seconds here.

    await task;
    return "Complete";
}

[Trace]
[MethodImpl(MethodImplOptions.NoInlining)]
private static async Task DoSomethingForSomeSecondsAsync(int seconds)
{
    await Task.Delay(TimeSpan.FromSeconds(seconds));
}

Dans cet exemple, le temps de réponse est toujours d’environ 5 secondes, mais le temps d’exécution réel du WebEndpointExample n’est plus d’environ 0.

L'agent .NET n'instrumentera pas les méthodes asynchrones si le legacy ASP pipeline est présent. Étant donné que Microsoft a remplacé le legacy ASP pipeline bien avant l’introduction des méthodes asynchrones, ce problème affecte généralement uniquement les applications créées sous .NET Framework 4.0 ou une version antérieure, puis migrées vers .NET Framework 4.5 ou une version ultérieure.

Pour voir si ce problème affecte votre application et comment le résoudre si c'est le cas, consultez les procédures de dépannage.

L'agent .NET ne prend pas en charge l'instrumentation des méthodes asynchrones dont le type de retour est autre que Task ou Task<T>. L'agent ne prend pas en charge les méthodes async void .

Pour plus d'informations, reportez-vous à la documentation Microsoft sur les types de retour asynchrones:

• Task<TResult> type de retour
• Vide asynchrone
• Types de retour asynchrones généralisés

L'agent .NET n'instrumente aucune méthode .NET qui utilise les styles begin* et end*, à l'exception de l'application WCF. En dehors de cette exception, si votre application appelle ces types de méthodes, l'agent ne créera pas de segments pour elles. Cependant, le reste de vos transactions et segments seront créés correctement.

L'agent .NET ne capture pas les métriques ou les segments limités dans les threads créés manuellement par votre application.

Si votre application appelle des méthodes asynchrones instrumentées, utilisez await plutôt que Task des méthodes liées comme Task.Result() pour attendre les résultats. Dans le cas contraire, l’instrumentation risque de ne pas fonctionner correctement.

En général, évitez d’utiliser Task.Result() lors de l’appel de méthodes asynchrones. Cela peut conduire à des impasses.

Si vous ajoutez votre propre bloc ContinueWith({}) à la promesse renvoyée par une méthode asynchrone instrumentée, cela peut affecter les mesures de synchronisation signalées par l'instrumentation. Par exemple, le temps peut inclure le temps nécessaire à votre ContinueWith pour s'exécuter.

Les services WCF hébergés par IIS n'imbriquent pas correctement le segment WCF sous le segment ExecuteRequestHandler . Les deux segments apparaîtront comme des frères et sœurs dans une trace de transaction, même si leur temps total signalé sera exact.

Les segments d'une trace de transaction ne généreront pas automatiquement de trace d'appels, même s'ils durent plus de transaction_tracer.stack_trace_threshold.