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.
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.
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:
- Page load timing process (detailed information about page load timing, sometimes referred to as real user monitoring or RUM)
- Configuring request queue reporting (configuration instructions for New Relic agents)
- Request queue server configuration examples (configuring the request queue HTTP header with Apache, Nginx, Varnish, F5 load balancers, etc.)