after_deserialization vs after_transmit

[cprieto]

Reading the docs for Intercept (https://docs.rs/aws-sdk-workspacesweb/latest/aws_sdk_workspacesweb/config/trait.Intercept.html) I am a little confused about this regarding after_transmit

The duration between invocation of this hook (before_transmit) and after_transmit is very close to the amount of time spent communicating with the service. Depending on the protocol, the duration may not include the time spent reading the response data.

And now after_deserialization

The duration between invocation of this hook (before_deserialization) and after_deserialization is very close to the amount of time spent unmarshalling the service response. Depending on the protocol and operation, the duration may include the time spent downloading the response data.

We are interested in measuring something close to TTFB vs time to read all data from the stream for the S3 client during requests, and we were looking at the possibility of using an interceptor for it, but I am a little confused regarding where are the scenarios where the response data is included or not.

Maybe somebody could enlighten me about this? or even if my idea or approach doesn't just make sense.

[aajtodd]

We are interested in measuring something close to TTFB vs time to read all data from the stream for the S3 client during requests

The closest you can get here is the time between before_transmit and after_transmit as the docs try to suggest. This won't really be an accurate TTFB though as the time between these phases includes reading all of the HTTP headers from the response as well as any implementation details of the HTTP client handling a request (e.g. connection acquisition time, DNS, etc). In other words the transmit phase is when we hand off the request to an HTTP client to actually send the request and get an HTTP response.

We would like to get an accurate TTFB metric emitted in the telemetry work we are currently doing but we need to coordinate with hyper (I know telemetry is on their radar but I don't know the current status or priority).

For a streaming payload like S3 the payload response isn't handled in deserialize, only other members (e.g. ones mapped to response headers). The time to read the data stream would be something you can measure.

If you aren't too tied to a metric being TTFB and you care mostly about the difference between getting an initial HTTP response and time to read the data then I think you would be able to capture that.

[cprieto]

If you aren't too tied to a metric being TTFB and you care mostly about the difference between getting an initial HTTP response and time to read the data then I think you would be able to capture that.

Thanks @aajtodd I understand before_transmit and after_transmit is currently the closest I could go for TTFB, and right now close enough is more than enough for us :)

For a streaming payload like S3 the payload response isn't handled in deserialize, only other members (e.g. ones mapped to response headers). The time to read the data stream would be something you can measure.

Yeah, I was expecting something like that, thanks!