Augmentez le débit avec RESTEasy Reactive dans Quarkus 2.2

Quarkus a, depuis ses débuts, fourni des fonctionnalités de base pour le codage de programmes Java dans des styles à la fois impératifs et réactifs. Avec la nouvelle version 2.2, Quarkus continue de s’améliorer en termes de fonctionnalités liées au réseau, de programmation réactive et d’intégration avec le bus d’événements Eclipse Vert.x. Par exemple, RESTEasy Reactive dans Quarkus est une nouvelle implémentation JAX-RS basée sur la couche Vert.x qui atteint un débit beaucoup plus élevé en gérant les événements réactifs sur le thread d’E/S non bloquant.

La version Red Hat de Quarkus 2.2 fournit un support de production pour les extensions RestEasy Reactive, avec des fonctionnalités supplémentaires :

• Traitement des requêtes multiparties/formulaires
• Exécuter une méthode non bloquante par défaut
• Détermination de la stratégie de dispatch par signatures de méthode
• Fournir un tableau de bord des scores de performances pour les points de terminaison réactifs

Ces nouvelles fonctionnalités améliorent les performances lors du développement d’applications réactives.

Cet article montre comment vous pouvez améliorer les performances d’une application réactive Quarkus à l’aide des fonctionnalités RESTEasy Reactive et de l’interface utilisateur Quarkus Dev. Téléchargez le référentiel depuis GitHub pour suivre ce didacticiel.

Vérifier les points de terminaison réactifs REST dans l’interface utilisateur de Quarkus Dev

Tout d’abord : exécutez Quarkus Dev Mode à l’aide de la commande Maven suivante dans le répertoire de votre projet où vous avez cloné l’exemple :

$ ./mvnw quarkus:dev

presse d après le démarrage de l’exemple d’application et affiche les messages suivants :

--
Tests paused
Press [r] to resume testing, [o] Toggle test output, [h] for more options>

Un nouveau navigateur Web s’ouvrira pour accéder à l’interface utilisateur de Quarkus Dev, illustrée à la Figure 1. Dans la zone RESTEasy Reactive, cliquez sur Scores des points finaux.

Vous serez alors redirigé vers la console de scores REST de Quarkus, qui affiche le comportement de quatre points de terminaison réactifs REST avec des scores et des couleurs (voir Figure 2).

Notez que deux points de terminaison ont un score de 100 avec la couleur verte, mais le /hello() point final a un score de seulement 33 en rouge et le /hello/stream/{count}/{name} point final a un score de 66 en jaune. Avant de rechercher pourquoi deux points de terminaison ne fonctionnent pas correctement, effectuons un test local pour voir s’ils fonctionnent correctement.

Exécutez ce qui suit curl commandes pour appeler les deux points de terminaison réactifs REST. Pour le /hello point final, saisissez :

$ curl localhost:8080/hello
hello 

Pour le /hello/stream/{count}/{name} point final, saisissez :

$ curl localhost:8080/hello/stream/3/daniel 
data:hello daniel - 0 
data:hello daniel - 1 
data:hello daniel - 2

Ces commandes doivent être complètes sans erreurs. Retournez au tableau de bord des scores dans l’interface utilisateur de Quarkus Dev et cliquez sur OBTENIR /Bonjour. Les scores de détail apparaîtront comme indiqué dans la figure 3.

Trois mesures montrent si une application réactive REST peut être optimisée davantage. Par exemple, le hello le point de terminaison est optimisé uniquement pour la mesure des ressources. Cela signifie que le point de terminaison est accessible et renvoie une sortie réussie, que vous avez déjà testée localement. En revanche, les mesures Writer et Execution montrent des échecs avec 0% scores.

Réglez les points de terminaison lents pour optimiser les performances

Ouvrez le ReactiveGreetingResource.java fichier dans le src/main/java/org/acme/getting/started répertoire et jetez un œil à la hello() méthode:

@GET
@Produces(MediaType.TEXT_PLAIN)
public Object hello() {
return "hello";
}

