Certains pourraient dire que les deux threads est trop, je ne suis pas tout à fait dans ce camp :-)
Voici mon conseil: mesurez, n'essayez pas de deviner. Une suggestion est de le rendre configurable et initialement fixé à 100, puis relâchez votre logiciel à l'état sauvage et de surveiller ce qui se passe.
Si votre utilisation du thread des pics à 3, puis à 100, c'est trop. Si elle reste à 100 pour la plupart de la journée, elle bosse jusqu'à 200 et de voir ce qui se passe.
Vous pourrait en fait avoir votre code d'utilisation du moniteur et ajustez la configuration pour la prochaine fois qu'il démarre, mais c'est probablement excessif.
Pour clarifier et préciser:
Je ne dis pas rouler votre propre thread sous-système de mise en commun, par tous les moyens d'utiliser celui que vous avez. Mais, puisque vous posiez des questions sur un bon point de coupure pour les threads, je suppose que votre pool de threads mise en oeuvre a la possibilité de limiter le nombre maximal de threads créés (ce qui est une bonne chose).
J'ai écrit fil et la connexion à la base groupement de code et ils ont les caractéristiques suivantes (qui, je crois, sont essentielles pour la performance):
- un nombre minimum de threads actifs.
- un nombre maximal de threads.
- l'arrêt de threads qui n'ont pas été utilisés pendant un certain temps.
La première établit une base de référence pour les performances minimales en termes de pool de threads client (nombre de threads est toujours disponible pour une utilisation). La seconde définit une restriction sur l'utilisation des ressources par les threads actifs. La troisième renvoie à la ligne de base dans le calme et le temps de façon à minimiser l'utilisation des ressources.
Vous avez besoin d'équilibrer l'utilisation des ressources de l'avoir inutilisés threads (Un) contre l'utilisation de la ressource de ne pas avoir assez de fils pour faire le travail (B).
(A) est généralement l'utilisation de la mémoire (les piles et ainsi de suite) depuis un thread ne faire aucun travail ne sera pas en utilisant une grande partie de la CPU. (B) sera généralement un retard dans le traitement des demandes qu'ils arrivent comme vous avez besoin d'attendre pour un thread pour devenir disponible.
C'est pourquoi vous mesurer. Comme vous le dites, la grande majorité de vos fils seront en attente d'une réponse de la base de données de sorte qu'ils ne seront pas en cours d'exécution. Il y a deux facteurs qui influent sur le nombre de threads que vous devrait permettre un.
La première est le nombre de DB connexions disponibles. Cela peut être une dure limite, sauf si vous pouvez l'augmenter au SGBD - je vais supposer que votre SGBD peut prendre un nombre illimité de connexions dans ce cas (bien que vous devriez idéalement être en mesure de que ainsi).
Ensuite, le nombre de threads, vous devez avoir dépend de votre utilisation historique. Le minimum que vous devriez avoir en cours d'exécution est le nombre minimum que vous avez jamais eu de course +%, avec un minimum absolu de (par exemple, et de le rendre configurable comme Une) 5.
Le nombre maximal de threads doit être votre historique de maximum + B%.
Vous devez également être suivi par des changements de comportement. Si, pour quelque raison, de l'utilisation à 100% de disponible pour un temps significatif (de sorte qu'il aurait une incidence sur les performances des clients), vous devez remonter le maximum autorisé jusqu'à ce qu'il est, une fois encore, B% plus élevé.
En réponse à la "exactement ce que dois-je mesurer?" question:
Ce que vous devez mesurer plus précisément, c'est le montant maximal de threads dans l'utilisation concomitante (p. ex., en attente sur un retour de la DB appel) sous la charge. Puis ajouter un facteur de sécurité de 10% par exemple (souligné, puisque d'autres affiches semblent prendre mes exemples fixe des recommandations).
En outre, cela devrait être fait dans l'environnement de production pour le réglage. Il est normal d'obtenir une estimation à l'avance, mais vous ne savez jamais ce que la production de jeter votre chemin (c'est pourquoi toutes ces choses doit être configurable à l'exécution). C'est d'attraper une situation inattendue doublement de la client appels entrant.
