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.
In order to report request queuing, most New Relic agents depend on an HTTP header set by the front-end web server (such as Apache or Nginx) or load balancer (such as HAProxy or F5). You can configure these front-end servers to set the timestamp in the HTTP header that represents when the request first entered your production infrastructure.
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-Request-Start header and use it to calculate Request Queuing. The agents treat these headers identically. Include a value in the format
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 front-end 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.
The C SDK does not support request queuing.
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-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-Queue-Start header has been manually configured into a web server's front end or in Apache itself.
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.
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.