J'ai une API qui effectue quatre tâches. Si nous procédons de manière séquentielle, cette API prendra plus de temps.
Pour augmenter les performances, j'ai utilisé le cadre du service Executor et soumis quatre tâches à l'aide du service executor.
Comme je le sais, créer un thread est une opération coûteuse, et dans le service exécuteur, le thread sera créé au moment de la soumission des tâches. Et les threads seront détruits lorsque nous appelons la méthode shutdown du service exécuteur.
Voici le processus de chaque demande dans ce scénario:
Ma question est donc de créer un service exécuteur et des threads dans chaque requête est-il correct ou non? Ou s'il vous plaît laissez-moi savoir une solution alternative à ce problème.
3 Réponses :
Créez un singleton de votre ExecutorService et utilisez cette même instance pour toutes les requêtes. NE le créez PAS encore et encore. Vous devez également limiter le nombre maximum de threads appartenant à ExecutorService pour empêcher votre API REST de faire exploser votre serveur.
Non, il n'est pas judicieux de terminer et de ré-instancier ExecutorService fréquemment. C’est l’intérêt. Créez un pool de threads fixe car vous connaissez déjà le nombre de tâches que vous souhaitez effectuer en parallèle. Découpez également votre gestionnaire de requêtes de la création d'ExecutorService. Notez que vous appelez shutdown (), c'est-à-dire que vous terminez les tâches en cours et n'acceptez aucune nouvelle tâche, ce n'est pas réutilisable, cela vous oblige à rétablir le pool par requête, alors essayez de ne pas mettre fin au pool de threads.
Il est parfaitement normal d'utiliser un pool de threads pour paralléliser le traitement des requêtes entrantes. Mais ce n'est pas bien de créer un nouveau pool de threads à chaque appel d'API.
Pour ce faire correctement, vous devez créer une instance ExecutorService distincte et simplement la réutiliser et l'arrêter uniquement lorsque vous arrêtez l'application.
N'oubliez pas non plus de le dimensionner correctement car s'il est saturé, cela dégradera votre latence au lieu de l'améliorer.
Si je crée un service exécuteur avec quatre threads, avant que la demande ne vienne. Pendant plusieurs appels à l'API, le premier appel utilisera les quatre threads pour exécuter les quatre tâches, et pendant ce temps, toutes les autres demandes seront en attente.
Oui, c'est pourquoi j'ai ajouté une note sur le dimensionnement correct.
Le fait que j'accepte que la création et la destruction du service exécuteur dans chaque appel d'API soit erroné. Le dimensionnement du pool de threads dans ce scénario n'est pas facile, ou l'exécuteur du pool de threads n'est-il pas adapté à ce contexte? Parce que, par exemple, si nous atteignons l'API de repos 1000 fois, quelle sera la taille du pool de threads, ou si ce nombre augmente à 10 millions, quelle sera la taille du pool de threads.
@DeepakGusain en fait, c'est assez facile si vous connaissez les exigences non fonctionnelles du service
Il vaut mieux saturer le ExecutorService que de consommer 100% de ressources cpu et de dégrader les performances de l'ensemble du système.