Comment faire pour déterminer le meilleur nombre de threads dans Tomcat?

la "combien de threads problème" est tout à fait une grande et complexe, et ne peut pas être répondu avec une règle simple.

Considérant le nombre de coeurs que vous avez est utile pour les applications parallélisées qui ont tendance à consommer beaucoup de CPU, comme de nombreux calculs et la comme. C'est rarement le cas pour une application web, qui n'est généralement pas monopolisé par le CPU, mais par d'autres facteurs.

Une limitation commune est le décalage entre vous et d'autres systèmes externes, notamment votre DB. Chaque fois qu'une demande arrive, il sera probablement de requête de la base de données un certain nombre de fois, ce qui signifie en streaming quelques octets sur une connexion JDBC, puis d'attendre pour ces octets à arriver à la base de données (même c'est que c'est sur localhost il y a toujours un petit décalage horaire), puis d'attendre pour la DB à considérer notre demande, ensuite, attendre pour la base de données à traiter (la base de données elle-même sera en attente pour le disque de chercher dans une certaine région), etc...

Pendant tout ce temps, le thread est inactif, donc un autre thread pourrait facilement utiliser que les ressources CPU pour faire quelque chose d'utile. Il est fréquent de voir des 40% à 80% du temps passé en attente sur DB réponse.

La même chose arrive aussi de l'autre côté de la connexion. Alors qu'un thread est le vôtre écrit sa sortie vers le navigateur, la vitesse de la connexion du CLIENT peut garder votre fil d'attente à vide pour le navigateur ack qu'un certain paquet a été reçu. (Ceci était une question il y a quelques années, les noyaux récents et les machines virtuelles utilisent plus les tampons pour éviter que votre fils pour la marche au ralenti de cette façon, cependant, un reverse proxy en face de vous serveur d'applications web, même tout simplement un httpd, peut être très utile pour éviter que les gens avec une mauvaise connexion internet à agir comme des attaques DDOS 🙂 )

Compte tenu de ces facteurs, le nombre de threads doit être généralement beaucoup plus que les coeurs que vous avez. Même sur un simple dual ou quad core server, vous devez configurer quelques dizaines de threads au moins.

Alors, qu'est-ce que la limitation du nombre de threads que vous pouvez configurer?

Tout d'abord, chaque thread (utilisée pour) consomment beaucoup de ressources. Chaque fil ont une pile, ce qui consomme de la RAM. En outre, chaque Thread va effectivement allouer des trucs sur le tas à faire son travail, de consommer à nouveau de RAM, et la loi de commutation entre les threads (changement de contexte) est très lourd pour la JVM/noyau de système d'exploitation.

Il est difficile d'exécuter un serveur avec des milliers de threads "en douceur".

Donné cette image, il y a un certain nombre de techniques (principalement: essayer, échouer, tune, essayez à nouveau) afin de déterminer plus ou moins le nombre de threads que vous app aurez besoin de:

1) Essayer de comprendre où votre threads de passer le temps. Il y a un certain nombre de bons outils, mais même jvisualvm profiler peut être un excellent outil, ou un traçage aspect qui produit résumé calendrier stats. Plus ils passent de temps d'attente pour quelque chose d'extérieur, plus vous pouvez générer davantage de threads à utiliser CPU pendant les moments d'inactivité.

2) Déterminer votre utilisation de la RAM. Étant donné que la JVM va utiliser une certaine quantité de mémoire (et notamment la permgen space, généralement jusqu'à une centaine de mégaoctets, de nouveau jvisualvm va dire), indépendamment de combien de fils que vous utilisez, essayez d'exécuter avec un fil, puis dix, puis cent, tout en insistant sur l'app avec jmeter ou que ce soit, et de voir comment l'utilisation du tas va croître. Qui peut constituer une limite dure.

3) Essayez de déterminer une cible. Chaque demande de l'utilisateur a besoin d'un thread pour être manipulés. Si votre temps de réponse moyen est de 200ms par "get" (il serait préférable de ne pas considérer le chargement des images, CSS et autres ressources statiques), puis chaque thread est en mesure de servir 4/5 pages par seconde. Si chaque utilisateur doit s'attendre à ", cliquez sur" chaque 3/4 secondes (dépend, est-ce un jeu par navigateur ou un site avec beaucoup de textes longs?), puis, un thread "servent à 20 utilisateurs simultanés", quoi que cela signifie. Si à l'heure de pointe, vous avez unique de 500 utilisateurs accèdent à votre site en 1 minute, puis vous avez besoin de suffisamment de threads pour gérer cela.

4) essais de Collision de la limite haute. Utiliser jmeter, configurer un serveur avec beaucoup de discussions sur une pièce de rechange de la machine virtuelle, et de voir comment le temps de réponse s'aggrave lorsque vous allez au-delà d'une certaine limite. Plus que le matériel, le fil de la mise en œuvre de l'OS sous-jacent est important ici, mais peu importe ce qu'il va atteindre un point où le PROCESSEUR de passer plus de temps à essayer de comprendre quel thread à exécuter que effectivement en cours d'exécution, et que le nombre n'est pas si incroyablement élevé.

5) Examiner comment les fils aura un impact sur d'autres composants. Chaque thread va probablement utiliser un (ou peut-être plus d'une) connexion à la base de données, est la base de données capable de gérer 50/100/500 connexions simultanées? Même si vous utilisez une fragmenté cluster de nosql, les serveurs, le serveur de la ferme offrent suffisamment de bande passante entre ces machines? Quoi d'autre va s'exécuter sur la même machine avec le web-serveur d'application? Anache httpd? le calmar? la base de données elle-même? un local proxy cache de la base de données comme mongos ou memcached?

J'ai vu des systèmes de production, avec seulement 4 fils + 4 de rechange, fils, cause le travail effectué par le serveur était simplement pour redimensionner les images, de sorte qu'il était près de 100% de temps CPU, et d'autres configuré sur plus ou moins le même matériel avec un couple de centaines de threads, la cause de la webapp a fait beaucoup de SAVON appels vers des systèmes externes et de passer la plupart de son temps à attendre les réponses.

Bureau que vous avez déterminé les env. minimum et maximum de threads optimale pour vous webapp, alors j'ai l'habitude de le configurer de cette façon :

1) Basé sur les contraintes de la RAM, d'autres à des ressources externes et des expériences sur la commutation de contexte, il y est un maximum qui ne doit pas être atteint. Ainsi, l'utilisation de maxThreads de la limiter à environ la moitié ou les 3/4 de ce nombre.

2) Si la demande est raisonnablement rapide (par exemple, il fournit des services web REST que l'habitude de l'envoyer une réponse est de quelques millisecondes), vous pouvez configurer un grand acceptCount, le nombre de maxThreads. Si vous avez un équilibreur de charge à l'avant de votre serveur d'applications web, de mettre un petit acceptCount, c'est mieux pour l'équilibrage de charge pour voir refusés demandes et de passer à un autre serveur que de mettre les utilisateurs en attente sur une déjà occupée.

3) Depuis le démarrage d'un thread est (encore) considérée comme une opération lourde, utilisez minSpareThreads d'avoir un peu de threads prêts lors des heures de pointe arriver. Cela dépend encore une fois sur le type de charge que vous attendiez. Il est bien raisonnable d'avoir minSpareThreads, maxSpareThreads et maxThreads le programme d'installation de sorte que le nombre exact de threads est toujours prêt, jamais repris, et les performances sont prévisibles. Si vous utilisez tomcat sur une machine dédiée, vous pouvez augmenter minSpareThreads et maxSpareThreads sans aucun danger de monopolisant les autres processus, sinon de les ajuster en bas de cause, les threads sont des ressources partagées avec le reste du processus en cours d'exécution sur la plupart des OS.