APM suit le temps écoulé entre l'entrée d'une demande dans votre système de production et son arrivée dans votre application. Nous appelons cette partie du cycle de vie de votre demande request queuing. Selon les spécificités de votre système de production, cette mesure du temps peut ou non inclure une file d'attente réelle dans laquelle requests entrent. Il peut également représenter d’autres fonctions (telles que l’équilibrage de charge ou la latence du réseau interne).
Utiliser la mise en file d'attente des demandes pour identifier les problèmes de mise à l'échelle
Le suivi du temps passé dans la file d'attente des demandes est utile pour identifier certains types de problèmes de performances et de mise à l'échelle ; par exemple :
- Lorsque votre serveur Web frontal perd du temps à attendre que les travailleurs de l'application soient disponibles
- Lorsque du temps supplémentaire est consacré au réchauffement des travailleurs de l'application après un réveil ou un redémarrage
Vous devez configurer votre agent et votre serveur New Relic pour signaler la mise en file d'attente des demandes. Ensuite, les informations apparaîtront dans le graphique Requests time de l'application sélectionnée pour le Web des transactions (dans la liste Applications de l'APM, sélectionnez l'application), ainsi qu'à d'autres endroits de l'interface utilisateur. La légende du graphique indique quelle couleur représente la mise en file d'attente des demandes.
Calculs Apdex
La mise en file d'attente des requêtes correspond au temps écoulé entre le moment où le navigateur requests du contenu et le moment où il le reçoit. Étant donné que votre score Apdex reflétera ces calculs, vous pouvez choisir de signaler le temps d'attente des demandes séparément ou non. Pour plus d'informations, voir configuration de l'agent.
Décalage de l'horloge
Si le serveur Web frontal (tel que Nginx) et votre application ne résident pas sur le même serveur physique, la mise en file d'attente des demandes signalées peut être affectée par un décalage d'horloge. NTP fournit un excellent moyen de maintenir les horloges des serveurs synchronisées. Cependant, ils continueront à dériver l’un par rapport à l’autre. Étant donné que les agents New Relic s'appuient sur un horodatage défini par le serveur frontal, ils peuvent sur- ou sous-évaluer la mise en file d'attente des demandes si l'horloge de ce serveur n'est pas étroitement synchronisée avec l'horloge du serveur d'applications.
Cela peut sembler être un problème majeur avec cette fonctionnalité ; cependant, il est peu probable que le décalage d’horloge entraîne des pics soudains dans la file d’attente des demandes signalées. Des pics soudains se produisent généralement lorsqu'une application est redémarrée ou est surchargée de requests. Notre expérience montre que les rapports sur les files d'attente de demandes peuvent être utiles pour identifier les problèmes de performances réels, mais assurez-vous de prendre en compte le décalage d'horloge lors de l'interprétation de ces données.