Request queuing occurs before the request reaches your application (where the agent resides). This is why you need to do some straightforward configuration of the agent and your production hosts to take advantage of this feature.
HTTP header
In order to report request queuing, most New Relic agents depend on an HTTP header set by the frontend web server (such as Apache or Nginx) or load balancer (such as HAProxy or F5). You can configure these frontend servers to set the timestamp in the HTTP header that represents when the request first entered your production infrastructure.
Tip
Set this header as soon after the request enters your infrastructure as possible so that you are less likely to miss performance problems in your infrastructure that occur before the header is set.
Most New Relic agents will interpret an X-Queue-Start or X-Request-Start header and use it to calculate Request Queuing. The agents treat these headers identically. Include a value in the format t=MICROSECONDS_SINCE_EPOCH where MICROSECONDS_SINCE_EPOCH is an integer value of the number of microseconds that have elapsed since the beginning of the Unix epoch (for example, January 1, 1970).
Nearly any frontend HTTP server or load balancer can be configured to add this header. Additional details depend on your specific agent and server configuration. For more information, see the request queue configuration examples.
Go agent
With the Go agent, set either header to record a metric for it.
Java, Node.js, Python, Ruby agents
The most recent versions of the Java, Node.js, Python, and Ruby agents provide more flexibility in the format of the X-Request-Start or X-Queue-Start header. These agents allow the timestamp to be submitted in seconds, milliseconds, or microseconds as an integer or floating point value. These agents also allow the leading t= in the header value to be omitted.
Based on the order of magnitude, these agents automatically interpret the time unit as seconds, milliseconds, or microseconds. New Relic can do this reliably since a millisecond timestamp, interpreted as microseconds, would result in a queue time over 40 years.
Python agent only: When using Apache/mod_wsgi 3.4 or higher, mod_wsgi will automatically insert an equivalent to the X-Queue-Start header into the WSGI environ dictionary for each request. This will mark the specific point in time where Apache first accepted the request. The value set by mod_wsgi will be picked up and used by the Python agent if no separate X-Request-Start or X-Queue-Start header has been manually configured into a web server's frontend or in Apache itself.
.NET agent
The .NET agent does not require (and will ignore) any configuration of HTTP headers to calculate queue time. It works by instrumenting the IIS-queuing mechanism directly and reports queue time as the difference between when the HttpContext constructor executes and when the HttpApplication.BeginRequest event fires.
Request queue time is only reported for .NET Framework applications hosted on IIS (for example: ASP.NET applications). It is not reported for ASP .NET Core applications (targeting .NET Core or Framework), nor for self-hosted OWIN applications.
PHP agent
The PHP agent only supports the X-Request-Start header. This identifies the timestamp in microseconds as an integer, with an optional t= in the header value. To ensure that the header is read properly, check your phpinfo() under the PHP Variables section, and verify that _SERVER["HTTP_X_REQUEST_START"] exists and is in the expected format.
If you are using Nginx, see Request queue server configuration examples for additional information on setting the header.