Le type de retour de la méthode est actuellement défini avec un type de Object. Il doit être spécifié en tant que String pour éviter toute conversion d’objet inutile lors de l’exécution réactive de l’application. Par conséquent, mettez à jour le type de retour comme indiqué dans l’extrait suivant (le changement est surligné en gras) :

@GET
@Produces(MediaType.TEXT_PLAIN)
public String hello() {
return "hello";
}

Sauver la ReactiveGreetingResource.java , puis rechargez la page du tableau de bord dans l’interface utilisateur Dev. Vous devriez constater que les performances se sont améliorées car la mesure Writer a été corrigée et le score est passé à 66, comme le montre la figure 4.

E/S non bloquantes

Résolvons le problème de performances restant dans le hello() méthode, indiquée par la mesure d’exécution. RESTEasy Reactive, dans la version Red Hat de Quarkus 2.2, détermine automatiquement si une méthode particulière s’exécute sur un thread d’E/S non bloquant de manière asynchrone ou sur un thread de travail de manière synchrone, en fonction de la signature de la méthode. Les hello() la méthode renvoie un String signature qui distribue un thread de travail bloquant. Le thread bloquant réduit les performances de traitement réactif par rapport au thread d’E/S non bloquant.

Par conséquent, vous devez remplacer la stratégie de répartition par défaut pour lui faire utiliser un thread d’E/S non bloquant, en utilisant le @NonBlocking annotation. Retournez au ReactiveGreetingResource.java fichier et ajoutez un @NonBlocking annotation comme suit :

@GET
@Produces(MediaType.TEXT_PLAIN)
@NonBlocking
public String hello() {
return "hello";
}

Sauver la ReactiveGreetingResource.java fichier, puis rechargez la page du tableau de bord dans l’interface utilisateur de développement. Vous devriez maintenant avoir 100 scores partout, grâce à l’optimisation du hello() les performances de la méthode (Figure 5).

Réparons maintenant l’autre point de terminaison, /hello/stream/{count}/{name}. Déplacez-vous vers le greetingsAsStream() méthode dans le ReactiveGreetingResource.java déposer:

@GET
@Produces(MediaType.SERVER_SENT_EVENTS)
@RestSseElementType(MediaType.TEXT_PLAIN)
@Path("/stream/{count}/{name}")
@Blocking
public Multi<String> greetingsAsStream(int count, String name) {
return service.greetings(count, name);
}

La signature de la méthode est déjà spécifiée Multi pour envoyer un thread d’E/S non bloquant. Cependant, un inutile @Blocking L’annotation apparaît dans la méthode, remplaçant la stratégie de répartition par défaut. Par conséquent, vous devez supprimer cette annotation ou la commenter. Mettre à jour le greetingsAsStream méthode comme indiqué dans l’exemple suivant :

@GET
@Produces(MediaType.SERVER_SENT_EVENTS)
@RestSseElementType(MediaType.TEXT_PLAIN)
@Path("/stream/{count}/{name}")
// @Blocking
public Multi<String> greetingsAsStream(int count, String name) {
return service.greetings(count, name);
}

Enregistrez le fichier et rechargez la page des scores dans l’interface utilisateur Dev. Vous devriez maintenant avoir 100% marque partout parce que le greetingsAsStream() méthode a été optimisée, comme le montre la figure 6.

La figure 7 montre que vous avez optimisé les performances de tous les points de terminaison.

Comment démarrer avec Quarkus

Cet article a montré comment les développeurs optimisent les applications réactives avec Quarkus dans la phase de développement en boucle interne. La version 2.2 fournit également des fonctionnalités impressionnantes pour améliorer la productivité des développeurs, notamment des tests continus, des améliorations de l’interface de ligne de commande (CLI) Quarkus et de l’interface utilisateur de développement, ainsi que des services de développement.

S’abonner à bit.ly/danielohtv pour apprendre le développement d’applications cloud natives avec Kubernetes.