swift-server
provide information about various timings (queue, connect, ...) to user via delegate (or otherwise)
With AsyncHTTPClient, the user currently struggles to calculate some timings. For example what's impossible to calculate accurately at the moment is:
- How long did this request spend in the connection pool queue
- How long did it take to make a connection (if one didn't already exist)
- How long did it take to send the request
- DNS timings
These should be available to a user.
Would it be enough for you if we expose these by adding traces for the individual timings and metrics?
Would it be enough for you if we expose these by adding traces for the individual timings and metrics?
No. These ought to be either observable (by giving the user enough "hooks" in the delegate) or pre-calculated for the user. I think giving the user enough hooks is preferable over calculating a bunch of stuff and surfacing numbers.
Would it be enough for you if we expose these by adding traces for the individual timings and metrics?
No. These ought to be either observable (by giving the user enough "hooks" in the delegate) or pre-calculated for the user. I think giving the user enough hooks is preferable over calculating a bunch of stuff and surfacing numbers.
Seems reasonable but I am would be curious if you have a use-case in mind for these timings besides reporting them to an observability system? Do you intend to steer behavior of an application depending on those timings?
Would it be enough for you if we expose these by adding traces for the individual timings and metrics?
No. These ought to be either observable (by giving the user enough "hooks" in the delegate) or pre-calculated for the user. I think giving the user enough hooks is preferable over calculating a bunch of stuff and surfacing numbers.
Seems reasonable but I am would be curious if you have a use-case in mind for these timings besides reporting them to an observability system? Do you intend to steer behavior of an application depending on those timings?
Today's use case is a parity question. An existing system reports this information to its clients (honestly, don't know what they do with it, maybe better error messages?) and URLSession allows you to calculate it -- AHC doesn't.
Also terminal output like curl etc can do needs timing in a way that tracing etc should not be used.