rôle du multithreading dans les applications web
J'utilise Java (Servlets, JSP) depuis 2 ans pour le développement d'applications Web. Au cours de ces 2 années, je n’ai jamais eu besoin d’utiliser multithreading (explicitement, car je sais que les conteneurs de servlets utilisent un système de thread pour servir le même servlet à différentes requêtes) dans n’importe quel projet.
Mais chaque fois que j'assiste à une interview pour un poste de développeur Web (Java), plusieurs questions se posent sur les discussions en Java. Je connais les bases du threading Java, donc répondre aux questions n'est pas un problème. Mais parfois je me demande si quelque chose me manque lors du développement d'une application Web en n'utilisant pas le multithreading?
Ma question est donc la suivante: quel est le rôle de multithreading dans une application Web? Tout exemple où multithreading peut être utilisé dans une application Web sera apprécié.
Merci d'avance.
Le multi-threading peut être utilisé dans les applications Web principalement lorsque les appels asynchrones vous intéressent.
Prenons l'exemple d'une application Web qui active l'état d'un utilisateur sur un réseau GSM (par exemple, active le forfait 4G) et envoie un message de confirmation SMS ou un e-mail à la fin.
Sachant que l’appel Web prendrait plusieurs minutes - surtout si le réseau GSM est sollicité - il n’a aucun sens de l’appeler directement depuis le fil Web .
En gros, lorsqu'un utilisateur clique sur "Activer", le serveur renvoie le message "Merci d'avoir activé le forfait 4G. Votre forfait sera activé dans quelques minutes et vous recevrez un SMS/email de confirmation".
Dans ce cas, votre serveur doit générer un nouveau thread, idéalement à l'aide d'un pool de threads, de manière asynchrone et renvoyer immédiatement une réponse à l'utilisateur.
Flux de travail:
1- L'utilisateur clique sur le bouton "Activer"
2- Le servlet reçoit la requête et active une nouvelle tâche "Activer le plan 4G" dans un pool de threads.
3- Le servlet renvoie immédiatement une réponse HTML à l'utilisateur sans attendre la finalisation de la tâche.
4- Fin de la transaction Http
...
De manière asynchrone, le plan 4G est activé plus tard et l'utilisateur est averti par SMS ou par courrier électronique, etc.
En parlant d'un exemple concret, il y a plusieurs raisons d'utiliser le multi-threading, et je ne voudrais pas embaucher un développeur web qui ne soit pas au courant. Mais au final, les raisons d’utiliser le multi-threading sont les mêmes pour le développement standard et Web: vous voulez quelque chose qui prend du temps (blocage) en arrière-plan pour donner à l'utilisateur une réponse entre les deux, ou vous avoir une tâche qui peut être accélérée en le faisant fonctionner sur plusieurs cœurs. Lorsque le multi-threading est réellement utile, la question est différente.
Situation 1: Un serveur Web qui nécessite un traitement et a un faible nombre de hits/seconde
Le multi-threading (si applicable à l'algorithme) est une bonne chose, car les cœurs inactifs sont utilisés et le threading peut permettre une réponse plus rapide de l'utilisateur.
Situation 2: Un serveur Web qui nécessite un traitement et reçoit un nombre élevé de hits/seconde
Le multi-threading est possible ici, mais comme les cœurs sont généralement occupés par d'autres requêtes, il ne reste plus de ressources pour l'utiliser correctement. En réalité, le fait de répartir la tâche sur plusieurs threads peut même avoir un impact négatif sur le temps de réponse, car la tâche est maintenant fragmentée et que toutes les parties doivent être terminées, mais l'ordre d'exécution avec les threads n'est pas défini. Ainsi, un client peut recevoir immédiatement une réponse, tandis que d'autres peuvent attendre que son dernier fragment soit traité.
Situation 3: Un serveur Web doit effectuer un traitement très long
Ici, le multi-threading est nécessaire, il n'y a pas de moyen de le contourner. Un client ne peut pas attendre des minutes ou probablement des heures jusqu'à ce qu'il reçoive la réponse. Dans ce cas, un système de rappel est généralement implémenté. Par conséquent, chaque tâche dispose d’une "API" qui peut être interrogée pour connaître l’état actuel. La plupart des boutiques en ligne en sont un exemple: vous commandez quelque chose et plus tard, vous pouvez interroger le statut de votre commande.
L'alternative au threading est le processus de forçage, comme le fait Apache dans sa configuration standard. L'avantage est que la charge est répartie sur plusieurs cœurs (principalement applicable à la situation 2) et que le code Web lui-même n'a rien à faire pour utiliser tous ces cœurs, car le système d'exploitation le gère automatiquement. Toutefois, si vous avez une charge déséquilibrée, certains cœurs peuvent être inactifs et les ressources ne sont pas utilisées de manière optimale. Une situation de filetage est presque toujours la meilleure solution, si elle est bien faite. Mais la configuration standard Apache/Tomcat utilise un modèle de thread très obsolète, en créant un thread pour chaque demande. Effectivement, avec un certain nombre de hits/seconde, la CPU est plus occupée par le threading que par le traitement de ces requêtes.
Eh bien, c’est une bonne question et je pense que la plupart des développeurs travaillant dans le développement d’applications Web n’utilisent pas explicitement le multithreading. La raison est assez évidente puisque vous utilisez un serveur d’applications pour déployer votre application, le serveur d’applications en interne. gère un pool de threads pour les demandes entrantes.
Alors pourquoi utiliser explicitement le multithreading? Quel est le besoin pour un développeur d’applications Web de s’exposer au multithreading?
Lorsque vous travaillez sur une application à grande échelle où vous devez traiter plusieurs demandes simultanément, il est difficile de traiter tous les types de demandes de manière synchrone, car un type de demande donné aurait pu traiter de nombreuses tâches susceptibles de réduire les performances de votre application.
Prenons l'exemple d'une application Web qui, après avoir répondu à un type particulier de demande, doit informer les utilisateurs par courrier électronique et SMS. Le faire de manière synchrone avec le thread de requête pourrait réduire les performances de votre application Web. Alors, voici le rôle de multithreading. Dans de tels cas, il est conseillé de développer une application multithread autonome sur le réseau, chargée uniquement de l'envoi de courrier électronique et de SMS.
La navigation multiple dans une application Web peut être utilisée lorsque des actions en parallèle vous intéressent, par exemple, l'extraction de données à partir de plusieurs adresses.
Si je comprends bien, le multi-threading est utilisé dans des situations différentes du thread-pool, qui peut être utilisé pour gérer les demandes de plusieurs clients.