Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add SocketsHttpHandler requests-queue-duration metrics #88981

Merged
merged 4 commits into from
Jul 17, 2023

Conversation

MihaZupan
Copy link
Member

Contributes to #88384

Following #88893, this PR adds the http-client-requests-queue-duration counter (final name TBD).
Includes the same tags as other connection counters: protocol, scheme, host, and port.

@MihaZupan MihaZupan added this to the 8.0.0 milestone Jul 17, 2023
@MihaZupan MihaZupan requested review from antonfirsov and a team July 17, 2023 05:29
@MihaZupan MihaZupan self-assigned this Jul 17, 2023
@ghost
Copy link

ghost commented Jul 17, 2023

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

Contributes to #88384

Following #88893, this PR adds the http-client-requests-queue-duration counter (final name TBD).
Includes the same tags as other connection counters: protocol, scheme, host, and port.

Author: MihaZupan
Assignees: MihaZupan
Labels:

area-System.Net.Http

Milestone: 8.0.0

Comment on lines +37 to +42
tags.Add("protocol", versionMajor switch
{
1 => "HTTP/1.1",
2 => "HTTP/2",
_ => "HTTP/3"
});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume it makes more sense to conform to other connection metrics and existing event counters, but note that request metrics log HTTP/1.0 if HttpRequestMessage.Version is 1.0. Is it worth a comment?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it makes sense for requests to log 1.0, but for connections, we only really have HTTP/1.1 that we share between 1.0 and 1.1 requests.
Added a small comment.


ValueTask<Http3Connection> connectionTask = GetHttp3ConnectionAsync(request, authority, cancellationToken);

if (HttpTelemetry.Log.IsEnabled() && connectionTask.IsCompleted)
if (requestsQueueDurationEnabled && connectionTask.IsCompleted)
{
// We avoid logging RequestLeftQueue if a stream was available immediately (synchronously)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused by this comment. It states that We avoid logging RequestLeftQueue, but then Http3Connection.SendAsync requests a new timestamp before OpenOutboundStreamAsync and actually logs it.

(And is it actually good that OpenOutboundStreamAsync is part of the "request queue duration" measurement?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It used to be that we were able to synchronously open an output stream, and if that happened we would skip logging this event.
This changed in #67859, such that OpenOutboundStreamAsync will always yield, so we would always log the event.
With that, I agree this comment here no longer makes sense. I've removed it and the few lines of logic around it.

@MihaZupan
Copy link
Member Author

Test failure is #87477

@MihaZupan MihaZupan merged commit 9ffdb53 into dotnet:main Jul 17, 2023
@ghost ghost locked as resolved and limited conversation to collaborators Aug 16, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants