Comment choisir le nombre de threads maximum pour un conteneur de servlets HTTP?

Question

Je développe un service Web reposant qui s'exécute en tant que servlet (utilisant des IO bloquantes) dans Jetty. Déterminer le réglage optimal pour le nombre maximal de threads semble difficile.

Existe-t-il une formule recherchée pour déterminer le nombre maximal de threads à partir de caractéristiques facilement mesurables du reste de la configuration?

Answer 1

Très simple et primitif:

max_number_of_threads = number_cPUs * C

Où C dépend d’autres facteurs de votre application: -)

Posez-vous les questions suivantes:

• Votre application nécessitera-t-elle beaucoup de ressources de processeur (C inférieur) ou attendra-t-elle le plus souvent un troisième système (C supérieur)?
• Avez-vous besoin de temps de réponse plus courts (C plus bas) ou pouvez-vous servir plusieurs utilisateurs à la fois, même si chaque demande prend plus de temps (C plus élevé)?

D'habitude, je règle C plutôt bas, par ex. 2 - 10.

Answer 2

Non, il n'y en a pas. Maintenez votre nombre de threads limité et sous contrôle afin de ne pas dépasser les ressources système. La limite de Java est généralement de 100 à 200 threads en direct.

Pour ce faire, utilisez les exécuteurs de java.util.concurrent .

Answer 3

Je comprends qu’au moment où cette question a été posée, Servlet 3.0 n’était pas sorti. Mais je pensais que je devrais enregistrer, dans cette question, la possibilité d'effectuer un traitement asynchrone dans le conteneur Servlet à l'aide de Servlet 3.0. Cela peut aider quelqu'un qui rencontre cette question. Inutile de dire que pour Servlet 3.0, il existe suffisamment de ressources pour indiquer que les threads de servlet principaux sont maintenant moins sous pression! Et Jetty a des équivalents asynchrones, au cas où on ne voudrait pas utiliser l’API Servlet 3.0 en tant que telle.

Answer 4

La réponse dépend du nombre maximum de connexions simultanées que vous comptez gérer. Vous devez autoriser autant de threads que de connexions attendues.

andreasmk2 est incorrect concernant le nombre de threads. J'ai exécuté des applications avec 1 000 threads et je n'ai rencontré aucun problème avec les ressources système. Bien sûr, cela dépend des spécificités de votre système. Vous rencontriez une limitation système et non une limitation Java .

Answer 5

Mon problème est que je ne sais pas comment prévoir raisonnablement le nombre de connexions simultanées. Vraisemblablement, à un certain point, il vaut mieux refuser de nouvelles connexions que de tout ralentir car il y a aussi des demandes en cours de traitement.

Il est difficile de simuler des charges de travail réalistes, c'est pourquoi je recherche une formule déjà recherchée par quelqu'un d'autre.

(La limite supérieure évidente est la taille maximale du segment de mémoire divisée par la quantité de mémoire minimale requise pour traiter une demande, mais cela reste difficile à mesurer dans un environnement avec un ramasse-miettes.)

Answer 6

Merci. Je lis ceci car il n’ya pas de formule facile. : - (

(Mon application est un validateur HTML5. Parfois, elle attend clairement sur des serveurs externes. Cependant, il est difficile de savoir quand elle est liée au processeur, seule ou via le ramasse-miettes.)