Request/Response timing

[i-aakopian]

It would be nice to have a metadata block returned in the response that would include a response time in milliseconds. I find myself having to write a small wrapper around axios to time any requests I make (for metric collection). Would this be a valid candidate for axios?

[rubennorte]

This could be written as a plugin. Something like:

function axiosTiming(axiosInstance) {
  // Store request timestamp in `config`
  axiosInstance.interceptors.request.add(...);

  // Store response timestamp and/or response time in response/error `config`
  axiosInstance.interceptors.response.add(...);
}

I'm not sure this feature is common enough to add it to the core (although it'd be relatively easy to implement and wouldn't have a performance penalty for those not using it).

@mzabriskie, @nickuraltsev, thoughts?

[keystorm]

IMO, this would be great for debugging requests, more so on hybrid apps with less than ideal debugging environments. It would be a good addition to an already must-have like axios!

Cheers.

[HamsterCoder]

Hi, I am trying to implement this myself with the proposed approach with interceptors, but there are a few things I cannot figure out:

I am not sure whether I can add random stuff to config (will it break axios, is there a right place for metadata), e.g:

// Request interceptor
config.requestStartTime = Date.now();

// Response interceptor
response.config.requestTime = Date.now() - response.config.requestStartTime;
response.config.requestId = response.headers['x-request-id'];

[testerez]

Using the interceptors would provide a timing including the request and the parsing. That would be interesting to have a precise timing for the request itself.

[dev101]

This would be a very useful feature, e.g. for instrumenting and monitoring 3rd party API performance.

Ideally, to be compatible with request timing schema:

[Mouvedia]

You would end up with this subset:

• timingStart (fetch or send)
• timings
  • response (readyState 3)
  • end (readyState 4)
• timingPhases
  • download
  • total (alias of timings.end)

[forivall]

Proof of concept for node, as a plugin / interceptors: https://gist.github.com/forivall/cbd363792b5e09c8aa4e8cb5390f8d93

hooks would need to be added for XHR timings.

[pmotyka]

@forivall, thanks for providing this POC code!

Here's some rough steps on how I was able to use it:

Download and unpack .zip of cbd363792b5e09c8aa4e8cb5390f8d93 gist
npm install -g typscript
npm install -D @types/node axios
tsc *.ts

Copy resulting axios-timing.js into your project

const addAxiosTiming = require('./axios-timing').addAxiosTiming;
addAxiosTiming(axiosInstance);

timings data will be available on the response

[AdeOpe]

I tried axios-timing.js but looking under the hood it basically uses interceptors.

The problem with interceptors are they are called before the 'socket' event gets triggered on the http object (probably for good reason i suppose...).
This means if you start the timer using interceptors you are combining both "queuing" time and time actually going out of the door.
However this matters in the use-case when you have maxed out your sockets, but a person wants to report queuing time separate from request time.

100% I agree with @dev101 suggestion.

[numandev1]

here is the demo https://stackoverflow.com/a/62257712/8079868

[jasonsaayman]

Closing this issue as I don't think it will be added to the axios core. If you disagree please re-open

[fguille94]

I disagree, this should be added to the core

[ghost]

I think this should be included in the core as an opt-in feature

[MatthiasKunnen]

In my use case, a large blob is sent to a third-party service and processed before a response is sent. I would like to measure the time between finishing sending the data and the response. This would allow me to differentiate between slow upload (which may be down to network congestion) and slow processing.

[smff]

so? any updates here ... becauce any solution based on interseptors gives wrong data in browser(((