Request time does not take into account connection creation
See original GitHub issueReported in https://line-armeria.slack.com/archives/C1NGPBUH2/p1574122806097100
I believe this is a regression after moving Endpoint selection to the begging of the request. We call startRequest only when about to send the request, but not anymore. This is affecting spans, but I think it also affects our totalDuration metric equally.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:18 (1 by maintainers)
Top Results From Across the Web
Troubleshoot common connection issues to Azure SQL ...
These connection problems can be caused by reconfiguration, firewall settings, a connection timeout, incorrect login information, or failure to ...
Read more >Advanced Usage — Requests 2.28.1 documentation
When you are using the prepared request flow, keep in mind that it does not take into account the environment. This can cause...
Read more >HTTP/1.1: Connections
Servers SHOULD always respond to at least one request per connection, if at all possible. Servers SHOULD NOT close a connection in the...
Read more >Troubleshoot your Application Load Balancers
Troubleshoot issues that you might encounter with your Application Load Balancer.
Read more >Using Connect with Express accounts | Stripe Documentation
Connect Onboarding is the recommended method for creating Express ... Create an Express account and set type to express in the account creation...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

Realized it may not be a regression and there from the start -
startRequesttakes a channel so it could only ever be called after connection is complete. I’m a bit confused since I thought we have heard evidence of people debugging DNS resolution slowness using metrics, but I guess they’ve used server latency instead of client latency to find that.It’ll be quite a refactor to record start timing without a channel 😅
Let me try to take a look into this soon.