Introduction à l'instrumentation asynchrone Java

New Relic pour Java inclut un ensemble de méthodes API pour l'instrumentation personnalisée de l'activité asynchrone. Ceci est particulièrement utile pour instrumenter l'activité asynchrone dans un framework non pris en charge, mais vous pouvez également utiliser l'API pour ajouter instrumentation au framework pris en charge. Ce document explique comment l'activité asynchrone se produit et comment fonctionne le moniteur asynchrone New Relic .

opérations asynchrones

Avec un modèle de programmation synchronous, les tâches de programmation sont généralement exécutées dans un ordre spécifique. Une tâche doit être terminée avant que la tâche suivante ne commence, et chaque tâche empêche la tâche suivante de se terminer.

Asynchronous la programmation utilise un modèle non bloquant, de sorte que les tâches peuvent être exécutées en parallèle. Les tâches exécutées de manière asynchrone sont complètement indépendantes les unes des autres dans leur exécution et leur initialisation. Étant donné que le code asynchrone ne s'exécute pas dans un ordre spécifique, toute la puissance de traitement du serveur peut être utilisée plus efficacement et le débit de l'application augmente.

Asynchrone et commutation de thread

Pour les applications qui utilisent le traitement asynchrone, thread-switching correspond au moment où un programme ou une tâche passe d'un thread à un autre. Comprendre ces entrelacements asynchrones peut vous aider à décider quelles méthodes doivent être instrumentées.

Voici un exemple de méthode avec un contrôleur qui effectue requests externes en parallèle. Ces requests s'exécutent de manière asynchrone, de sorte que chaque requête s'exécute indépendamment des autres et getScoreAsync() revient immédiatement après avoir été appelée. Cela permet au thread demandeur de continuer à faire requests pendant que getScoreAsync() effectue un appel externe et envoie une réponse.

@ResponseBody
@RequestMapping("getScores", method = RequestMethod.Get
    produces = "text/plain")
public String getCreditScores(@RequestParam(name = "uids") uids) {
    return Arrays.stream(uids.split(","))
                 .parallel()
                 .map(Integer::valueOf)
                 .map(uid -> getScoreAsync(uid))
                 .collect(Collectors.toList());}

Certaines de ces requests seront traitées avant d’autres. Certains pourraient même terminer après que le thread demandeur soit passé à d’autres tâches :

Dans l'UI APM, sur la vue en cascade des détails trace, l'UI affiche l'activité asynchrone comme se chevauchant sur l'axe x horizontal.

Asynchrone et temps de réponse

Response time est défini comme la durée d'une transaction du point de vue du demandeur. Pour les applications asynchrones, le temps de réponse est souvent inférieur au temps total de transaction. C'est parce que les méthodes n'ont pas besoin d'attendre que toutes les méthodes précédentes soient terminées avant de revenir. Étant donné que les tâches peuvent être différées, l’application peut tirer parti de ses ressources limitées et traiter les choses plus rapidement.

La ligne de temps de réponse du graphique vous donne plus d'informations détaillées sur le comportement perçu et la vitesse de votre application que le temps total de transaction Web :

instrumentation personnalisée avec l'APIasync

Pour implémenter l’instrumentation personnalisée du travail asynchrone, consultez le guide de l’API asynchrone de l’agent Java. Pour obtenir des informations générales sur l’utilisation de l’API de l’agent Java, consultez le guide de l’API de l’agent Java.