Request queuing and tracking front-end time

New Relic provides the ability to track the time after a request enters your production systems and before it reaches your application. This portion of your request's life cycle is referred to as request queuing. Depending on the specifics of your production systems, this time may include an actual queue that requests enter, or it may represent other functions (such as load balancing or internal network latency).

Performance and scaling problems

Tracking time spent in request queuing is useful for identifying certain types of performance and scaling problems; for example:

  • When your front-end web server is spending time waiting for application workers to become available
  • When extra time is spent warming up application workers after a deploy or restart

You must configure your New Relic agent and server to report request queuing. Then the information will appear in the selected application's Requests time chart for web transactions (from New Relic APM's Applications list, select the app), as well as other places in the user interface. The chart's legend indicates which color represents request queueing.

screen-request-queue.png
APM > Applications > (selected app) > Monitoring > Overview: Here is an example of the app's Requests response time chart with a request queuing spike after a deployment. The Request Queuing band is bright green.

Apdex calculations

Request queuing is the time from when the browser requests content to the time it receives the content. Since your Apdex score will reflect these calculations, you can select whether to report request queue time separately or not. For more information, see Agent configuration.

Clock skew

If the front-end web server (such as Nginx) and your application do not reside on the same physical server, reported Request Queuing may be affected by clock skew. NTP provides an excellent way to keep server clocks in sync. However, they still will drift relative to each other. Since New Relic agents rely on a timestamp set by the front-end server, it may over- or under-report Request Queuing if the clock on that server is not closely synchronized with the clock on the app server.

This may seem like a major problem with the feature; however, clock skew is unlikely to result in sudden spikes in reported request queuing. Sudden spikes generally occur when an app is restarted or becomes overloaded with requests. New Relic's experience is that request queue reporting can be useful to identify real performance problems, but be sure to consider clock skew when interpreting this data.

For more help

Additional documentation resources include:

Join the discussion about New Relic APM in the New Relic Online Technical Community! The Technical Community is a public platform to discuss and troubleshoot your New Relic toolset.

If you need additional help, get support at support.newrelic.com.