Skip to content
This repository has been archived by the owner on Jul 5, 2020. It is now read-only.

Support chunked request and response http dependency tracking #62

Closed
abaranch opened this issue Mar 22, 2016 · 1 comment
Closed

Support chunked request and response http dependency tracking #62

abaranch opened this issue Mar 22, 2016 · 1 comment

Comments

@abaranch
Copy link
Contributor

If response or request is chunked duration reflects time only from beginning of the request till first chunk received/posted.
Related issue: #58

Repro:
Create web app that is doing:

protected void Page_Load(object sender, EventArgs e)
        {
            HttpContext.Current.Response.BufferOutput = false;
            HttpContext.Current.Response.Write("Chunck 1");
            HttpContext.Current.Response.Flush();

            Thread.Sleep(10000);

            HttpContext.Current.Response.Write("Chunck 2");
}

Create an app that does a request to that app like this:

var address = new Uri("http://localhost/Component2/Default);
var response = await new HttpClient().GetAsync(address);

Tracked dependency duration will be much less than 10 seconds.

It is not related to having StatusMonitor but rather to instrumenting GetResponse that fires when headers are sent. We need to instrument some other functions that read response and sum together all the durations.

@lmolkova
Copy link
Member

Today we use following HTTP dependency tracking mechanisms:

  1. .NET Fx: DiagnosticSource. The end event is fired when HttpResponseMessage is disposed i.e. after response is read. The issue is not relevant
  2. .NET Fx: profiler: we instrumented OnEndGetResponse
  3. .NET Core DiagnosticSource

For both p2 and p3 there are caveats.
HttpClient methods have an overload that takes HttpCompletionOptions that specify if the response should be read and buffered before returning the result. By default it is set to ResponseContentRead, i.e. response streams are buffered (up to some huge size).
So by default, we track time to last byte.

However, users can (and should for huge responses) supply HttpCompletionOptions.ResponseHeadersRead and then response body is not read or buffered before the user explicitly reads it. This is out of ApplicationInsights control and for now, users should track this extra time manually with StartOperation.

I'm closing this issue for now, as there is no work planned to address it. Please upvote and reopen if this affects you.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants