Limiter le nombre de demandes à un servlet

Question

Nous avons un servlet qui occupe plus de mémoire virtuelle sur le serveur en raison de la logique dont il dispose. Pour cette raison, nous aimerions limiter les demandes simultanées à ce serveur, par exemple, nous ne souhaitons traiter que 10 demandes simultanées. Les autres demandes doivent attendre dans la file d'attente.

Un pool de threads personnalisé peut-il être créé et attribué à ce servlet pour gérer ce scénario? Nous utilisons WebLogic Server 9.2. Ou existe-t-il une meilleure approche pour le faire? Appréciez vos pensées.

Answer 1

  

Un pool de threads personnalisé peut-il être créé et attribué à ce servlet pour gérer ce scénario? Nous utilisons WebLogic Server 9.2. Ou y a-t-il une autre meilleure approche pour le faire? Appréciez vos pensées.

Oui, c'est possible. Au lieu d'utiliser le gestionnaire de travaux autoréglable par défaut (à partir de Weblogic 9.x, les files d’exécution sont remplacées par des gestionnaires de travail pour les pools de threads ¹ ), vous pouvez créer un gestionnaire de travail avec un comme la max-threads-contrainte éventuellement la capacité . Vous pouvez ensuite affecter un servlet à un gestionnaire de travaux spécifique à l'aide de wl-dispatch-policy du fichier de descripteur de déploiement weblogic.xml .

¹ Notez qu'il est toujours possible de activer le modèle de pool de threads WebLogic 8.1 et utiliser des files d'attente d'exécution.

Answer 2

Vous avez besoin de quelque chose devant ou sur la machine hébergeant le servlet, car lorsque les demandes arrivent sur la machine, il est un peu trop tard: des ressources sont déjà utilisées. Vous ne pouvez pas contrôler la demande : vous ne pouvez que réagir et planifier en conséquence.

Vous avez probablement besoin d’un équilibreur de charge, logiciel ou matériel, en fonction des besoins de votre cible. L’équilibreur de charge logiciel peut être simplement un "servlet de répartiteur". avec contrôle de session (par exemple, 10 simultanés au servlet X).

Il existe une autre possibilité: vous "papillon". les demandeurs en émettant un code HTTP approprié. Bien sûr, cela signifie une logique supplémentaire du côté du demandeur ... et elle utilise toujours des ressources du côté serveur.

Answer 3

Vous pouvez équilibrer la charge de sorte qu’il existe un serveur secondaire qui traite toutes les demandes pour le servlet coûteux.

Answer 4

Vous pouvez avoir un compteur statique et une servlet servant uniquement de passerelle vers l'appel de méthode coûteux. Vous devez simplement faire face à une situation de concurrence probable sur ce compteur statique.

Ainsi, vous transformeriez votre servlet actuelle en appel de méthode.

Ensuite, le servlet de passerelle recevra la demande, verra si le compteur est suffisamment bas, puis augmentera. Si plus de 10, alors renvoyer un message d'erreur.

Ce n'est pas une situation idéale, mais si vous mettez des éléments dans une file d'attente, les navigateurs commenceront à expirer après un certain temps ou les utilisateurs s'impatienteront et cliqueront à plusieurs reprises sur le bouton d'envoi, car cela prend trop de temps.

Si vous pouviez utiliser javascript pour envoyer la demande, de meilleures solutions pourraient vous aider.

Answer 5

Sans utiliser d'équilibreurs de charge, etc., il me semble que vous souhaitez découpler la demande du traitement.

par exemple.

1. le navigateur envoie une demande. Le servlet le prend, le met en file d'attente et rend un ticket.
2. La servlet travaillera sur cette demande de travail si les ressources le permettent (à l'aide d'un pool de threads séparé extrayant les éléments de travail de la file d'attente).
3. Le navigateur peut actualiser (re-obtenir) à l'aide de ce ticket et la servlet renverra un résultat approprié (par exemple, ne pas traiter, traiter, traiter).

Ceci est un modèle assez courant. Notez que le navigateur n'est pas bloqué, mais se contente de transmettre la demande, puis effectue des contrôles réguliers pour voir si l'élément de travail est terminé. J'ai utilisé cette méthode avec succès (par exemple) dans le cas où des utilisateurs demandaient des graphiques dont le traitement nécessitait 5 minutes ou plus, et qui utilisaient une bibliothèque native qui n'était pas thread-safe. Dans ce scénario, je devais limiter le traitement à un seul thread, quel que soit le nombre de requêtes simultanées.

Answer 6

J'aime l'idée d'utiliser un compteur statique et de rediriger pour afficher un message d'erreur lorsque le compteur a dépassé une limite.

Si nous pouvions configurer un servlet séparé et que le pool de threads n'autorise que le nombre X de demandes simultanées, toutes les autres demandes seraient placées en file d'attente pour utiliser le prochain servlet disponible. Cette approche génère-t-elle une erreur de délai d'attente? Pouvez-vous s'il vous plaît partager plus de détails à ce sujet? Merci

http://download.oracle.com /docs/cd/E13222_01/wls/docs92/perform/appb_queues.html