APM tracks the time after a request enters your production systems and before it reaches your application. We call this portion of your request's life cycle request queuing. Depending on the specifics of your production systems, this measurement of time may or may not include an actual queue that requests enter. It may also represent other functions (such as load balancing or internal network latency).
Use request queuing to identify scaling problems
Tracking time spent in request queuing is useful for identifying certain types of performance and scaling problems; for example:
- When your frontend 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 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.
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 frontend 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 frontend 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. Our 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.